The migration finished at 3:14 a.m. The new column was there, sitting in the database schema like a fresh scar across the table. It looked simple. It was not.
Adding a new column is one of the most common schema changes in production systems. It can be safe or catastrophic, depending on how you do it. The core issues are schema locking, query performance, and data backfill strategies. Doing it right means zero downtime and no corrupt data. Doing it wrong means stalled requests, failed deployments, and rollback chaos.
The first step is to understand the database engine’s behavior. MySQL, PostgreSQL, and modern cloud databases handle ALTER TABLE ... ADD COLUMN differently. Some use metadata-only operations for nullable columns with defaults. Others rewrite the full table, which can lock writes for minutes or hours under load.
For high-traffic systems, plan your new column in two phases. Phase one: run ALTER TABLE with a nullable column, no default, and no constraints. This is cheap and usually instantaneous. Phase two: backfill data in batches using an idempotent background process. Once backfill is complete, set defaults and add constraints in separate, small changes to avoid massive table rewrites.