Adding a new column should be fast, safe, and obvious. In most production systems, it is anything but. Schema changes can lock tables, trigger long-running migrations, and disrupt requests. The path to zero-downtime schema updates starts with understanding how engines handle altering tables and storing column metadata.
A new column often means an ALTER TABLE statement. The impact depends on the database engine and table size. In PostgreSQL, adding a nullable column with no default can be instant. Adding a column with a default value rewrites the table. In MySQL, ALTER TABLE may rebuild the entire table unless you use ALGORITHM=INPLACE or the newer ALGORITHM=INSTANT.
Order matters when deploying a new column to a live system. The safest sequence is:
- Deploy code that ignores the column.
- Run the
ALTER TABLEto add it, starting with nullable and no default. - Backfill data in small batches to avoid locks and replication lag.
- Add indexes, constraints, or defaults in separate steps.
- Deploy code that uses the column.
Never combine schema changes with application logic changes in the same deploy. This isolates risk and makes rollbacks simple. Monitor replication lag, I/O load, and query performance during the change. For large datasets, test the migration plan in a staging environment with production-sized data.