Adding a new column is not hard. Doing it fast, without breaking production, is harder. Schema changes are traps for the unwary. Locking tables. Blocking writes. Slowing queries. Every second of downtime is expensive.
A new column changes more than the schema. It touches application code, APIs, data pipelines, and indexes. If defaults are wrong, old rows return nulls. If types mismatch, casts fail. If naming is inconsistent, developers waste hours hunting bugs.
Start by defining the exact purpose of the new column. Decide on data type, nullability, and default values. Test in a staging environment with production-scale data. Measure query plans before and after. Watch for unexpected full table scans.
For large datasets, add the new column without locking the table. PostgreSQL's ADD COLUMN is usually fast, but adding with a default rewrites the table. Use a two-step migration: add the column null, then backfill in batches. Only once all values are set should you add NOT NULL constraints.
Update the application to read and write the new column only after it exists in production. Deploy code and schema changes in separate steps. Roll out writes first, reads second. This prevents race conditions while deployments propagate.