Adding a new column seems simple. One line in an ALTER TABLE statement. But in production, it can lock writes, disrupt queries, and trigger costly downtime. The right approach depends on the database, the table size, and the load. Fail that, and you create a bottleneck that ripples through every dependent service.
In PostgreSQL, adding a new column with a default value rewrites the table. That rewrite can crush performance for large data sets. One option is to add the column without a default, then backfill in batches. In MySQL, a similar problem arises with table rebuilds. Online schema change tools like pt-online-schema-change or gh-ost can add the column without blocking.
When adding a new column to a distributed database, the complexity multiplies. Schema changes must propagate across nodes in a way that doesn’t break replication or consistency guarantees. The trick is to design the migration plan before the code that will consume it.