Adding a new column is never “just one more field.” It changes the shape of your data. It changes queries, indexes, and constraints. It can stall deployments if not done with precision. The way you handle it will determine whether production stays alive or burns under migration load.
Start by defining the new column with exact types and constraints. Avoid guessing at defaults—be explicit. If the column is non-nullable, plan for backfill before the schema change. For large tables, use phased migrations: create the nullable column first, populate in batches, then set the constraint. This prevents locking entire tables for extended periods.
Review how the new column interacts with existing indexes. Adding it to the wrong composite index can slow writes. In some cases, a separate index is faster. Re-run query plans after the schema change; assumptions about performance often fail when data distribution shifts.