The migration was almost done when the schema broke. The team stared at the error: missing field. The fix was simple—add a new column—but the clock was already past midnight.
A new column changes the shape of data. It can unlock features, improve performance, or support integrations. But if you do it wrong, it can freeze production or corrupt history. In relational databases, adding a column touches both schema and data. The impact depends on engine, scale, and access patterns.
In PostgreSQL, adding a nullable column with a default value is instant in newer versions, but can lock the table in older ones. In MySQL, ALTER TABLE can rebuild the entire table, blocking writes for seconds or hours. In distributed systems like CockroachDB, schema changes are often asynchronous and multi-step. Knowing how your database handles ALTER TABLE ADD COLUMN is the difference between zero downtime and a blown deploy window.
Before adding a new column, ask if you need a default value at creation. Setting a default at schema change time can rewrite all rows. Instead, add the column as nullable, backfill in small batches, then set the default and NOT NULL constraints. This staged approach avoids blocking transactions and reduces replication lag.