Rails Zero-Downtime Database Migrations

A production checklist for safe Rails migrations: compatibility, backfills, PostgreSQL locks, rollback limits, and deploy order.

Most Rails migrations that cause outages are not wrong. They are correct and badly timed.

rename_column works. change_column_null works. Both can still take your app down, because for a few seconds two versions of your code run against one database, and only one of them knows what you changed.

This is the order I use for Rails zero downtime migrations on PostgreSQL, tested on Rails 8.1 and PostgreSQL 15.

They fail in three ways, and each one needs a different fix.

Version skew. During a rolling deploy, old and new processes share a database. A migration that drops or renames a column breaks whichever side still expects the old shape.

Lock queues. A schema change waits for a lock, and everything behind it waits too. The migration itself may be instant. The queue it creates is not.

Long writes. A backfill, an index build, or a constraint check holds a transaction open or scans the table while traffic keeps arriving.