Adding a new column should be fast, safe, and predictable. In most systems, it isn't. Schema changes can block writes, lock tables, or cause unpredictable downtime. The larger the dataset, the greater the risk. Growth turns a simple ALTER TABLE into a high-stakes deployment. Engineers need a process that handles a new column without breaking production.
The first rule: choose the right migration strategy. For small databases, adding a column with a default value is usually fine. For large ones, this can lead to table rewrites that stall traffic. Instead, create the new column without defaults or constraints, then backfill asynchronously. This avoids locking and lets the operation complete instantly from the client perspective.
The second rule: make schema changes backward-compatible. Applications should be able to read and write both the old and new formats during the transition. Deploy schema changes before deploying code that depends on them. Only when the new column is fully backfilled and tested should you enforce constraints or drop old fields.