The migration was almost done when the issue appeared: a missing field that could break the whole release. You needed a new column. Fast.
Adding a new column is one of the most common database changes, but it’s also one of the most likely to create downtime, data corruption, or performance hits when done poorly. A clean deployment means planning the schema change, understanding the table’s size, locking behavior, indexing, and how the application reads and writes to it.
In relational databases, a new column alters the structure of the table. The cost of that alteration depends on the engine, the column type, the default values, and whether the DB must rewrite the entire table. On small tables, this is trivial. On large, high-traffic ones, it can be an outage waiting to happen.
For PostgreSQL, adding a new column with a constant default rewrites the table up to version 11. In later versions, it only stores the default in the metadata, avoiding the rewrite. MySQL behaves differently depending on the storage engine and version; InnoDB can rewrite in place for some changes but still locks in others.