Can I undo UPDATE without WHERE in Postgres?

If it ran in a transaction that isn't committed yet, run ROLLBACK. Once committed, you can only recover from a backup, a database log (PITR / binlog / WAL), or a managed-host snapshot — covered step by step above.

An AI agent (Cursor / Claude Code) ran it — does that change anything?

No. The recovery is identical regardless of who ran the query. What matters is whether the change was committed and whether you have a backup or log from before it. Agents do make this far more likely, which is why an automatic snapshot tool is worth setting up.

How do I stop this happening again?

Keep automatic, recent snapshots. OopsDB snapshots your Postgres every few minutes and restores in one command, so a destructive query becomes a quick rollback. It's free and runs locally.

Recovering from `UPDATE without WHERE` in Postgres

Whether you typed it yourself or your AI agent did, here's exactly what to do after a UPDATE without WHERE 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

An UPDATE with no WHERE overwrites a column in every row. The rows still exist but the old values are gone unless the transaction is still open (ROLLBACK) or you have a backup/log to compare against.

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 UPDATE without WHERE 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 UPDATE without WHERE 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 UPDATE without WHERE in Supabase UPDATE without WHERE in MySQL UPDATE without WHERE in SQLite UPDATE without WHERE in Neon Cursor deleted my database

Recovering from UPDATE without WHERE in Postgres

First, in the next 60 seconds

What just happened

Your recovery options in Postgres, best first

Roll back if the transaction is still open

Point-in-time recovery (PITR)

Restore from a logical dump

Check your managed-host backups

If you have no backup

Make sure this never happens again

Related recovery guides

Recovering from `UPDATE without WHERE` in Postgres