Adding a new column in a production database changes more than the schema. It can impact query plans, write performance, backups, and downstream systems. Schema evolution is easy to plan in development environments, but in production, every column addition is a deployment with risk.
A new column may trigger a full table rewrite, depending on the database engine. In PostgreSQL, adding a nullable column with a default can lock writes during the rewrite. In MySQL, the cost depends on the storage engine and version. For large datasets, the downtime or replication lag can be severe.
Before creating the new column, measure the size of the table, the replication lag tolerance, and the query patterns that will use it. Decide if the column should be nullable, if it needs a default, and whether it will be indexed immediately or later. Avoid premature indexing; every index slows down writes.
Plan the deployment in stages. First, add the column without defaults or constraints to avoid table rewrites. Second, backfill data in controlled batches to prevent load spikes. Third, add constraints and indexes after the backfill completes. Monitor each stage with clear metrics on latency and error rates.