u/vira28

Anyone who works on a production Postgres knows the feeling. Every command you run, you're walking a tightrope. One typo, one wrong terminal tab, one bug in the app that turned a filter into a full-table query, and now you're doing PITR or restoring from backup at 3am.

I've spent years as a DBA in charge of critical production workloads. Most of the time the rope holds. Sometimes it doesn't.

pg_savior is a Postgres extension that hooks the planner and refuses the obvious dangerous shapes:

• DELETE / UPDATE without a WHERE
• CREATE INDEX without CONCURRENTLY
• DROP DATABASE
• ALTER COLUMN TYPE that triggers a full rewrite
• DELETE WHERE id > 0 (planner row estimate gives intent away)

When you really mean it: SET LOCAL pg_savior.bypass = on for the transaction, and the guard steps aside.

It's an extension, not a proxy — psql against a local socket, ORMs, migration tools, cron jobs, AI agents with DB credentials all hit the same hook. Nothing routes around it.

Three hooks do the work: post_parse_analyze_hook, ExecutorStart_hook, ProcessUtility_hook.

• Code: https://github.com/viggy28/pg_savior
• Design notes: https://viggy28.dev/article/pg-savior-seatbelt-for-postgres/
• PGXN: https://pgxn.org/dist/pg_savior/

What other dangerous queries should pg_savior catch? Also, curious if you have best practices to catch these mistakes.