Adding a new column should be simple. In reality, it can break production if done the wrong way. Schema changes are one of the most dangerous operations in any database. A single blocking migration can lock tables, stall queries, and cascade into downtime. That risk scales with traffic, table size, and replication lag.
A new column in a relational database is more than metadata. How the engine stores it, whether it rewrites the table, and how defaults are handled depends on the database type and version. In PostgreSQL before 11, adding a column with a non‑null default rewrote the entire table. On large datasets, that was hours of blocking. In MySQL, even an apparently “online” schema change can trigger a full table copy if the column definition isn’t compatible with in‑place alteration.
Safe patterns exist. Add the new column as nullable, then backfill in small batches. Use database‑specific online DDL tools like PostgreSQL’s ALTER TABLE ... ADD COLUMN in later versions, MySQL’s ALGORITHM=INPLACE, or external migration tools like gh‑ost or pt‑osc. For high‑traffic systems, run dry‑runs against replicas and monitor query plans before and after. Treat every DDL as a deploy with rollback plans, metrics, and alerts.