DROP SCHEMA or DROP DATABASE in a migration

Critical — this fails outright or takes production down.

What it catches

Dropping a schema removes every object in it in one statement — with CASCADE, without even listing them. Dropping a database is the same at a larger radius. Neither belongs in schema history; both are irreversible.

Fires on

DROP SCHEMA app CASCADE;

Do this instead

Quarantine before deleting: rename the schema, let it soak while anything still depending on it surfaces, then drop its objects explicitly in small reviewed migrations. DROP DATABASE never belongs in schema history at all — that is an operator action with backups verified first.

-- Quarantine first, delete later:
SET lock_timeout = '5s';
ALTER SCHEMA app_legacy RENAME TO app_legacy_deprecated;
-- after a soak period, drop its objects explicitly, a few per
-- reviewed migration — never the whole schema with CASCADE

Catch this before it ships

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

Browse all 69 rules

← BV026 BV028 →