Adding a new column in a database is simple to write, but complex to deploy safely. Every schema change carries risk. Schema migrations must handle live traffic, existing data, and compatibility with older code paths. For high-uptime systems, you can’t afford locks or slow responses during the change.
Know your database. In PostgreSQL, adding a column without a default is fast. Adding a column with a default value to a large table can lock writes. MySQL also varies by engine—InnoDB often requires a table copy for certain types of column changes. Always review the execution plan before running an ALTER TABLE in production.
Plan for data backfills. Adding a NOT NULL column means either setting a default or updating rows in batches to avoid timeouts. Use background jobs for large updates. Monitor performance during the migration and run it during low-traffic windows if possible.
Keep application code in sync. Deploy changes that read the new column separately from those that write to it. This avoids race conditions when old code versions hit updated schemas. Use feature flags to control rollout and ensure old behavior still works until the change is fully live.