开源AI数据库客户端datazen：告别DBeaver卡顿和Navicat昂贵

核心特性

1. AI 原生能力

• 自然语言 → SQL：描述需求，DataZen 利用当前数据库 Schema 作为上下文生成可执行 SQL
• SQL 错误诊断：AI 结合数据库错误信息和 Schema 上下文，解释问题并提出修正方案
• EXPLAIN 分析：可视化执行计划，AI 帮助识别性能瓶颈和优化机会
• 数据库感知的 AI 聊天：AI 侧边栏可结合当前连接的 Schema，将对话中的 SQL 转换为可直接使用的代码。支持 OpenAI、Anthropic、DeepSeek 及兼容的自定义端点

• 查询结果可直接转为图表（折线图、柱状图、饼图、散点图、面积图）
• 支持聚合、分组以及 PNG/SVG 导出，无需导出到 Excel

• 用 YAML 描述可复用的数据库操作流程
• 一个 Workflow 可组合 SQL 查询、AI 步骤、条件和循环，每个步骤连接不同的数据库
• 例如：从 PostgreSQL 查询订单、从 MySQL 获取物流信息，再由 AI 汇总结果
• 可从 UI、AI 侧边栏、MCP 启动，也可由 AI 生成

• MCP Server：将数据库操作、Schema 检查、EXPLAIN、Workflows 暴露给外部 AI 代理，支持 headless stdio 模式
• MCP Client：连接外部 MCP 服务器，为 AI 聊天引入额外工具和上下文

• 通过 DataZen Driver API 将应用与数据库特定实现分离
• 驱动编译时集成到 DataZen 中，而非通过不稳定的 Rust 动态库 ABI 加载
• 驱动可独立开发，在独立仓库中维护
• Driver API 以 MIT 许可证发布为 datazen-driver-api crate

介绍

每天打开电脑，第一件事就是面对那个让人又爱又恨的数据库客户端！

商业软件太贵，开源工具太笨重，查个线上问题要复制粘贴几十次，老板要个报表得折腾半天。直到有一天，公司合规部门一纸禁令，连Navicat都不让用了。一个写了十几年代码的开发者，决定自己动手。

结果呢？他用Tauri v2加Rust加React，搓出了一个安装包不到10MB的数据库客户端，取名DataZen。GPLv3开源，Mac、Windows、Linux全支持。最关键的是，他把AI、图表、工作流全塞进去了。

商业软件太贵，开源工具太重，卡在中间的人怎么办

数据库客户端这个赛道，早就被几个大玩家占住了。

Navicat好用，但贵。个人版一年大几百，团队版更不用说。很多公司不愿意掏这个钱，或者像前面说的那样，合规政策直接禁用。DBeaver开源免费，功能也确实全，但启动慢、内存占用高。打开一次等半天，查个数据电脑风扇就开始转。TablePlus也不错，但对很多团队来说还是要付费。

卡在中间的人怎么办？用着不舒服，换又没得换。

DataZen的开发者就是其中之一。公司不让装Navicat了，DBeaver能用但日常用起来总觉得差点意思。他没有选择忍，也没有选择付费买商业版，而是决定自己写一个。不是玩票，不是做个Demo给别人看，就是给自己用。

这就有意思了。一个被公司禁掉的商业软件，反而逼出了一个开源项目。

查一次线上问题，复制粘贴十几次，这事真的合理吗

开发者说，做DataZen的念头，来自两个具体的日常痛点。

第一个痛点：查线上问题。

处理投诉、排查线上故障，流程大概是这样：先查表A，拿到某个ID或状态；用这个值去查表B；再查表C、表D……更麻烦的是，这些表往往不在同一个库，没法直接JOIN。只能等上一条SQL跑完，把结果里的字段复制出来，填到下一条SQL的WHERE条件里。

一条链路下来，复制粘贴十几次是常态。烦不烦？烦。容易出错吗？太容易了。填错一个ID，后面全白查。

这其实是数据库工作的一个普遍困境：工具只提供了单次查询的能力，但真实的工作流是多步骤、跨数据库的。工具和 workflow 之间，有一道巨大的鸿沟。

DataZen的解法是Workflow——用YAML把多步查询串起来。上一步的结果直接传给下一步，不同步骤可以连不同的库。比如从PostgreSQL订单库查出订单，再去MySQL物流库补物流信息，最后让AI汇总。查一次，整条链路跑完。

这就把“复制粘贴十几次”的手动操作，变成了一次性定义、反复执行的自动化流程。

老板要个报表，你得折腾半小时，这事真的合理吗

第二个痛点：老板要数据。

做开发的都懂。临时要个数字、要张图，经常就是“帮查一下上周×××”“对比一下这个月和上个月”。每次打开客户端、写SQL、导出、贴到PPT或飞书里，重复劳动很多。

DataZen的解法是Dashboard——把常用SQL和图表保存下来，定时刷新，多个指标放在一页。老板要看的时候，打开就行，不用每次重新查。

这两个功能，开发者说都是自己日常真的会用到的东西，不是看竞品有什么就抄什么。

这话其实点出了一个很重要的区别：很多工具的功能是“我觉得用户可能需要”，而DataZen的功能是“我自己真的每天都在用”。前者是产品经理的假设，后者是开发者的真实 pain point。

AI不是噱头，是嵌入工作流的助手

2026年，哪个软件不提AI都不好意思见人。但DataZen的AI能力，有点不一样。

它不是把AI当做一个独立的聊天窗口让你去问问题，而是把AI嵌入了数据库工作的每一个环节。

自然语言生成SQL：描述需求，DataZen用当前数据库的 schema 作为上下文生成可执行的SQL。想不起来表名或函数？直接说人话。

SQL错误诊断：写错SQL不用去搜索引擎了。报错之后点“诊断”，AI告诉你错在哪、为什么错，修正后的SQL一键应用。

EXPLAIN分析：慢查询怎么优化？执行计划可视化之后，AI帮你解读瓶颈在哪。

数据库感知的AI聊天：AI侧边栏自动带上当前库的表结构做上下文。支持OpenAI、Anthropic、DeepSeek，也支持自定义端点。

AI Provider可以动态拉取模型列表，prompt也可以按驱动或按用户覆盖。

你看，AI在这里不是“附加功能”，而是“工作流的一部分”。你不用把 schema 复制到 ChatGPT，不用把错误信息贴到浏览器搜索，不用把执行计划截图发给同事问“这个对不对”。所有事情都在同一个工具里完成。

不到10MB，塞下了多少东西

DataZen的技术栈很有意思：Tauri v2加Rust后端，前端用React加CodeMirror 6。

Tauri的好处是什么？安装包小。不捆绑Chromium内核，用的是系统自带的 webview。所以DataZen的安装包不到10MB。启动快，内存占用低。

作为一个对比，Electron应用随便一个安装包就上百MB，内存占用更是动不动几百MB。DataZen用Rust做后端，用Tauri做桥接，在保持原生性能的同时把体积做到了极致。

但体积小不代表功能少。DataZen支持PostgreSQL、MySQL、SQLite、Redis。有SQL编辑器、Schema树、结果集查看。有SSH隧道，不需要本地安装ssh二进制文件。连接信息用AES-256-GCM加密，主密钥存在操作系统钥匙串里。支持备份到SQL，CSV和JSON的导入导出。PG和MySQL之间可以做 schema 和数据的同步。Redis有专门的key浏览器。支持暗色主题，中英文界面。

还有图表功能：查询结果一键从表格切到图表，自动推断字段类型并推荐合适的图。折线、柱状、饼图、散点、面积五种，轴、聚合、分组都能配。支持导出PNG和SVG。

还有MCP支持：既可以作为MCP Server把数据库操作暴露给外部AI代理，也可以作为MCP Client连接外部MCP服务器。

不到10MB，塞下了这么多东西。

驱动可以自己写，Workflow可以自己配，这软件是给你折腾的

DataZen有一个很有意思的设计：驱动是编译时集成的，不是运行时加载的。

什么意思呢？大多数数据库客户端通过动态链接库加载驱动，好处是灵活，坏处是容易出兼容性问题。DataZen走的是另一条路：驱动通过DataZen Driver API独立开发，在编译时集成到应用中。Driver API以MIT许可证发布，叫datazen-driver-api。

这样做的好处是稳定。坏处是——如果你想加一个新数据库的支持，你得重新编译整个应用。但开发者的思路是：与其让用户面对不稳定的动态加载，不如把驱动生态做成可编译的模块。目前PostgreSQL、MySQL、SQLite、Redis是默认支持的，MongoDB、ClickHouse、DuckDB、SQL Server可以通过编译时驱动扩展加进去。

Workflow也是可配置的。用YAML定义自动化流程：查询、AI分析、条件分支、循环。每个步骤可以绑定不同连接。错误策略可以选abort、skip、fallback，超时可配。运行入口很灵活：连接窗口里跑、独立窗口跑、MCP里调，甚至直接让AI生成一份工作流。

这软件的哲学很清楚：给你工具，也给你改工具的能力。

一个还在打磨的早期版本，但方向已经对了

DataZen目前还是早期版本，v0.1.0。开发者自己说还有很多粗糙的地方。

但他提出了几个很有意思的问题，值得每个用数据库客户端的人想一想：

YAML是不是跨库工作流的好接口？

只读权限和写操作审批应该怎么做？

数据库驱动的可扩展性在实际工作中到底有没有用？

日常数据库工作里还有哪些重复劳动是可以自动化的？

这些问题没有标准答案。但能问出这些问题，说明开发者真的在日常工作中被这些问题折磨过。

做产品的都知道，最怕的不是功能少，而是功能多但没一个解决真实问题。DataZen的方向很清晰：先解决开发者自己的两个痛点——跨库查询的复制粘贴地狱和老板要报表的重复劳动——然后再往外扩展。

开发者说了一句话，很有意思：“中间有好几次，差点去做一些技术上很酷、但日常用不上东西。后来慢慢学会问一句：这个功能，是不是在解决我自己的真实问题？”

这话听起来简单，做起来难。多少开源项目死在了“技术上很酷”但“日常用不上”的路上。

macOS用户第一次打开如果提示“已损坏”，需要跑一下这行命令：xattr -cr /Applications/DataZen.app。应用还没做公证。这些细节说明，这确实还是一个早期项目，距离“开箱即用”还有一段路要走。

但方向已经对了。

当一个工具从“别人让我用”变成“我自己想用”的时候，它就开始变得不一样了。DataZen的起点是被公司禁掉的Navicat，终点是什么，没人知道。但至少，它让我们看到了另一种可能：不用在“太贵的商业软件”和“太重的开源工具”之间二选一。

也许还有第三条路。