The build broke again. Everyone is staring at the database schema, trying to figure out why the migration failed. The culprit: a new column added to a critical table without the safeguards that could have prevented the mess.
Adding a new column should be predictable and safe. In production systems, it must be done without locking tables for long periods, breaking queries, or corrupting data. A disciplined process for adding a new column reduces downtime, keeps services responsive, and avoids painful rollbacks.
Start by planning the schema change. Confirm that the new column is necessary, with a defined name, type, and nullability. Ensure compatibility with existing code paths. For large datasets, consider rolling out the new column in phases. Create it with a default value only if the database engine can do so without rewriting the entire table.
In PostgreSQL, adding a nullable column is a fast metadata-only operation. Adding a column with a default value on a large table can lock writes, so you may prefer adding it as nullable and then updating rows in batches. In MySQL, be aware that certain storage engines require a full table rebuild for most schema changes.