A new column is one of the most common schema changes, yet it’s also one that can break production if done poorly. Adding a column touches data storage, queries, APIs, and often the application logic. A careless migration can lock tables, slow writes, or cause failures in code expecting the old schema.
Plan the change before running the migration. Decide on the column name, data type, default value, and whether it can be null. If the column needs an index, create it only after the column is populated to avoid long lock times. For large datasets, add the column in a way that keeps the migration online: break it into multiple steps, backfill in batches, and use tools that reduce table locking.
Update application code to handle both the old and new schemas during the rollout. Deploy the changes in a safe order: first add the new column, then backfill data, then switch the application to use it, and finally drop any old columns if needed. Test migrations against staging databases of realistic size to predict performance and catch problems.