Comparison
strong_migrations vs pgfence
An honest comparison of two Postgres migration safety tools: strong_migrations (Ruby, Rails runtime) and pgfence (TypeScript, multi-ORM static analysis).
What strong_migrations does well
strong_migrations is a well-known tool in this category. Created by Andrew Kane, it protects Rails applications from dangerous migrations by intercepting ActiveRecord migrations at runtime and raising an error before dangerous DDL executes.
If you run Rails, it is one of the clearest migration-safety options to evaluate first.
Feature comparison
| Feature | strong_migrations | pgfence |
|---|---|---|
| Language | Ruby | TypeScript (Node.js native) |
| Analysis approach | Runtime interception | Static analysis (pre-merge) |
| Frameworks | Rails / ActiveRecord | TypeORM, Prisma, Knex, Sequelize, Drizzle, raw SQL |
| When it catches issues | When the migration runs | In CI, before merge |
| Lock mode reporting | No (identifies patterns, not lock modes) | Explicit per statement |
| Safe rewrite recipes | Yes (inline suggestions) | Yes (step-by-step safe rewrite guidance for common patterns) |
| DB-size-aware risk scoring | No | Yes (row counts and table sizes) |
| SQL parser | Pattern matching on ActiveRecord API | libpg_query (PostgreSQL's actual parser) |
| Database required | Yes (runtime interception) | No (optional for size-aware scoring) |
| Coverage reporting | No | Yes (coverage line in reports) |
| Policy checks | Some (timeouts, transaction settings) | Yes (lock_timeout, statement_timeout, tx policy) |
| Trace mode | No (runtime only) | Yes (Docker-based, verifies locks against real PG) |
| VS Code extension | No | Yes (diagnostics, supported quick fixes, hover) |
| GitHub Action | No | Yes (repo-level composite action) |
| SARIF output | No | Yes (GitHub Code Scanning integration) |
Runtime vs. static analysis
The fundamental difference is when the tool catches issues.
strong_migrations intercepts migrations at runtime, when rails db:migrate runs. This means it has access to the actual database schema and can make precise decisions. But it also means the issue is caught later in the workflow: during local development or deployment, not during code review.
pgfence analyzes migration files statically in CI, before the code merges. In CI and review tooling, teams can surface lock modes, risk levels, and safe rewrite guidance before approval. The goal is to catch the dangerous migration before a database ever sees it.
When to choose strong_migrations
- Your team runs Ruby on Rails with ActiveRecord
- You want runtime interception that catches issues during
db:migrate - You prefer a mature, well-established tool with years of production use
- You want integration with Rails-specific patterns (like
safety_assuredblocks)
When to choose pgfence
- Your stack is Node.js/TypeScript (strong_migrations doesn't work outside Ruby)
- You use TypeORM, Prisma, Knex, Sequelize, or Drizzle
- You want migration safety checks in CI, before merge, not at runtime
- You want to know the exact lock mode each statement takes and what it blocks
- You need table-size-aware risk scoring from a stats snapshot (no runtime DB required)
- You want GitHub-friendly CI and PR outputs with lock analysis and safe rewrite guidance
Different ecosystems, same problem
strong_migrations proved that migration safety tooling matters. pgfence brings a similar focus to Node.js teams, with a different approach: static analysis using PostgreSQL's actual parser, explicit lock mode reporting, and safe rewrite guidance across multiple ORMs.
If your team runs Rails, use strong_migrations. If your team runs Node.js, pgfence fills the same role.