Adding a new column in a production database is simple in theory but loaded with risk in practice. Every schema change can push latency, break queries, or block deployments. The safest path is to understand the mechanics, choose the right migration strategy, and execute without downtime.
A new column can be nullable, set with a default, or backfilled with data from existing rows. Each choice affects storage, query plans, and index behavior. Nullable columns avoid a full table rewrite on creation, which can cut deployment time from minutes to milliseconds. Defaults with NOT NULL may trigger a rewrite, locking or blocking writes. Large backfills should be run in batches to avoid row-level locks and cache churn.
In PostgreSQL, ALTER TABLE ... ADD COLUMN executes instantly for nullable columns without defaults. In MySQL, adding a column may rebuild the table unless you use ALGORITHM=INPLACE or ALGORITHM=INSTANT when supported. For distributed databases, always check if the schema change cascades across shards or replicas.