Adding a new column should be simple. In production, it is not. It can break queries, slow down requests, and lock tables if not planned. Every schema change has to be precise, timed, and verified. The wrong approach can cascade into downtime.
A new column in SQL alters the table definition. In PostgreSQL, ALTER TABLE ADD COLUMN is the command. By default, it will add the column to the end of the table. Adding a column with a default value can rewrite the entire table, which is dangerous on large datasets. Best practice is to add it as nullable, backfill in small batches, then set constraints after data migration.
In MySQL, an ALTER TABLE may trigger a table copy for some storage engines. This can lock writes. Using ALGORITHM=INPLACE or ONLINE (on supported versions) can reduce impact, but race conditions still require careful handling.
New columns don’t break code if the application checks for their existence before use. Rolling out the change across services means coordinating deployments. First, add the column. Then deploy code that reads from it without assuming it’s always populated. Last, write to it. This staged rollout allows rollback without downtime.