Adding a new column seems simple. In production, it is not. Schema changes on live databases can lock tables, break queries, trigger downtime, or cause silent data corruption. The wrong approach can turn a one-line migration into a site outage.
The core decision starts with whether the new column is nullable or has a default. Adding a nullable column is usually safe and fast. Non-null with a default value can trigger a full table rewrite on some engines. On large datasets, that’s hours of blocked writes unless you handle it with an additive migration pattern.
In PostgreSQL, adding a new column with a default will rewrite the whole table before 11.2. After that, defaults are stored in metadata, making it nearly instant. MySQL, depending on version and storage engine, still rewrites for most default operations. Know your database’s exact behavior before deploying.
For large tables, the safest method is zero-downtime migrations. Add the column as nullable first. Backfill in small batches to avoid replication lag and lock contention. Then apply constraints or defaults after the data is in place. This avoids blocking queries and lets you roll back if needed.