The query ran for eight seconds before failing. Someone had added a new column, but nothing downstream knew it existed. Logs filled with errors. Dashboards went dark. This is what happens when schema changes lag behind the code that depends on them.
A new column is never just a column. It is schema evolution. It is query shape changes. It is pipeline dependencies, cache keys, serializers, and tests. If you treat it like a single migration step, you are already behind.
When you add a new column in production, you must think about deployment order. Apply the migration first. Deploy the code that writes and reads it later. Keep backward compatibility during the overlap. Avoid dropping old paths until you have confirmed all consumers use the new shape.
In relational databases, a new column without defaults can lock large tables during writes. Adding it with NULL allowed can be safer, then backfill in small batches. Track read/write metrics to verify adoption. In NoSQL systems, a new column means new document fields that may not exist in older records. Handle them in application logic until the migration completes.