pgbrake 为 AI 数据库操作增加撤销机制

让 Claude Code、Codex 连接开发数据库，文件改坏了可以回退，误删的数据却未必能找回来。pgbrake 想补上这个缺口：把 SQL 执行收进一个 MCP 服务，修改前留存数据，危险操作交给人确认。

它的价值在于把确认、撤销和审计放到数据库操作路径里。但这个「撤销键」有明确边界：只覆盖经过 pgbrake 的修改，DDL 和 TRUNCATE 也不能撤销，目前作者只在 Postgres 17 上测试过。

文件能回退，为什么数据库还需要单独保护

作者开始让 Claude Code 和 Codex 操作开发数据库后，担心的是数据库状态。Claude Code 的检查点可以回退文件，却不能让已经执行的错误 DELETE 自动恢复。

客户端的权限弹窗有帮助，但执行入口不止一个。Agent 如果转而调用 psql，原来那套确认流程就可能被绕开。

pgbrake 的做法是提供一个小型 MCP 服务，让 Agent 通过它访问数据库。每条语句都交给 pglast 解析，也就是先识别 SQL 的实际结构，再决定是否执行。相比只匹配几个危险关键词，这更贴近 SQL 真正要做的事情。

下面两条命令完成安装，并为 Claude Code 注册服务：

pip install pgbrake
claude mcp add pgbrake --env PGBRAKE_DSN="postgresql://me@localhost/app" -- uvx pgbrake serve

要看清第二行的 PGBRAKE_DSN：它指定服务连接哪个数据库。原文给出了 Claude Code 的接入命令，没有展示 Codex 的配置方式。

哪些操作能撤销，哪些必须先问人

普通写入执行后，pgbrake 会返回一个变更 ID。执行 UPDATE 或 DELETE 前，它先把受影响的行保存在本地，之后可以通过 pgbrake undo <id> 恢复。

这里还有一道冲突检查：如果这些行在操作之后又发生了变化，撤销会被拒绝。这样可以避免把后续修改直接覆盖掉，但也表示撤销失败时仍需要人工处理。

能撤销，不等于任何时候都能恢复。

以下操作会等待人工确认：

• DDL，也就是建表、改表等数据库结构操作。
• 不带 WHERE 的 UPDATE 或 DELETE。
• 涉及超过 100 行的操作。

确认可以走客户端弹窗，也可以在终端执行 pgbrake approve <id>。作者表示，后者没有 TTY 就拒绝运行，以此阻止 Agent 自行批准 SQL。TTY 可以理解为交互式终端环境；这一限制能否覆盖具体 Agent 的运行方式，原文没有提供验证过程。

所有语句和决策都会进入本地审计日志。作者也明确表示，数据不会离开本机。

我的判断

我认同把保护放到执行路径里的方向。相比只在提示词里要求 Agent「不要误删」，解析、留存和拦截至少是程序可以执行的规则。相比每次写入都弹窗，它也试图让普通操作继续运行，把人工注意力留给风险更高的语句。

但前提是，操作确实经过 pgbrake。如果 Agent 仍能通过 psql 直接写库，这套保护就存在绕行入口。 原文没有说明如何限制数据库凭据和其他访问通道，不能仅凭 MCP 接入就认定所有操作都受控。

另外，超过 100 行需要确认，是产品规则，作者没有给出阈值的对照数据。十行重要配置也可能比几百行测试数据更敏感。原文同样没有提供性能、并发或复杂 SQL 的测试结果，只说明目前测试过 Postgres 17。

撤销也不能替代备份：TRUNCATE 和 DDL 可以拦住等待确认，却不能撤销。作者提出的迁移命令保护仍是付费扩展设想，例如捕获 prisma migrate reset --force，先做快照再询问，询价为一次性 $29，不能当成现有能力。

能拿来做什么

• 给 Claude Code 接入开发数据库时，可以先在可丢弃的数据副本上试用，验证误删后执行 pgbrake undo <id> 的恢复过程，以及行被再次修改后的拒绝行为。
• 在 Node 或全栈项目中，可以检查 Agent 是否还持有直接写库的凭据、是否还能调用 psql，确认实际数据库操作是否经过 pgbrake。
• 涉及 DDL、TRUNCATE 或迁移重置时，继续保留独立备份和恢复流程；不要把本地变更记录当成完整的数据库恢复方案。