Adding a new column should be simple. In practice, it’s where production databases break, deployments stall, and data teams get paged. A single mistake in how you design, add, or backfill that column can ripple across every system that touches your database.
A new column changes more than table structure. It can impact indexes, query plans, replication, and application code. Before you run ALTER TABLE, you need to decide if the new column is nullable, what the default value should be, and how it will interact with existing records. Nullable columns avoid immediate backfills but require defensive code. Defaults protect downstream services from null values but can cause long write locks during migration.
In PostgreSQL, small schema changes like adding a nullable column are fast. Large-scale backfills are not. MySQL can still lock tables for writes in some scenarios. With high-traffic apps, even milliseconds of downtime create user-facing issues. Plan for zero-downtime migrations by splitting the process into three steps: add the new column without constraints, backfill in batches, then enforce constraints after the data update finishes.