Opening Scenario
Your team ships a feature that renames the users.username column to users.handle. Simple change. The migration runs in staging in 200ms. You deploy to production during a maintenance window.
The migration locks the table for 4 minutes. Your API returns 500s for every endpoint that touches users. Support tickets flood in. You roll back the migration — but now the new code is deployed with the old schema, and the new code references handle, not username. Your service is down.
Two weeks later, a different team runs ALTER TABLE orders ADD COLUMN discount_applied BOOLEAN NOT NULL DEFAULT false on a table with 50 million rows. It runs fine in staging (10,000 rows). In production, it locks the table for 7 minutes.
Both incidents were preventable. Both required understanding what the database actually does during a schema change.
Question Progression
Q1: Why did renaming a column lock the table?
Question: ALTER TABLE users RENAME COLUMN username TO handle…
In the full tutorial
- Closing: When to Reach for This