The migration had to run before the first request hit production. That meant adding a new column without breaking anything. No downtime. No corrupt data. No rollback nightmares.
A new column sounds simple, but the wrong approach can lock tables, block queries, and trigger cascading failures. In high-traffic systems, schema changes must be deliberate. You need to think about timing, constraints, indexing, and compatibility with existing code.
Before adding a new column, inspect the schema. Understand how the table is used, which services query it, and what dependencies exist in foreign keys or triggers. Decide on the correct data type for the column. Mismatches here can be costly. Ensure defaults and nullability rules align with current logic.
Use an online schema change process for production. Tools like gh-ost or pt-online-schema-change can add a column in a live database by creating a shadow table, copying data in chunks, and swapping with minimal blocking. In cloud environments, some managed databases now provide native online DDL, which can handle a new column without downtime.