The query had been running fine for months. Then the product team asked for one more field. You need a new column.
Adding a new column sounds small, but it carries real impact. Schema changes can lock tables, block writes, or break downstream jobs. The longer the table has existed, the more hidden dependencies it carries. A careless alter can freeze production.
The first step is to define the exact type and constraints for the new column. Avoid generic types. Choose the smallest, strictest type that matches the data. Decide if you can allow nulls during migration to reduce risk.
Next, plan the deployment. For small datasets, a direct ALTER TABLE ADD COLUMN may be fine. For large, high-traffic databases, use an online schema change tool or a phased approach. Add the column without a default. Backfill data in small batches. Then apply constraints or defaults after the table is fully updated.
Always measure before and after. Check query plans involving the new column. Update indexes only if you see actual performance needs. Blindly adding indexes increases storage and slows writes.