The migration failed halfway through. The logs showed why: a missing new column in the database schema.
Adding a new column is one of the most common changes in a production database. Yet it’s also one of the most dangerous if deployed without care. Schema changes affect every query, index, and data write touching that table. In high-traffic systems, even a small DDL operation can lock rows, block other transactions, or spike CPU. The wrong approach can lead to downtime and data drift.
The first rule for adding a new column: plan for backward compatibility. Deployed services may still expect the old schema. Introduce the column in a way that doesn’t break running code. Use a deployment process that rolls out schema changes separately from application changes. Make the column nullable or provide a sensible default so that old writes still succeed.
The second rule: measure the impact. On large tables, a new column can trigger storage engine behavior you don’t expect. For example, in some systems a table rewrite occurs even for adding a nullable column without a default. This can mean minutes or hours of lock time. Test the exact DDL statement on a staging database with production-like data before touching production.