A migration is a change to data people are using. The safe ones add first, backfill in a job, and only then remove the old column.
Add before you remove
Create the new column as nullable, deploy the code that writes both, and backfill during a quiet hour. Dropping the old column in the same release as the new read path means a rollback cannot boot. If the table is large, an index built concurrently is a different operation from a rewrite of every row.
Know the lock
A default on a busy table can lock writes longer than the health check allows. Read the database’s note for the version you run, and try the migration on a copy of production size, not on an empty laptop database. If it rewrites the table, schedule it, and tell the client the window.
The app and the schema must overlap
The previous release should still start against the new schema, or you do not have a rollback. That usually means the old code ignores the new column and the new code tolerates the old nulls until the backfill finishes.
Add the column before you require it
A migration that adds a non-null column without a default will lock and fail on a table that already has rows. Add the column as nullable, deploy the code that writes it, backfill, then enforce the constraint in a later migration. Each of those steps can roll forward on its own.
Read the plan on a copy of production size if the table is large. A rewrite of a busy table is an outage even when the SQL looks like one line.
What to do this week
- Split destructive changes into a later release.
- Rehearse on a database with real volume.
- Confirm the previous image still boots.