The migration script failed on a single line, and the deploy froze. All because of one thing: a new column.
Adding a new column to a database table sounds simple. It is not. In production systems, it can stall queries, lock tables, and break APIs in ways that linger for weeks. The operation touches schema, data, code, and infrastructure at the same time. If you do not plan it well, you ship downtime.
In SQL, adding a new column with ALTER TABLE can trigger a full table rewrite. On large datasets, this means hours of blocking. In PostgreSQL, smaller changes—like adding a nullable column without a default—are metadata-only and cheap. But adding a non-null column with a default forces a full table update. MySQL and MariaDB can perform instant column additions for some types, but not all. Every database engine has its own rules, and knowing them is the first defense against failure.
A schema change that survives production must start with analysis. Check the engine version. Understand the table size and index usage. Plan the column defaults with intent. In many cases, adding the column as nullable first, backfilling the data in controlled batches, and then applying constraints avoids downtime. Test the migration path against a realistic staging dataset, not an empty mock.