Adding a new column should be fast. It should not trigger downtime. It should not require long planning sessions. Yet too often, this basic step slows releases, creates migration conflicts, or forces schema freezes.
A new column in a relational database alters the table definition. In PostgreSQL, ALTER TABLE ADD COLUMN is straightforward for nullable fields with defaults set to NULL. But adding NOT NULL columns, large defaults, or indexed fields can lock writes and reads. At scale, these locks can mean minutes or hours of blocked traffic.
For MySQL and MariaDB, the impact depends on the storage engine. InnoDB supports ALGORITHM=INPLACE or INSTANT modes, which avoid full table rebuilds. Knowing these modes and their limitations reduces risk.
Column additions also break downstream systems when schemas are consumed by services, ETL jobs, or APIs. A new column can change serialization formats, increase payload sizes, or break deserialization logic if consumers are strict. The safest approach is to add columns in a backward-compatible way. Deploy schema changes before code that writes to them. Deploy code that reads from them before removing fallbacks.