Adding a new column sounds simple. In production, it is not. Schema changes carry risk. They can lock tables, cause downtime, and break dependent code. A disciplined approach is the difference between a smooth release and a pager going off in the middle of the night.
First, define the exact purpose of the new column. Document the data type, nullability, default values, and constraints. Choose a name that fits existing naming conventions. Avoid ambiguous types and inconsistent casing.
Second, plan the database migration. For large tables, consider adding the column without a default, then backfilling data in batches. This reduces lock times and performance hits. If the column will have indexes, add them after the data is populated to avoid slow writes during the backfill.
Third, deploy in stages. Add the column first. Ship application code that reads from both old and new columns if needed. Populate the column in controlled chunks. Switch writes over once the column is ready. Remove legacy paths only after verifying all data.