The migration hit production at 03:12. The system needed a new column.
A single schema change can cripple services if executed poorly. Adding a new column is never just altering a table—it’s altering a running engine. The stakes rise with scale. The speed of your deployment matters. The impact of your defaults matters. The locks taken during the ALTER operation can determine whether your API stays online or goes down.
When you create a new column, decide if it will allow NULL. Adding a non-null column without a default forces every existing row to update immediately, which can cascade into heavy writes. On large datasets, this can stall replication and block reads. For mission-critical systems, use an online schema change tool or apply changes in stages.
In distributed systems, altering a table with a new column across nodes can create version drift. A single node running outdated code may throw errors when reading or writing to the altered table. Always coordinate schema changes with deployment order. Avoid schema-first changes unless the new version handles both the old and new structure gracefully.