Adding a new column sounds simple. In production, it’s rarely that clean. Schema changes can lock tables. They can block writes. They can cascade through code and break queries that worked a second ago. The difference between a smooth migration and a midnight outage is planning.
The first rule: know your database. In PostgreSQL, adding a nullable column without a default is fast. Adding a column with a non-null default rewrites the whole table. MySQL behaves differently, and not every storage engine responds the same way. Read the docs, test on a realistic dataset, and measure the cost before you run ALTER TABLE.
The second rule: keep the change safe. In systems under heavy load, run schema changes in multiple steps. Create the new column with no constraints. Backfill the data in batches, using small transactions to avoid long locks. Once complete, enforce the constraint or drop the old column. This approach keeps the application responsive and the database stable.
The third rule: update the code and data in sync. Deploy application changes that can handle both old and new schemas. Use feature flags to control rollout. Remove the old code paths only after the migration is verified in production.