The migration hit production at midnight. By 12:03, a missing column halted every write. Logs filled. Transactions queued. The fix was simple: add a new column. But in systems with live traffic, “simple” can be a lie.
A new column in a database is more than a structural change. It impacts queries, indexes, migrations, and in-memory caches. If not planned, it can lock tables, break applications, and corrupt data. In distributed systems, schema changes ripple across services and versions.
When adding a new column to relational databases like PostgreSQL or MySQL, downtime can come from table rewrites. Large tables may lock during ALTER TABLE unless you use non-blocking strategies. Adding a nullable column with a default can force a table scan. Avoid this by adding the column without a default, then backfilling in small batches.
For NoSQL stores, a new column (often a new field) may seem trivial. But you must handle forward and backward compatibility in application code. Existing documents need migrations, or your code must treat missing values as defaults until fully updated.