Adding a new column is one of the most common schema changes in production systems. Done right, it’s a zero-downtime upgrade. Done wrong, it blocks writes, locks tables, and stalls the application. The right approach depends on your database engine, the data size, and the operational constraints.
In PostgreSQL, ALTER TABLE ... ADD COLUMN is fast when the new column is nullable without a default value. The system updates the metadata, and the column virtually exists for all rows. But adding a default value or making it non-null forces a rewrite. On large tables, this rewrite can consume I/O and block concurrent operations. The safer pattern is to add the column as nullable, backfill in controlled batches, then alter with a SET NOT NULL once complete.
In MySQL and MariaDB, adding a new column can trigger a table copy depending on the storage engine and version. Online DDL features like ALGORITHM=INPLACE or ALGORITHM=INSTANT in newer versions can prevent blocking writes. Always verify execution plans before pushing changes to production.
Distributed databases like CockroachDB, YugabyteDB, or Spanner handle schema changes asynchronously, but the logical column addition still triggers cluster-wide propagation. Ignoring these mechanisms can lead to partial availability or inconsistent query results if the application reads during the propagation window.