pgbot：5.9MB 的开源 Postgres 体检工具，让 AI 直接告诉你数据库哪里病了

原文来源：pgbot.dev — 一个只读连接 Postgres、用 AI 辅助输出健康报告的开源可观测性工具。

"没人读数据库指标。pgbot 读。"——这是 pgbot 官网的第一句话，也是这个项目想解决的问题。数据库的健康状态其实一直有答案：慢查询、锁等待、缓存命中率、WAL 增长，Postgres 自己的统计视图里全都有。问题是这些指标散落在几十张视图里，日常根本没人看。pgbot 做的事情很简单：一个 5.9MB 的静态二进制，只读连上你的 Postgres，把统计视图翻译成一份"发现优先"的健康报告。

项目 2026 年 8 月中旬发布在 GitHub 上，两周多已经攒了 600+ star，Apache-2.0 许可，支持 Postgres 14 到 18。

用起来什么样

安装就是一行命令：

curl -fsSL https://pgbot.dev/install | sh

然后连上数据库跑一次体检：

pgbot inspect "postgres://pgbot_ro@host:5432/db"

输出不是密密麻麻的指标表格，而是一份分级报告，类似这样：

Database health: 82/100

CRITICAL
● transaction-id age 1.8B — 84% toward wraparound

WARNING
● orders queries 3.2× slower (8 → 26 ms mean)
● 3 unused indexes consume 18 GB
● connection usage reached 87%

GOOD
● cache hit ratio 99.4%
● replication healthy
● no deadlocks

问题按严重程度分成 CRITICAL / WARNING / NOTE 三档，健康的子系统也列出来并附上数值——"一个会说它查过什么的工具，读起来像一位真的看过的同事，而不是一个报警器"。连接字符串也可以放到环境变量里，避免密码出现在 shell 历史和 ps 输出中。

它到底查什么

pgbot 的检查覆盖四块：

• 数据库实时健康：连接数、锁、事务、缓存命中率、复制状态、WAL、事务 ID 年龄（防 wraparound 那个经典坑）
• 查询性能：慢查询、性能回归、吞吐、延迟、昂贵 SQL——全部基于 Postgres 自己的统计信息
• 表和索引：表增长、索引使用情况、未使用索引、缺失索引、vacuum 活动、存储模式
• 变化对比：报告会和上次运行对比，告诉你"什么变了"——这正是排障时最想要的答案

命令行还有 queries、indexes、lint 等聚焦子命令。lint 只做 schema 级检查，空数据库的 CI 环境也能跑。

可选但很有意思的 AI 层

不用 AI 的话，pgbot 全功能都是确定性的：不联网、不需要 API key、数据不出机器。AI 层是可选开关，配一个 key 就能用：

export OPENAI_API_KEY=sk-...    # 或 GEMINI_API_KEY
pgbot ask "what's wrong?"
pgbot explain "orders queries are 3.2x slower"

ask 用自然语言提问，explain 针对具体发现给解释和建议，回答都基于真实的数据库信号，不是凭空生成。

更值得关注的是它的 MCP 支持：pgbot mcp 命令可以把这些发现通过 MCP 协议暴露给 AI agent。也就是说，你的 coding agent 或运维 agent 可以直接把"数据库体检"作为一项工具调用——让 agent 自己去看数据库出了什么问题，而不是等它猜。

设计上的两个坚持

只读。 连接只授予只读权限（README 建议用一个带 pg_monitor 角色的专用账号），路径中任何环节都没有写权限。对数据库这种动辄出生产事故的东西，这个设计底线很让人安心。

数据本地。 核心功能零外部依赖，报告在本机生成。只有你主动开启 AI 层，prompt 才会发给模型服务商。

适合谁用

如果你符合下面任何一条，pgbot 值得放进工具箱：

• 没有专职 DBA 的小团队——这是最常见的场景。几个命令就能知道数据库今晚会不会出事，而不是等监控告警炸了才去翻 pg_stat_activity
• 想给 AI agent 加数据库能力的开发者——MCP 接口让 agent 能自主做数据库巡检
• CI 里想加数据库健康门槛——--fail-on=critical 让问题变退出码，还能输出 SARIF 直接传 GitHub Security tab，--fail-on-new 可以在 migration PR 上只报新增问题
• 本地开发的自托管数据库——一条命令体检，比开一整个监控栈轻量得多

它不适合的场景也有：需要写操作、需要跨集群的完整监控大盘、或者你对 AI 解释的准确性有绝对要求（beta 阶段，AI 层输出建议人工确认后再动手）。

顺带一提，这类"只读体检 + AI 解读"的工具最近在 Hacker News 上讨论度不低——数据库可观测性正在成为 AI agent 落地的一个真实场景，pgbot 是其中做得比较克制、定位清晰的一个。