The migration ran clean until the last step: adding a new column. One line in the schema, but it can block deploys, lock tables, and cascade failures if handled wrong.
Adding a new column in production is not just an ALTER TABLE statement. It is about zero downtime, keeping queries fast, and ensuring data integrity as the system keeps serving traffic. Modern databases treat schema changes differently, so the correct path depends on your engine.
In PostgreSQL, adding a nullable column without a default is instant. Adding one with a default writes to every row and can lock the table. The safer route is to add the column as nullable, backfill in batches, then set the default and constraints. MySQL behaves similarly but with its own DDL locking rules; in some older versions, even null columns can trigger full table copies.
When dealing with billions of rows, you cannot risk long locks. Use online schema change tools like pg_online_schema_change or pt-online-schema-change. Test on a realistic dataset to measure migration time and log impact. Monitor replication lag if you run read replicas.