The migration ran at midnight, but the schema was already out of sync. You needed a new column, fast, before the API failed for everyone.
Adding a new column sounds simple. It rarely is. In production, schema changes are precision moves. With zero downtime requirements, every detail matters—type selection, default values, nullability, index impact, and compatibility with existing queries. One wrong change can lock a table or cascade into latency spikes.
A new column starts in the database definition. Choose the smallest data type that meets the need. Avoid null where possible to simplify logic paths. If it must be nullable, define clear handling rules in your application code. Decide if the column requires an index. Adding it later can be safer than locking writes during peak load.
Run changes in a migration script that is idempotent and reversible. Test the migration against a staging environment with production-scale data. Measure run time and lock behavior. In systems with high write throughput, deploy the column creation separately from data backfills or index creation to minimize contention.