// the find
fatkodima/online_migrations
Catch unsafe PostgreSQL migrations in development and run them easier in production (code helpers for table/column renaming, changing column type, adding columns with default, background migrations, etc).
A Rails/PostgreSQL gem that detects unsafe migration patterns (table rewrites, blocking DDL, N+1 lock risks) at migration-run time and gives you code helpers to do the safe version instead. It's aimed at teams running Postgres at a scale where a bad migration can take down writes for minutes, and it's explicitly a superset of strong_migrations with actual helper methods instead of just warnings.
The column/table rename trick using a VIEW plus schema cache override avoids a full data copy, which is the part everyone gets wrong by hand. It ships real background data and background schema migration frameworks (batching, throttling, retry/scheduler) rather than just telling you to go write that yourself. Checks are specific to real PG rewrite/lock behavior (version-aware: e.g. PG11+ default-value adds, PG12+ not-null via check constraint), not generic lint rules. The multi-step workflows (initialize/backfill/finalize/cleanup) are consistent across type changes, renames, and column adds, so once you learn the pattern it transfers.
Postgres-only — if you're on MySQL/MariaDB too, you're stuck with strong_migrations or nothing from this gem. Requires Ruby 3.3+ and Rails 7.2+, so it's dead weight for anyone on an older stack, and the multi-step rename/retype migrations (5-10 deploys per change) are a real workflow cost, not just boilerplate. The view-based rename trick silently breaks schema dumping to schema.rb — you're forced into structure.sql or an extra gem (scenic) just to keep migrations reproducible, which is a non-obvious tax most people won't discover until CI breaks. Exclusion constraints have no safe path at all (acknowledged in the docs as an open problem), so for that one case you're on your own anyway.