The migration ran clean until the moment it didn’t. One table threw an error. The cause was simple: we needed a new column.
Adding a new column is common, but the execution decides whether it’s fast, safe, and observable. In production, a schema change must account for table size, lock time, and compatibility with application code. Fail here, and downtime or data loss follows.
A new column can be added with SQL like:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
On small tables, this runs instantly. On large ones, blocking alters can freeze queries for minutes or hours. Engineers avoid that by using online schema change tools, zero-downtime migrations, or feature flags to gate usage. The sequence matters:
- Deploy code that tolerates the column’s absence.
- Add the new column without blocking queries.
- Backfill data in small, controlled batches.
- Switch application logic to use the column.
- Remove the old path only after confirming correctness.
Constraints, defaults, and indexes on the new column must be weighed carefully. Adding a default that writes to every row can be costly. Instead, add the column as nullable, backfill, then set the default. Index only when data is stable.
Version control for migrations reduces risk. So does monitoring the database during the change. Any alter that touches production data must be observable, logged, and reversible.
The difference between “it works” and “it works under load” is planning. A new column is not just a definition change — it’s a production event that can impact every dependent service. Treat it as such.
To see database migrations, schema changes, and new column deployments done right, visit hoop.dev and have it running in minutes.