Creating a new column in a production database is not only about adding fields. It’s about schema evolution, deploy safety, and ensuring application code aligns with persistent state. A careless ALTER TABLE can lock rows, block writes, and impact availability. The right approach depends on the database engine, the size of the table, and the traffic load.
In PostgreSQL, adding a nullable column with a default can trigger a table rewrite. This means the command will scan and rewrite all rows, potentially causing long locks. The safer pattern is to first add the column without a default, then update it in batches, and finally set the default at the schema level. In MySQL, similar concerns apply: run the change in a way that avoids full table blocking, often using online DDL if supported.
For distributed databases, schema changes must propagate across nodes without creating version mismatches between services. This often requires deploying application code that can handle both old and new schemas during the migration window. The process may include feature flags, staged rollouts, and backward-compatible queries.