Data shifted. Requirements changed. You need a new column, and you need it without breaking production.
A new column is one of the most common changes in relational databases. It sounds simple. In practice, it can break code paths, invalidate migrations, and lock tables at the wrong time. The safe path is to design for zero downtime.
Start with the schema migration. In MySQL and PostgreSQL, adding a nullable column or one with a default can lock the table. On high-traffic systems, this means blocking reads and writes until the operation finishes. To avoid locking, add the column without defaults, backfill in small batches, and apply constraints after. In distributed systems, coordinate deployment so that application code can handle both old and new states.
When adding a new column for analytics or features, check every integration that touches the table. ORM models, ETL pipelines, and API responses must be updated. If a single service assumes a fixed schema, it will fail when encountering unknown fields. Use versioned responses or feature flags to roll out the change gradually.