Adding a new column sounds simple. In production, it can be dangerous. Schema changes lock tables, block writes, and break upstream jobs. Even a small ALTER TABLE can trigger downtime if you don’t plan it. At scale, this is not an option.
The first step is to define the column exactly. Decide the name, type, nullability, and default values. Avoid defaults that require rewriting every row. Instead, add the column as nullable, then backfill in controlled batches. This reduces lock times and keeps I/O steady.
Next, consider indexes. Adding an index with the new column can double migration cost. Create the column first, let it populate, then add indexes in a separate step. For large datasets, use online schema change tools like pt-online-schema-change or native database features that stream changes without blocking traffic.
Coordinate with application code. Deploy code that ignores the missing column. Run the migration. Deploy code that uses the new column. This decouples schema and application changes, avoiding race conditions and brittle deploy sequences.