The ALTER TABLE that took down our API for 6 minutes

Last Tuesday at 2:47 PM, we deployed a migration that looked completely innocent: ALTER TABLE users ADD COLUMN email_verified boolean NOT NULL ; CREATE INDEX idx_users_email ON users ( email ); Two statements. Nothing exotic. The kind of thing you've written a hundred times. At 2:48 PM, every API endpoint that touched the users table started timing out. Our health checks went red. PagerDuty fired. Customers couldn't log in. At 2:54 PM — six minutes later — the migration finished and everything recovered on its own. The root cause wasn't a bug. It was a lock. What actually happened Every DDL statement in Postgres acquires a lock on the table it modifies. The lock type depends on the statement: Statement Lock Mode What it blocks ADD COLUMN ... NOT NULL (no DEFAULT) ACCESS EXCLUSIVE Everything — reads, writes, DDL CREATE INDEX (no CONCURRENTLY) SHARE All writes SELECT ACCESS SHARE Nothing ACCESS EXCLUSIVE is the nuclear option. It blocks every other operation on the table — including simp