The database schema had to change, and the deadline was yesterday. You open the migration file. The task is simple: add a new column. But simple steps can hide sharp edges. If you do it wrong, you risk downtime, data loss, or a broken deploy.
Adding a new column sounds trivial. It’s not. The right way depends on the database engine, the size of the table, and how the application reads and writes data. In PostgreSQL, adding a column without a default is usually instant. Add a default with NOT NULL on a large table, and you can lock writes for an uncomfortably long time. MySQL behaves differently; ALTER TABLE often copies the table under the hood. On large datasets, that can mean minutes or hours of blocked access.
The safest process starts with understanding the migration path. For high-traffic systems, add the column with a NULL default first. Backfill the new column in small batches to avoid write amplification. Once the data is populated, enforce constraints and defaults in a second migration. This phased approach keeps the system online and responsive.