The schema broke the moment you pushed the latest migration. A single missing field. One new column.
Adding a new column sounds simple. In production, it’s not. Every database type handles schema changes differently. Postgres can lock rows. MySQL may rebuild entire tables. On large datasets, this can mean downtime, blocking queries, and frustrated users refreshing their screens.
The first rule: know your data store. In PostgreSQL, ALTER TABLE ... ADD COLUMN is fast if the column has no default and is nullable. Adding a default or NOT NULL forces a rewrite, so avoid that unless necessary. In MySQL with InnoDB, adding a column can trigger a table copy unless you’re on a recent version with instant DDL. Even with “instant” modes, check for hidden compatibility caveats.
The second rule: think about application code. Adding a new column is not just a database operation; it’s a feature rollout. You must handle old data, write migrations that can run online, and deploy code that tolerates missing or null values until backfill completes. In distributed systems, read replicas may lag in schema updates, creating mismatches if code assumes the column exists everywhere.