Runbook category
Schema migrations
Open this category when the change is a deploy, not a query. A migration window, a column type change, a constraint, a partition attach, or a CREATE INDEX that has to finish without taking the site down. Most migration outages are lock outages, not data outages, and they start from a DDL statement that looked harmless in staging.
The pattern repeats: a statement wants ACCESS EXCLUSIVE, waits behind one long reader, and every query arriving after it queues too. These runbooks show the non-blocking form of each change, NOT NULL without a full rewrite, NOT VALID then VALIDATE for CHECK constraints, CONCURRENTLY for indexes, detach and attach for partitions, filenode checks when you need to know whether a rewrite already happened. And how to recover when CREATE INDEX CONCURRENTLY fails halfway and leaves an invalid index behind.
Locking & concurrency is the runtime wait-graph skill you need when a migration is already stuck. Indexing is which index to add; this category is how to add or validate schema without a multi-hour outage. If the incident is an app deploy and the table is the blast radius, you are in the right place.
- Pro
Add a NOT NULL column to a huge table safely
SET NOT NULL grabs a strong lock, scans a huge table, and the deploy stalls behind it.
- Pro
Change a column type without a full table rewrite
ALTER COLUMN TYPE is instant on one column and a locked full rewrite on the next.
- Pro
Partition a growing table so the planner can prune
Every query has to consider the whole table because there is nothing to prune.
- Pro
Recover from a failed CREATE INDEX CONCURRENTLY
An invalid index left behind by a failed build: reads ignore it, writes still pay for it.
- Pro
Validate a CHECK constraint without a long lock
Adding a CHECK scans the entire table under lock and the migration times out.
- Pro
Detach and attach partitions with minimal locking
DETACH PARTITION queues behind one open reader and takes the parent table down with it.