You ran the migration. The build passed. Then the system stalled in production. Queries slowed, indexes broke, and jobs backed up. Adding a new column is never just adding a new column. It’s a structural change, and structure resists change.
In relational databases, a new column can impact storage layout, query planners, and application logic. On large tables, it can trigger full table rewrites that lock writes and block reads. Even when the migration runs online, downstream systems may fail if the code expects the old schema. Adding columns to high-traffic production systems without a plan risks downtime, data drift, or split-brain state between code and data.
Best practice is to ship schema changes in stages. First, add the new column in a backward-compatible way. Avoid NOT NULL constraints and heavy indexes at creation. Then, deploy code that writes to both old and new columns. Backfill data in batches to avoid locking. Only after the system runs stably should you switch reads to the new column, drop the old one, and tighten constraints.