Zero-downtime migrations with Alembic

A migration can lock the table it's changing

You met Alembic's basic idea back in module 25. At scale, HOW you write a migration matters as much as what it does. Adding a column with NOT NULL and a default to a large existing table sounds harmless — but Postgres historically had to rewrite every existing row to backfill the default, holding a lock on the whole table for the duration. On a bookings table with millions of rows, that's minutes of the table being unreadable and unwritable — a real outage, not a hypothetical one.

(Modern Postgres optimizes a constant default to be metadata-only and fast — but a computed or non-constant default, or an older Postgres version, still triggers the full rewrite. Treat 'add NOT NULL + default to a big table' as dangerous by default rather than betting on which case you're in.)