Recovering from DROP DATABASE in Postgres

Whether you typed it yourself or your AI agent did, here's exactly what to do after a DROP DATABASE hit your PostgreSQL — best options first, honest about the rest.

First, in the next 60 seconds

  • 1. Stop all writes. Quit the app, pause the agent, and don't run another query — every write reduces what you can recover.
  • 2. Don't restart, vacuum, or checkpoint the database. Those steps can permanently overwrite recoverable data.
  • 3. Make a copy of the current state now (a dump, a snapshot, or the raw file) before you attempt anything.

What just happened

A DROP DATABASE removes every table, view and row at once. Recovery means restoring an entire backup or point-in-time copy — there is nothing left in the live database to salvage from.

Your recovery options in Postgres, best first

  • 1

    Roll back if the transaction is still open

    If the destructive statement ran inside a transaction that has not been committed yet, run ROLLBACK; in that same session and the change is undone instantly. Once COMMIT has happened, this is no longer possible.

  • 2

    Point-in-time recovery (PITR)

    If you have WAL archiving / continuous archiving enabled, restore a base backup and replay WAL up to the moment just before the bad statement (recovery_target_time). This is the cleanest recovery and loses only seconds of data.

  • 3

    Restore from a logical dump

    If you have a pg_dump / pg_dumpall file, restore it with pg_restore or psql into a fresh database, then copy back the affected rows or table.

  • 4

    Check your managed-host backups

    On RDS, Cloud SQL, Neon, Azure and most managed Postgres, automated daily snapshots and PITR exist in the console. Restore to a new instance and copy the data across — do not overwrite the live one yet.

If you have no backup

With no transaction to roll back, no WAL archive and no dump, committed Postgres data is effectively gone — there is no built-in "undo" after commit. Forensic tools like pg_filedump can occasionally salvage rows from disk pages that have not been overwritten or vacuumed, but treat this as a long shot, not a plan.

Make sure this never happens again

The honest truth: your coding agent will eventually run DROP DATABASE again. The fix isn't to trust it more — it's to keep an automatic, recent snapshot so a bad query is a 30-second rollback instead of a lost weekend.

OopsDB takes an encrypted snapshot of your PostgreSQL every few minutes and restores it with one command. It's free, open-source, and runs entirely on your machine — set it up in two minutes and the next DROP DATABASE won't cost you anything.

See how it works

Free & open-source for local backups · optional €8/mo cloud vault keeps a copy off your machine · cancel anytime.

Related recovery guides

Recover from DROP TABLE in Postgres Recover from DELETE without WHERE in Postgres Recover from TRUNCATE in Postgres DROP DATABASE in Supabase DROP DATABASE in MySQL DROP DATABASE in SQLite DROP DATABASE in Neon Cursor deleted my database
📋 The 8-step disaster checklist — print it before you need it
The exact first-10-minutes playbook from this guide, on one page. Get the link by email: