A single schema change can decide the fate of a release. Adding a new column is one of the most common, and most dangerous, database operations. Done right, it unlocks features. Done wrong, it locks you into downtime and rollback chaos.
When you add a new column to a production table, you’re altering a core contract between your application and its data. The stakes are high: the database must accept writes, preserve existing rows, and keep queries fast while the change applies. For large tables, an ALTER TABLE ADD COLUMN in the wrong RDBMS can block traffic for minutes or hours.
To avoid this, engineers often use online schema changes. PostgreSQL supports adding columns with defaults as constants without rewriting the entire table, but anything involving a computed default triggers a full table rewrite. MySQL’s ALGORITHM=INPLACE can help for certain column types, but not all. Always test the exact migration on a staging dataset that mirrors production scale before deploying.
Nullability matters. Adding a non-nullable new column with no default will fail if existing rows can’t satisfy the constraint. Adding it nullable, backfilling values in small batches, and then setting NOT NULL is safer in most cases. This controlled sequence reduces long locks and keeps availability high.