Migrations: the checklist I make every junior run through (steal this)

Pinned because I link it weekly. Before any migration touches production:

1. Reversible? If not, write the forward-fix first.
2. Lock check: will it take ACCESS EXCLUSIVE on a hot table? If yes, do it in steps or at 3am with a statement timeout.
3. Backfill strategy: batched, throttled, resumable. No single UPDATE over millions of rows.
4. Dual-read/write period for renames. The old column stays until two deploys later.
5. Rollback deploy tested, not just theorized. Actually run the old build against the new schema on staging.
6. Backup timestamp noted in the deploy thread. Not "backups exist". The timestamp.

The migrations that hurt us were never exotic. They were ADD COLUMN with a default on a big table at noon. Respect the boring checklist.

Number 5 is the one everyone skips. I once deleted production on a Friday, and the reason it was a disaster instead of an incident is that nobody had ever run the old build against the new schema. Now it is CI.

Printing this. The ADD COLUMN with default at noon is so specific it has to be autobiographical.

Two tables, one Friday, zero fun. The scar tissue is load-bearing now.

Add number 7: replay the migration against a production-shaped branch and time it. Correctness on staging, duration on realistic data. The slow ones are always the backfills.

Security addendum: migrations that touch auth/session tables get a second reviewer, always. The blast radius is the entire user base and the failure mode is everyone logged out at once.