☢️DROP DATABASE

Destroy an entire catalog

DROP DATABASE removes the database object and its contents, schemas, tables, roles that live inside that catalog, and associated files, subject to engine rules. Recovery requires backups or replicas; there is no “undo” in the SQL standard. Treat this as a break-glass operation in production, with tickets, MFA, and a verified backup restore path.

SQL

PostgreSQL: terminate sessions, then drop

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = 'sandbox_legacy' AND pid <> pg_backend_pid();

DROP DATABASE IF EXISTS sandbox_legacy;

✓Illustrative result set

result
DROP DATABASE

🛡️Guardrails

Automation-friendly vs footgun-friendly keywords.

Pattern	Why
IF EXISTS	Idempotent teardown scripts and CI ephemeral environments
Terminate / single-user / restricted session modes	Engines refuse DROP while connections exist, know your vendor’s session-kill story before on-call at 2 a.m.
Separate DSN naming	Prevents “staging script, prod DSN” disasters, color-coded clients and read-only defaults help.

DROP in a shared migration without environment gate

A down migration or cleanup task that drops a namesake database can erase the wrong environment when URLs are copy-pasted.

Require explicit env flag + human approval for prod

Split migration tools per environment, use break-glass roles, and emit alerts on any DROP DATABASE statement execution in audit logs.

After the drop

Update backup retention labels, remove monitoring dashboards, and revoke DNS or connection pool entries, orphan automation will otherwise hammer a dead endpoint forever.

TL;DR

DROP DATABASE destroys a database catalog and its objects, irrecoverable without a backup. Engines may refuse the command while sessions remain connected. Run it only from controlled migration tooling with snapshots taken first; follow with cleanup of users, connection strings, and automation that referenced the old name.