Adding a new column is one of the most common database schema changes. Done wrong, it causes downtime, data loss, or blocking locks in critical paths. Done right, it slips into production without a hitch. The key is understanding how your database engine handles ALTER TABLE operations and planning for zero-downtime execution.
In PostgreSQL, ALTER TABLE ADD COLUMN without DEFAULT and NOT NULL is instantaneous. But as soon as you add a default or mark it not null, the database rewrites the table. On large datasets, that can mean minutes—or hours—of locked writes. The same holds true in MySQL and MariaDB, though Online DDL options can help. Always check ALGORITHM=INPLACE or COPY and verify its impact before running the migration.
For distributed systems, schema changes must be coordinated with application deployments. Adding a new column to a live table means updating ORM models, validation logic, and serialization layers. Staged rollouts—deploying schema changes before the code that uses them—reduce the risk of undefined behavior and application errors.