推荐 DBX：25MB 的开源数据库客户端，管 100+ 种数据库，还能接进 AI

这两年别人问我「有没有好用的数据库客户端」，我一开始是回避的：手上的库越来越杂，MySQL、PostgreSQL、Redis、MongoDB、ClickHouse 各配一个客户端，许可证、平台限制、更新节奏全不一样，推荐谁都显得偏心。直到我把 DBX 用成了主力，并且以贡献者的身份给它写完了一整个 Salesforce 驱动之后，我可以不回避了：这就是我现在会第一个推荐的名字。

先给结论，再展开：

DBX 是一个开源的跨平台数据库管理工具，官方口号是「100+ databases in 25 MB」——桌面端（macOS / Windows / Linux）、Docker 自托管的 Web 版、CLI、内置 AI 助手和 MCP Server，五种形态共用同一套连接和同一套功能。仓库在 github.com/t8y2/dbx，文档在 dbxio.com。

它解决的真实痛点

数据库客户端这个品类很老，但痛点一直没变：

1. 一个库一个客户端。管三个以上的技术栈，桌上就摆着一排图标，每家的快捷键、导出格式、SSH 隧道配置方式都不一样。
2. 好用的大多收费或闭源。团队里新人入职第一天就要_license key_，或者只能装在某个平台上。
3. AI 时代的新缺口：Coding Agent 越来越强，但「让 Agent 安全地看一眼数据库」这件事，绝大多数客户端根本没想过——要么没有机器接口，要么一给就是全权限。

DBX 对这三条的回答分别是：manifest 驱动的统一驱动层、完全开源（含自托管）、以及从第一天就把 MCP 当一等公民。

架构：Rust 内核 + Vue 前端，一份代码五种形态

DBX 的内核是 Rust（驱动、schema 浏览、查询执行、导入导出都在 dbx-core），前端是 Vue 3 + TypeScript，桌面壳用 Tauri 2——所以安装包能压到 25MB 这个量级（官网主视觉的口径更狠：约 20 MB），和动辄上百 MB 的 Electron 同行放在一起对比很直观。Web 版是同一个前端加一个 Axum 后端，Docker 一行命令起服务；CLI 和 MCP Server 复用同一套内核逻辑，不存在「网页版功能残血」的问题。

驱动系统是 manifest 驱动的：每种数据库在 manifest 里声明自己的模式（native / file / agent）、能力集（是否支持 DDL、外键、触发器、文档模型……），UI 按能力渲染——不支持的标签页直接不出现，而不是点进去给你看一片空白。这种「能力自描述」的设计，是后面我写 Salesforce 驱动时体会最深的地方。

日常用得最多的几件事，它的完成度都对得起「主力工具」四个字：连接管理（分组、配色、SSH 隧道、断线自动重连）、schema 浏览、带补全和诊断的查询编辑器、可编辑的结果网格、导入导出、ER 图。破坏性操作有确认弹窗，连接配置可以加密导出——这些小地方才是客户端工具的分水岭。

AI 原生：MCP Server 是它最被低估的部分

DBX 单独发一个 Rust 写的 MCP Server，把你在 DBX 里配好的连接暴露给 Claude Code、Cursor 这类 Coding Agent：

{
  "mcpServers": {
    "dbx": { "command": "npx", "args": ["-y", "@dbx-app/mcp-server"] }
  }
}

关键设计是权限分档：在 DBX 设置 → MCP 里给每个连接选 Read only / Data read/write / Full access（机器值 read_only / safe_write / high_risk_write），并且有连接白名单。也就是说「Agent 能不能动我的库」是工具侧的策略，不靠提示词自觉。我自己的默认配置是：生产只读、沙箱可写，Agent 查数排错再也不用我把结果复制粘贴进对话里。

一个深度样本：我贡献的 Salesforce 驱动

推荐一个开源项目，除了功能，还要看它「接住贡献」的能力。我最近给 DBX 提交了 Salesforce（SOQL）支持（PR #10214），从 spec 到合并候选走完全流程，这段经历比任何 feature list 都能说明问题。

Salesforce 是个很好的压力测试：它的查询语言 SOQL 不是 SQL——不支持 SELECT *、不支持引号标识符、FIELDS(ALL) 必须带 LIMIT ≤ 200、OFFSET ≤ 2000；它没有「数据库」概念，只有 org 和对象；认证体系是 OAuth PKCE / Device Flow / 用户名密码（ROPC）/ 直接贴 token 四条路。这个驱动最后做成：

• 四种登录方式，client secret、refresh token、ROPC 密码全部走 DBX 已有的加密凭据存储，不明文落库；
• 方言层处理 SOQL 的怪脾气，网格「查看数据」走专用 builder 而不是把表名当 SQL 标识符硬引号；
• 网格行级增删改，保存前弹审阅弹窗，让你看清楚每一条即将发出的 REST 调用；
• MCP 侧的 DML 走两步确认：Agent 先拿到一个一次性令牌和待执行语句，人工确认后才真正写 org——未确认的写入永远到不了你的数据。

而项目本身的工程质量，是在这个过程里「被教育」的：先写 spec 再分里程碑实现；CI 是 nextest 矩阵加 clippy -- -D warnings，一个 await_holding_lock 就能把 PR 挡红；i18n 有自动翻译机器人盯着 11 个语言文件；maintainer 的 review 逐条核对凭据流向、PKCE 测试向量、分页是否静默截断，甚至提出「分页 cursor 虽然是 Salesforce 自己返回的 URL，但绝对地址还是应该校验同源」这种加固意见——我照做之后，他对 PR 的评价是「CI green and this merges」。一个外部贡献者能被这样接住，这个项目就值得你托付日常。

五分钟上手

桌面端去 Releases 下载安装即可（macOS / Windows / Linux 都有）。想团队共享或放服务器上：

docker run -d --pull=always --name dbx -p 4224:4224 \
  -v dbx-data:/app/data \
  t8y2/dbx:latest

国内拉镜像慢的话用 CNB 镜像 docker.cnb.cool/dbxio.com/dbx:latest。终端党：

npm install -g @dbx-app/cli   # 也有不依赖 Node 的原生二进制

装好之后建议的顺序：先连一个只读库熟悉界面 → 开 MCP 的 Read only 档接进你的 Coding Agent → 再按需放开写权限。HelloGitHub 和 Product Hunt 都推荐过它，社区活跃度不用担心。

也说说它不适合谁

诚实地讲：如果你只需要深度伺候某一种数据库（比如 Oracle 的 AWR 级诊断、SQL Server 的执行计划调优工作坊），官方或商业的专用工具仍然更深；DBX 的价值主张是「广而统一」加上「AI 可达」，不是在每个单一数据库上做最深的那把刀。另外它的 Web 版适合自托管在内网，不建议直接暴露到公网。

结语

工具推荐最怕的是「用了一周就写文章」。DBX 我是先当用户用成主力，再当贡献者把一个小语言生态（SOQL）完整接进去，最后才写这篇：它的统一体验解决眼前的杂，它的 MCP 设计解决即将到来的 AI 工作流，它的工程文化决定它三年后还在不在。三件事都答得上来的开源数据库客户端，目前我只见到这一个。

本文基于 DBX 0.6.x 与公开仓库信息撰写；Salesforce 部分对应 PR #10214（已通过 CI 与 maintainer review）。功能细节以官方文档为准。