A new column is one of the most common schema changes, yet it can be one of the most disruptive if handled wrong. Adding a column to a live production table changes the contract between your data model and the code that speaks to it. Without discipline, you risk downtime, broken queries, and silent data loss.
Plan the addition with intent. First, define the column schema precisely — name, type, nullability, default values. Use database-native defaults instead of setting them in application code. Defaults applied in the migration reduce race conditions between deployment steps.
When possible, add the new column in a non-blocking way. On large relational databases, use ALTER TABLE ... ADD COLUMN with options that avoid rewriting the whole table. For systems that do not support online schema changes, schedule maintenance windows or use tools like gh-ost or pt-online-schema-change.
In application deployments, deploy in phases. Ship code that can read the new column before writing to it. Backfill historical data in batches to avoid locking. Only when data is populated and verified should the application start to depend on the column in requests or queries.