You needed a new column.
Adding a new column sounds simple. It rarely is. Schema changes can block writes, spike CPU, and stall deployments. In distributed databases, the wrong migration can bring down entire regions. Even small teams know one careless ALTER TABLE can break production.
A new column is not just a schema change—it is an operation with real cost. The choice of how to add it, and when, matters. You need to think about the database engine, index impact, null defaults, and how your ORM maps the model. You need to test the migration path on real data, not just empty tables.
In MySQL, adding a new column with a default might lock the table unless you use ALGORITHM=INPLACE when possible. In PostgreSQL, adding a column with a non-null default rewrites the whole table—better to add it nullable and backfill in batches. In document stores, adding a field might be cheap, but reading stale documents with missing fields may break deserialization logic.
Plan for zero downtime. Use migration tools that split the work into safe steps. Deploy the code that can handle both the old and new schema before you change the schema. Only after the migration finishes should you make the new column required in application logic.
A new column can be the smallest change in your codebase or the biggest risk in your infrastructure. Treat it like a deploy. Measure, monitor, and roll it out with intent.
See how to run safe migrations and add a new column without downtime. Try it live in minutes at hoop.dev.