I've started letting Claude Code and Codex work against my dev databases, and the part that worried me was the database itself. Claude Code checkpoints rewind files. A bad DELETE stays done. Permission prompts help, but they live in the client, and an agent can always reach for psql instead.
pgbrake is a small MCP server the agent uses in place of direct database access. Every statement goes through the real Postgres parser (pglast). Normal writes run and return a change id. Before an UPDATE or DELETE it saves the affected rows locally, so pgbrake undo <id> puts them back, and it refuses if those rows changed since.
DDL, UPDATE/DELETE without WHERE, and anything touching more than 100 rows wait for a human: the client's own prompt, or pgbrake approve <id> in a terminal. That command refuses to run without a TTY, so the agent can't approve its own SQL. Every statement and decision lands in a local audit log. Nothing leaves your machine.
MIT, Python:
pip install pgbrake
claude mcp add pgbrake --env PGBRAKE_DSN="postgresql://me@localhost/app" -- uvx pgbrake serve
Limits: undo only covers changes made through pgbrake. TRUNCATE and DDL can be held but not undone. It doesn't replace backups. I've only tested on Postgres 17 so far.
I'd like to hear where it breaks. I'm also thinking about a paid add-on that catches migration commands like prisma migrate reset --force (snapshot first, then ask). Would that be worth a one-time $29 to you?
Top comments (1)
Anything over 100 rows waiting for a human is a clear tripwire, but undo refusing when those rows changed since leaves the riskiest case unrecovered. If a migration or a second agent touches them first, the safety net fails exactly when it is needed most.