The migration script finished, but the table looked wrong. A missing new column had broken the data flow, and every downstream service was throwing errors.
Adding a new column is simple to describe but easy to get wrong in production. Schema changes that seem trivial in development can cause locks, downtime, or silent data loss in live systems. The right approach depends on your database, your concurrency model, and your tolerance for risk.
In SQL, a new column is added with an ALTER TABLE statement. For small datasets, this runs fast. For large, high-traffic tables, it can block queries and delay writes. Some databases, like PostgreSQL when adding a nullable column with a default value, rewrite the table entirely. This can take minutes or hours. MySQL and MariaDB may lock the table depending on the storage engine and version.
Safe deployment patterns include adding the column without a default, backfilling values in small batches, and then adding constraints or indexing afterward. This reduces blocking but increases operational steps. For zero-downtime migrations, many teams use tools like pt-online-schema-change or gh-ost to stage a new column in parallel and swap it in without locking.