PGthesev1database
ErrorsTriageCookbook
ArchitectureLessonsInterview
Pricing
Runbooks/Schema migrations

Runbook category

Schema migrations

Most migration outages are lock outages, not data outages. The pattern repeats: a DDL 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 VALID then VALIDATE, CONCURRENTLY, filenode checks — and how to recover when one fails halfway.

  • 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.

    Pro

Other categories

Query performance16Indexing9Vacuum & bloat8Locking & concurrency7Observability16WAL & replication7

Browse all runbooks →

thesev1database

Evidence-first PostgreSQL reference. Every claim is reproduced in a Docker lab and cited back to the official manual — no hand-waving.

Firefight

ErrorsTriageCookbook

Learn

ArchitectureLessonsPathwaysLibrary mapGlossaryGUCsInterview prep

More

PricingSign in

Company

ContactTermsPrivacyRefunds