The migration failed at column 42. You open the schema and realize the fix is simple: a new column.
Adding a new column to a database table is one of the most common schema changes. Yet it is also one of the most dangerous if done without discipline. A careless ALTER TABLE can lock rows for seconds or minutes, spike CPU load, or cascade into replication lag. The larger the dataset, the higher the stakes.
A new column changes storage layouts, index structures, and sometimes query plans. In systems under heavy load, this can break SLAs. The safe path always starts with understanding your database engine’s behavior. Postgres, MySQL, and SQL Server handle schema changes differently. Some versions allow instant column adds if you define sane defaults or avoid defaults altogether. Others rewrite the whole table.
Best practice: add the column without a default or NOT NULL constraint first. Backfill values in batches. Then add constraints after data migration. This keeps table locks short and reduces contention. Monitor replication lag if you’re using replicas. Always test on a dataset that matches production size before touching live systems.