The build had passed, but the data looked wrong. A missing value, traced to a schema that hadn’t kept pace with the code. The fix was simple: add a new column. The consequences were not.
Adding a new column to a database table is one of the most common schema changes. Done right, it’s fast, clean, and safe. Done wrong, it can cause downtime, block writes, or corrupt production data. The difference lies in understanding the database engine, your migration tooling, and the lifecycle of the change.
First, know the cost of a new column in your database system. In PostgreSQL, adding a nullable column without a default is instant. Adding one with a default value rewrites the table and locks it, so it should be avoided in large tables under load. MySQL behaves differently depending on version and storage engine. In both cases, test your migration on a production-sized clone.
Second, make the change backward compatible. Add the new column without dropping or altering existing ones. Update code to write to both old and new columns during the migration phase. Roll out reads from the new column only after all writers have been updated. This removes the need for downtime and makes rollbacks possible.