Adding a new column should be simple. In practice, it’s one of the most common points where production deployments stall. Schema drift, partial migrations, historical data, and concurrency all conspire to make a “simple” new column dangerous.
When you add a new column to a table, you need to plan for three things: data consistency, application compatibility, and deployment safety. A single ALTER TABLE can lock writes. On high-traffic systems, this lock can cascade and take your service down.
First, decide if the new column should have a default value or allow NULLs. Setting a default in the DDL can cause a full table rewrite on massive datasets. Instead, create the column as nullable, backfill in small batches, then set the default once complete. This avoids blocking writes and keeps latency stable.
Second, handle application code in phases. Deploy code that writes to the new column before code that reads it. This keeps older versions safe during rolling deploys. Avoid situations where reads expect a column that isn’t yet present in every environment.