Database-wide REINDEX in a migration
Critical — this fails outright or takes production down.
What it catches
REINDEX SYSTEM and REINDEX DATABASE rebuild every index in the database, system catalogs included — and catalog indexes can never be rebuilt concurrently, so their rebuild takes locks that stall catalog lookups for every session. Runtime scales with total index volume across the database. Whatever a migration needs, it is never this; rebuild the specific index or table instead.
Fires on
REINDEX DATABASE app;Do this instead
Rebuild only what is actually bloated or corrupt, online: REINDEX INDEX CONCURRENTLY or REINDEX TABLE CONCURRENTLY (Postgres 12+), each alone in its own migration outside a transaction. Catalog/system reindexing is a superuser maintenance action for a window, never schema history.
-- Own migration, outside a transaction (PG12+):
REINDEX INDEX CONCURRENTLY idx_orders_region;
-- or per table: REINDEX TABLE CONCURRENTLY orders; This rule runs in the hosted service on Startup and above — add --remote with a team token, or use the GitHub Action: npx bolvrk check migration.sql