ban-drop-database

What triggers it

Fires on any DropdbStmt — every DROP DATABASE statement, unconditionally.

What does not

Only non-DropdbStmt nodes are skipped; there is no other condition, so a DROP DATABASE statement is always flagged regardless of missing_ok or the database name.

Where it applies

Applies to every PostgreSQL version MigrationPilot targets. It works on the SQL text alone — no database connection needed.

The lock, and what it blocks

The rule does not characterize this by lock behavior. DROP DATABASE sits outside the normal table-locking model (PostgreSQL simply refuses if other sessions are connected to that database). The real risk is that there is no undo.

Why it matters

DROP DATABASE is the most destructive operation possible. It permanently removes the database and all its contents. This should never appear in a migration file.

Unsafe, and safe

DROP DATABASE production;

-- Never DROP DATABASE in a migration file

What it assumes

Assumes any DROP DATABASE in a migration file is a mistake, which holds for essentially all application migrations; it cannot distinguish that from a deliberate administrative script that happens to be checked in alongside migrations.

What backs this rule

Every rule is a claim about PostgreSQL, so it carries what the claim rests on: a handbook chapter that cites the manual, the incidents that put it there, and the version it was last checked against.

What the CLI prints

✗ [MP034] CRITICAL (line 1)
  DROP DATABASE "production" permanently destroys the entire database. This should never appear in a migration file.

  Safe alternative:
  -- DROP DATABASE should never be in a migration file.
  -- If you need to reset a database, use a separate administrative script.

  Why: DROP DATABASE permanently and irreversibly destroys the entire database including all tables, data, indexes, and extensions. If this statement appears in a migration file, it almost certainly indicates an error. There is no undo.
  Docs: https://migrationpilot.dev/rules/mp034

Generated by running the CLI's own formatter over the flagged example above, so it is the text the tool actually produces. A real run also reports the other rules that fire on the same statement; those blocks are left out here.

Turning it off

For one statement, put a comment on the line before it:

-- migrationpilot-disable MP034
DROP DATABASE production;

For the whole project, in .migrationpilotrc.yml — by name or by id:

rules:
  MP034: false

# or keep it, and downgrade it
rules:
  MP034:
    severity: warning

Try it

Open this rule's flagged example in the playground. It runs in your browser — edit it and watch the finding appear and disappear.

Related rules

• MP035ban-drop-schemaDROP SCHEMA is similarly destructive
• MP026ban-drop-tableDROP TABLE destroys individual tables
• MP022no-drop-cascadeCASCADE amplifies destructive operations