DBHub vs Bytebase MCP：数据库Agent接入方案对比

我们维护着两个数据库 MCP 服务器：DBHub 和 Bytebase 内置的那个。经常有人问该用哪个，答案是：只有你一个人受影响时用 DBHub，有其他人会受影响时用 Bytebase MCP。

注意这和「开发环境 vs 生产环境」不是一回事。只有你一个人访问的只读副本放在 DBHub 上没问题；加载了真实客户数据副本的 staging 数据库就不行。真正重要的是——如果 agent 做了它能做的最坏的事，谁来买单。

剩下的就是这一个差异，所有其他区别都从它而来。

共享账号 vs 个人账号

DBHub 接收一个连接字符串。实际上那是一个共享的服务账号，通常是你的应用已经在用的那个，每个指向它的 agent 都以同一个账号连接。

Bytebase MCP 采用 OAuth 登录。agent 以你的身份连接。

所以当你的 agent 在凌晨两点执行一条 DELETE 时，DBHub 的数据库日志里写的是 app_user，和其他所有共享该账号的人的查询一样。你知道这事发生了，但不知道是谁做的，而且你无法只撤销一个人的权限而不撤销所有人的。Bytebase 则会把日志记在你的账号名下。

一条命令，无需服务器：

npx @bytebase/dbhub@latest --transport stdio --dsn "postgres://user:pass@localhost:5432/mydb"

默认提供两个工具：运行 SQL 和搜索 schema，这样你的上下文窗口可以留给真正的问题。Postgres、MySQL、MariaDB、SQL Server 和 SQLite，多个连接在一个进程里。可以启动为只读模式，可以限制返回行数，可以设置查询超时。

但没有身份标识。只读是进程层面的一个标志，所以它保护的是你（免受 agent 伤害），而不是启动进程的那个人。

无需安装任何东西。如果你跑了 Bytebase，它就在 /mcp，你的 agent 继承你的账号，而你的账号上本来就有规则：脱敏列会返回 *****、schema 变更会打开审查而不是直接执行、每次调用都会以你的名义记录。

值得直说：它继承你所有的权限。以你自己的身份连接只有在你不是管理员时才有用。

DBHub 没有可供授予或撤销的个人访问权限、没有列脱敏、在写操作开启时 agent 和数据表之间没有任何阻断。

Bytebase MCP 需要 Bytebase 在运行且配置了外部 URL，而且只支持 HTTP。无法对 SQL 做 dry-run，因为检查发生在变更创建时。结果默认限制 100 行，最多 1000 行，超时 30 秒。

本地 Postgres、临时副本、主库的只读副本、只读探测生产库：用 DBHub。真实客户数据、需要脱敏的列、写操作需要有人先过目：用 Bytebase MCP。

说实话，两个都用才是常态。本地工作时在客户端配置里用 DBHub，共享场景用 Bytebase MCP。真正要避免的是中间地带——一个恰好连到生产库的连接字符串，因为粘贴起来最快就被放进了 MCP 配置。