Adding a new column is never just a schema change. It’s a contract update between your data and every piece of code that touches it. To do it right, you need precision. Altering tables in production can lock rows, block writes, or even crash critical services if done without a plan.
First, define the purpose of the new column. Is it nullable? Does it have a default value? Will it be indexed? These technical choices affect storage size, query performance, and migration speed. Adding a column with a default on large datasets can cause table rewrites—it might freeze your database longer than your maintenance window allows.
Second, run the migration in a backward-compatible way. Deploy code that can handle both the old and new schema before adding the column. This prevents unhandled errors during rolling updates across services.