Adding a new column is simple in theory, but in production systems it can be dangerous. The wrong migration can lock tables, slow queries, or break deployments. The goal is to make changes that are safe, fast, and reversible.
A new column often starts as a small requirement: store a flag, capture metadata, track status. The technical impact depends on the table size, indexes, and how the application reads and writes to it. On small datasets, direct ALTER TABLE commands may be fine. On massive tables, that command can run for hours and block writes.
Use an additive, backward-compatible approach. Create the new column as nullable with no default. This prevents full-table rewrites. Once deployed, backfill data in small batches, observing query performance. When the data is complete, add constraints or defaults if necessary.
In distributed environments, deploy schema changes separately from application changes. First release support for reading from the new column. Then write to it. Only after data is consistent should you change logic to depend on it. This staged process avoids downtime.