The migration script failed. The release clock kept ticking. You needed a new column in production, fast, without breaking anything.
Adding a new column sounds simple, but in practice it can trigger downtime, lock tables, or kill query performance. In relational databases like PostgreSQL, MySQL, or MariaDB, ALTER TABLE commands can block writes if not handled carefully. Even non-blocking changes can stall under high load if indexes or defaults are involved.
The safest approach starts with checking your environment. Understand if your ALTER TABLE ADD COLUMN will trigger a table rewrite. Adding a nullable column without a default in PostgreSQL, for example, completes instantly. Adding a default with a non-volatile value writes every row. In MySQL with InnoDB, instant add column operations are supported only in recent versions; older ones rebuild the table.
In zero-downtime deployments, schema changes should be backward-compatible. Deploy the new column first, without constraints that block writes. Update application code to write to both old and new columns if needed. Once all clients use the new column, backfill data in batches to avoid overload, then apply constraints or defaults in a later migration.