DBX 是最近让我把 Navicat 和 DataGrip 都从 Dock 栏挪走的工具。连接在 DBX 里配一次，它自带的 AI 助手、给 Claude Code 用的 MCP、终端里的 CLI 都能直接用，MCP 还能精确管到"哪个分组、哪个连接、哪个库、只读还是可写"。想出个临时报表，一句话交给 AI，它自己查数、自己画图。
开源免费，macOS / Windows / Linux 三端通用，装好只有 77 MB。项目才半年，功能却很全，国产数据库和 Nacos、RocketMQ 这些国内常用的中间件都照顾到了。
一、为什么换掉 Navicat 和 DataGrip
我的情况：手上常年挂着几组 dev / prod 的 MySQL 和 Redis，写代码主要靠 Claude Code，查库也越来越多地交给它。
Navicat 用了很多年，好用，但三个问题越来越明显：
- 体积大。装好占 1.1 GB，DBX 只有它的零头。
- AI 出不了窗口。Navicat 17、18 都有 AI 助手，能写 SQL、解释和修复语句，但只服务 Navicat 自己的界面。Claude Code 想查库，Navicat 帮不上：截至 2026 年 9 月发布的 Navicat 18，我没找到 MCP 相关功能。
- 连接要维护两份。为了让 Claude Code 能查库，我之前推荐过 DBHub。它能用，但每个库的地址、账号、密码要在
dbhub.toml里再写一遍。Navicat 一份、DBHub 一份，改一次密码要改两处。
DataGrip 也用了很久。它的 AI 集成是这几个里最接近 DBX 的：从 2025.2 起内置 MCP Server，Claude Code、Codex 能直接用 DataGrip 里配好的连接，今年还加了数据库相关的 Agent Skills。但用下来也有几个绕不开的问题：
- 太重。它是一个完整的 JetBrains IDE，macOS 安装包将近 1 GB，IntelliJ 家的软件打开就至少占 1 GB 内存；工具窗口和设置项多，只是查个数也要开一整个 IDE。
- MCP 离不开 IDE。MCP Server 集成在 IDE 里，Claude Code 想查库，DataGrip 就得开着。
- 权限太粗。给 AI 的权限只有几个全局开关，作用于所有库，没法按库区分。
DBX 把这几点都照顾到了：体积小、上手快、功能全，同一份连接配置同时给 GUI、内置 AI 和 MCP 用。免费开源是附带的好处，不是我换过来的主要原因。
二、DBX 是什么
DBX 是一个开源（Apache-2.0）的轻量数据库客户端，核心用 Rust 写，桌面端基于 Tauri 2。官方的定位是"100+ 数据库，25 MB，桌面、Docker、CLI、内置 AI 助手和 MCP Server 都有"。
叫它 AI Native，是因为 AI 在这里不只是侧边栏里的一个聊天框：内置助手能直接查数、画图；外部的 Claude Code、Codex 通过 MCP 用同一份连接；CLI 还自带一个给 Agent 用的 Skill（dbx agent setup 安装到 ~/.agents/skills/dbx）。
几个数字，我在 macOS Apple Silicon 上实测（DBX v0.6.60 / v0.6.61）：
| 项目 | DBX | Navicat Premium 17.3.5 |
|---|---|---|
| 价格 | 免费开源 | 订阅 500~1000 美元/年 |
| 安装包 | macOS dmg 43 | — |
| 装好后磁盘占用 | 77 MB | 1.1 GB |
| 空闲内存（含 WebView 进程） | 约 720~770 MB | 约 110 MB |
| MCP | 有 | 无 |
体积：官方说 25 MB，实际安装包 3047 MB、装好 77 MB，口号偏乐观，但和 Navicat 的 1.1 GB 比仍然差了一个数量级以上（DataGrip 我已经卸了，官方 2026.2 版的 macOS 安装包也有 980 MB1 GB）。DBX 小，是因为不带 JRE、不带 Chromium：Tauri 用系统自带的 WebView 渲染界面。连 Oracle、达梦这类走 JDBC 的库时要另装对应的驱动和 JRE，这部分没算在内。
内存不是它的强项。Tauri 应用的界面跑在系统的 WebKit 进程里，活动监视器里只看 dbx 进程，只有 80 MB 左右，容易误判。我用 macOS 的 footprint 把归属 DBX 的 WebKit 进程一起算上，合计 700 MB 出头，其中渲染进程就占了 500 MB 左右；同一台机器上刚启动、还没连库的 Navicat 约 110 MB。我的 DBX 窗口开得很大，图形内存会偏高，所以这不是严格对照，但量级差异是真实的。官方仓库里有专门的运行内存排查报告，一直在优化，在意内存的话先有个预期。
更新频繁：仓库 2026 年 4 月底才创建，半年打了 181 个版本 tag。10 月 17 日到 29 日从 v0.6.47 发到 v0.6.61，基本一天一版。GitHub 上已经 2.8 万 star。
更新快对 AI Native 的工作流很重要。模型和 Agent 工具每个月都在变，客户端得跟得上：9 月 DBX 加了 AI 回复里直接渲染图表，MCP 工具也从 SQL 一路扩到了 Redis、Kafka、Nacos、Consul。代价是 bug 也不少，第七节单独说。
三、新项目，但功能全、接地气
操作简单：这是我用下来感受最明显的一点。界面没有多余的东西，常用操作右键都能找到，MCP、AI、同步在设置里各有独立入口，从 Navicat、DataGrip 过来基本不用看文档。DataGrip 功能更深，但工具窗口和设置项多，找功能要花时间。
图 1：数据表格里右键就能排序、筛选、批量修改、克隆行和导出，不用到菜单栏里找（图片来自 DBX 官方文档）。
功能却不少：项目才半年，日常用得到的基本都有了：ER 图、表结构编辑、Schema 对比、数据对比、跨库数据传输、执行计划、字段血缘、SQL 文件执行、CSV / Excel 导入，拖一个 Parquet 文件进来能直接预览。Oracle 可以调试 PL/SQL，MySQL、PostgreSQL、openGauss 可以设定时备份。不是 SQL 的系统也没有硬塞进一个查询框：Redis、MongoDB、Elasticsearch 有专门的浏览器，Kafka、RabbitMQ、Pulsar、MQTT、ZooKeeper、etcd 有独立控制台。S3、Kubernetes、LDAP 这类能力通过插件商店接入。
图 2：关系图按外键自动画出表之间的引用，可以搜索表和字段、导出图片（图片来自 DBX 官方文档）。
很接地气，看得出是照着国内开发者的日常需求做的：
- 国产数据库覆盖全：达梦、人大金仓、openGauss、GaussDB、OceanBase、TiDB、TDengine、虚谷、瀚高、崖山、GBase 都能连。
- 国内常用的中间件有控制台：Nacos 能看配置和服务，RocketMQ 能查 Topic、消费组和消息。
- 迁移成本低：能导入 Navicat 的
.ncx连接（DataGrip、DBeaver、Another Redis Desktop Manager 的也行），MySQL、PostgreSQL 的备份还能直接输出 Navicat 的.nb3格式。 - 国内服务直接能用：同步可以走坚果云 WebDAV 或 Gitee，AI 预设里有 DeepSeek、通义千问、MiniMax，中转站的兼容接口也能直接填。
- 国内网络友好：Docker 有 CNB 国内镜像，MCP 安装脚本在 npmjs 不通时会自动换到 npmmirror。
- 部署方式多：1Panel 应用商店可以一键装 Web 版，有飞牛 NAS 的安装包，Windows 还有支持 Win7 / Server 2012 R2 的离线安装包。
图 3：新建连接时，TiDB、OceanBase、openGauss、GaussDB、人大金仓这类兼容库单独分组，不用在一长串列表里找（图片来自 DBX 官方文档）。
四、MCP：DBX 里配好的库，Claude Code 直接能用
这是我换过来的主要原因。
图 4：连接只在 DBX 里存一份，四个入口都从这里读；MCP 这条路多一道权限策略。
和 DBHub、DataGrip 比
DBHub 的多库配置大概是这样，每个库一段，密码用环境变量注入：
# dbhub.toml
[[sources]]
id = "dev"
dsn = "mysql://root:${DEV_PASSWORD}@10.0.0.12:3306/app"
[[sources]]
id = "prod"
dsn = "mysql://readonly:${PROD_PASSWORD}@prod-db.example.com:3306/app"
[[tools]]
name = "execute_sql"
source = "prod"
readonly = true
DBX 的 MCP 直接读 DBX 自己的连接存储，客户端配置里只有一个可执行文件路径：
{
"mcpServers": {
"dbx": { "command": "/Users/你的用户名/.dbx/bin/dbx-mcp" }
}
}
在 DBX 里新加连接、改密码，MCP 这边不用跟着改任何配置。
公平地说，DBHub 有它的位置：不依赖任何 GUI，一个 DSN 就能跑，适合服务器、CI 这类没有桌面的环境，还能在 TOML 里定义带参数的自定义 SQL 工具。DBX 的 MCP 依赖 DBX 的连接存储，要么本机装了 DBX 桌面端，要么部署了 DBX Web（用 DBX_WEB_URL 指过去）。不过桌面端不需要一直开着，MySQL、PostgreSQL、Redis、MongoDB 这类常见连接由 MCP 进程自己直连执行。
DataGrip 的思路和 DBX 一样，也是复用 IDE 里已有的连接，在 Settings → Tools → MCP Server 里打开，Claude Code、Codex 可以一键自动配置。区别有两点：
- 要不要开着客户端。DataGrip 的 MCP Server 集成在 IDE 里，用的时候 DataGrip 得开着；DBX 的 MCP 是独立的二进制，桌面端关了也能查。
- 权限粒度。DataGrip 给 AI 的数据库权限是几个全局开关（读数据、改数据、读结构、改结构），作用于所有数据库；官方建议要严格只读，就给数据源配一个只读账号。DBX 可以按分组、连接、库分别设。另外 DataGrip 的 MCP 还会暴露 IDE 的其他能力，比如执行终端命令（默认需要确认），不需要的可以在 Exposed Tools 里逐个关掉。
安装
最省事的是在 DBX 里操作：设置 → MCP → 接入方式，一键安装 MCP Server，页面会生成各个客户端的配置，复制过去即可。
命令行安装也行，不需要 Node.js：
# macOS / Linux，装到 ~/.dbx/bin/dbx-mcp
curl -fsSL https://dbxio.com/install-mcp | sh
# Windows PowerShell
irm https://dbxio.com/install-mcp.ps1 | iex
脚本会打印 Claude Code、Cursor、Codex 等客户端的配置。以 Claude Code 为例（--scope user 表示所有项目都能用）：
claude mcp add --scope user dbx -- "$HOME/.dbx/bin/dbx-mcp"
配置里要写展开后的绝对路径，不要写
~或裸命令dbx-mcp，GUI 类客户端不一定继承 shell 的 PATH。
习惯 npm 的也可以用 npx -y @dbx-app/mcp-server，背后是同一个 Rust 二进制。dbx-mcp 很轻，我本机每个进程只占 7~10 MB 内存。
权限：细到分组、连接、库
把生产库交给 AI 之前，权限是绕不开的问题。DBX 在 设置 → MCP → 权限管理 里统一管理，客户端配置里不放任何权限参数：
- 三档权限：只读（查询和元数据）、数据读写（普通插入、带有效条件的更新和删除）、完全访问（再加上 DDL、
TRUNCATE、大范围删改）。 - 三级范围：分组、连接、单个库都能单独设权限，最具体的设置优先。每个连接的库范围可以选"全部 / 指定 / 不开放"，请求范围外的库直接返回
DATABASE_OUT_OF_SCOPE。 - 硬上限：连接本身的只读开关、生产保护、数据库账号的权限，任何 MCP 设置都绕不过去。
- 工具白名单：可以只开放部分工具，服务端每次调用都会检查，客户端缓存了旧的工具列表也调不动。
- 高危确认：开启后，高危调用执行前会在 DBX 桌面端弹窗，逐次批准。
- 调用记录：每次调用的客户端、工具、目标库、判定级别、耗时都能查到。
图 5：设置 → MCP → 权限管理。图里是我本机的配置，全局默认开的是"完全访问"；第一次用建议先选"只读"，再按分组、连接单独放开。
图 6：一个典型配置。全局默认只读，dev 分组放开数据读写，prod 连接只读并开生产保护，敏感库干脆不放进范围。
有个细节能看出这块是认真做过的："数据读写"档允许带条件的 UPDATE / DELETE，但 WHERE 1 = 1、WHERE TRUE 这种形同虚设的条件仍然按高危处理。
边界也要说清楚：权限粒度到库为止，没有表级。想把某几张表藏起来，还是得靠数据库账号授权，给 MCP 用的连接单独配一个只授权部分表的账号。
不只是 SQL
MCP 这块迭代很快。除了 SQL，现在还有 Redis 命令、MongoDB、Kafka 消息读取（不提交消费位点）和发送、Nacos 配置与服务管理、Consul 的 KV 和服务健康查询。每个工具都标了只读 / 读写 / 高危，同样受上面的权限管控。插件装多了以后，可以把插件工具切到按需发现模式（DBX_MCP_PLUGIN_TOOLS=lazy），只暴露三个入口工具，用到时才加载参数 schema，省上下文。
日常用法就是在 Claude Code 里直接说人话。写这篇文章时，我就是让 Claude Code 通过 dbx MCP 列出本机连接来核对配置的。再比如：
用 dbx 看一下 dev 库里 orders 表的结构，统计最近 7 天每天的订单数，
查完在 DBX 里打开结果
后半句会调用 dbx_execute_and_show，结果直接出现在 DBX 的表格里，比在终端里看 Markdown 表格舒服（这一步需要 DBX 桌面端开着）。
五、内置 AI：临时报表直接交给它
不在 Claude Code 里的时候，DBX 自带的 AI 助手也够用。
模型接入：内置 Claude、OpenAI、Gemini、DeepSeek、Qwen、MiniMax、Ollama 预设，也支持 OpenAI / Anthropic 兼容接口，中转站可以直接填。它还能直接调用本机已经登录的 Claude Code、Codex 等 CLI，不用再单独配 API Key。
两种模式：
| 模式 | 适合 | 会不会执行查询 |
|---|---|---|
| Ask | 写 SQL、解释、优化、修复报错 | 不执行，只给建议 |
| Agent | "查出结果""对比真实数据"这类要取数的任务 | 会看表结构、取样、执行只读查询 |
在输入框里用 @表名 点名相关的表，比让模型在整个库里猜更准，也更省 token。
临时报表是我用得最多的场景。以前要么写 SQL 导出 Excel 再画图，要么打开 BI 工具拖半天。现在切到 Agent 模式说一句：
统计 orders 表最近 30 天每天各渠道的订单数，画成折线图，最后给三条结论
它会先读表结构、写 SQL、执行只读查询，再在回复里直接渲染图表（目前支持折线图、柱状图、饼图）。DBX 给模型的规则要求图表数据来自查询结果，不许编造。最终分析可以导出成 Markdown，发给同事就是一份临时报表。
图 7：用一个演示库实测。一句话需求，AI 先确认时间、读字段、执行两次只读查询，再画出折线图、给出结论，连"今天还没过完、0 单不代表下滑"都主动说明了。
写操作有后端兜底，不只靠提示词约束。AI 想执行非只读 SQL，必须先把 SQL 作为提案展示出来；你确认后，授权只绑定同一个连接、同一个库、完全相同的 SQL 文本，而且只对下一次执行有效。生产库上的写入和 DDL 一律不授权给 AI，只能把 SQL 交给你人工执行。
提醒一句：用云端模型时，表结构摘要、SQL 和部分查询结果会发给模型供应商。敏感数据可以换成 Ollama 本地模型，或者提问前自己先脱敏。
六、WebDAV 同步：换电脑不用重配连接
设置 → 同步 里选 WebDAV，坚果云、NAS、Nextcloud 都可以，支持定时自动上传。另一台电脑填同样的 WebDAV 地址，下载一次就恢复了。
同步的是 DBX 的配置，不是业务数据：
| 内容 | 默认 |
|---|---|
| 数据库连接、分组、侧边栏布局 | 同步 |
| 保存的 SQL | 同步 |
| 桌面和编辑器设置 | 同步 |
| 数据库密码、SSH 密码、AI API Key | 不同步，可选加密后同步 |
| JDBC 驱动、插件 | 不同步 |
不用 WebDAV 的话，桌面端也支持同步到 GitHub Gist、Gitee、GitLab 的私有代码片段，需要手动上传和下载。
下载会用远端快照替换本地的连接和保存的 SQL，恢复前先确认路径没填错。
从 Navicat 迁移也简单：Navicat 里 文件 → 导出连接 得到 .ncx 文件，DBX 里 设置 → 导入连接 选中它。Navicat 加密存储的密码导不过来，导入后要重新输一遍。
七、和 Navicat、DataGrip、DBHub 怎么选
| 维度 | DBX | Navicat Premium | DataGrip | DBHub |
|---|---|---|---|---|
| 定位 | 客户端 + AI + MCP + CLI | 商业数据库客户端 | JetBrains 数据库 IDE | 纯 MCP Server |
| 价格 | 免费开源 | 订阅 500~1000 美元/年；另有免费的 Lite 版（功能精简，每个组织最多 5 人） | 非商业免费；商业个人约 100 美元/年起 | 免费开源 |
| 磁盘占用 | 装好 77 MB | 装好 1.1 GB | 安装包约 1 GB | npx 运行，没有 GUI |
| 内存 | 偏高（WebView 架构） | 较低 | JVM 应用，几百 MB | — |
| 上手难度 | 低，菜单好找 | 中，老用户多 | 高，功能深、设置多 | 要手写 TOML |
| AI 助手 | 内置多家模型，可直接用本机 Claude Code / Codex；Agent 能查数画图 | 内置多家模型；18 版加入 AI 填充数据、AI 建表 | JetBrains AI 助手，内置数据库 Agent Skills | 没有，交给 MCP 客户端 |
| MCP | 复用 GUI 里的连接；分组 / 连接 / 库三级权限；不用开着客户端 | 无 | 复用 IDE 里的连接；全局权限开关；要开着 IDE | TOML 手写 DSN；按数据源设只读 |
| 跨设备同步 | WebDAV / Gist / Gitee / GitLab | Navicat Cloud / 个人配置同步 | JetBrains 账号同步 IDE 设置 | — |
| 成熟度 | 半年的新项目，功能已经很全，一天一版 | 老牌商业产品 | 老牌 JetBrains 产品 | 专注 MCP，功能面小 |
Navicat 仍然占优的地方：数据建模、BI 仪表盘、数据脱敏这些重功能，DBX 目前没有或者没那么完整；Navicat 的稳定性也是多年打磨出来的。重度依赖这些功能，或者公司已经买了授权，没必要换。
DataGrip 仍然占优的地方：SQL 编辑和代码智能是几个里最强的，补全、重构、跳转、实时报错都很成熟，适合把 SQL 当代码写、整天泡在查询里的人。已经在用 IntelliJ IDEA 这类 JetBrains IDE 的话，同样的数据库功能可以通过 Database Tools 插件直接用。
DBHub 仍然合适的场景：没有桌面的服务器、CI 环境，或者只想要一个最小的 MCP、不需要 GUI。
DBX 的不足：
- bug 不少。我遇到过部分有外键关联的表在 DBX 里删不掉，同样的表 Navicat 能直接删。GitHub 上标题带
[Bug]的 issue 目前还有 360 多个没关。好在修得也快，最近一周关了 170 多个；我翻到的一个 SQL Server 改外键的兼容问题，从提交到关闭不到 3 小时。遇到问题直接提 issue，急用的操作先拿 Navicat 兜底。 - 回归风险。一天一版意味着改动频繁，出现回归的概率也更高。生产库建议开"只读"或"生产保护"，升级前扫一眼更新日志。
- 内存偏高，前面说过。
- 没有表级权限。MCP 权限到库为止，表级隔离要靠数据库账号。
- JDBC 数据库要另装依赖。Oracle、达梦这类 JDBC 数据库要额外装驱动和 JRE，体积优势在这类场景会打折扣。
八、五分钟上手
1. 安装：从 Releases 下载，或者用包管理器：
brew install --cask dbx # macOS
winget install t8y2.dbx # Windows
Linux 有 deb / rpm / AppImage，也可以用 Flatpak。要给团队用，可以用 Docker 部署 Web 版：
docker run -d --name dbx -p 4224:4224 -v dbx-data:/app/data t8y2/dbx:latest
2. 导入或新建连接：从 Navicat 导入 .ncx，补上密码；生产库顺手打开"生产保护"。
3. 装 MCP：设置 → MCP → 接入方式，安装后把生成的配置加到 Claude Code。
4. 配权限：设置 → MCP → 权限管理，全局默认先设成只读，再按需给 dev 分组放开。
5. 接 AI：设置 → AI 添加模型，或者直接选本机的 Claude Code CLI。
6. 开同步：设置 → 同步 → WebDAV，打开定时上传。
九、收尾
DBX 适合每天和数据库打交道、又经常让 AI 帮忙查库的开发者。Navicat 功能最全，但它的 AI 只服务自己的窗口；DataGrip 也能把连接开放给 AI，但它是一个重型 IDE，权限也只能全局控制。DBX 轻、上手快、功能全，也懂国内开发者的需求，把连接变成了 GUI、内置助手、Claude Code 都能用的公共资源，权限也管得住。它还年轻，bug 不少，但更新节奏跟得上 AI 工具的变化速度。
连接配一次，人和 AI 都能用，这是我留下它的原因。