Adding a new column sounds simple, but in production systems it is one of the most dangerous schema changes you can make. It changes the database structure, affects queries, and can block writes if done without care. In distributed systems, the risk compounds when different services expect different versions of the schema.
A new column impacts performance at multiple layers. Altering large tables can lock rows or the entire table, causing downtime. Even in modern databases with online DDL, adding a column with a default value may rewrite every row. This can trigger replication lag, break indexes, or hit storage limits. Planning for this early avoids rollbacks under pressure.
To add a new column safely, treat it as a staged deployment. First, deploy code that ignores the new column. Then deploy migrations that add it without defaults or constraints. Fill the column with backfill jobs in small batches, monitoring load and replication delay. Finally, update application code to use it, and only then apply defaults and constraints.