A single missing field can break a release, trigger rollbacks, and burn hours in postmortems. Adding a new column to a database table should be simple, but at scale it’s a fragile step. Schema changes can lock tables. They can block writes. In production, they can freeze user actions. Doing it right means balancing speed, safety, and consistency.
Start by designing the new column with intent. Define its type, default values, and nullability. Never add a column to production without first testing the migration path against a dataset that mirrors the size and shape of the real thing. Use feature flags or shadow writes if you need to decouple the schema deployment from the application code that uses it.
On relational databases like PostgreSQL or MySQL, large table changes require careful execution. Adding a nullable column without a default value is usually safe. Adding a non-nullable column with a default can rewrite the entire table. That can lock reads and writes for minutes or hours. Avoid that by creating the column as nullable, backfilling in batches, and then adding the constraint in a later step.