公司不让装 Navicat 了，就自己写了一个数据库客户端

先说下背景吧。我在公司写了十几年代码，平时主要跟后端、数据库打交道。之前也给自家孩子做过几个 Android 小应用，背单词、练口算那种，他们用得还行。但那些东西说到底还是「给别人用」的，做完交付就完了，自己平时该用什么工具还是用什么工具。

直到前段时间，公司合规那边突然发通知，不让装 Navicat 了。说实话，我当时心里是有点懵的。用了这么多年，肌肉记忆都刻在指尖上了。然后我就试着换到 DBeaver，社区版确实免费开源，但日常用起来总觉得差点意思——界面响应有点钝，多表联查的操作路径也绕，特别是遇到跨库的场景，简直折磨。

正好那阵子 vibe coding 这个概念特别火，大家都在用 AI 写东西。我寻思着，与其憋着用不趁手的工具，不如自己上手试一把，看能不能做出一个真正工业级、能天天拿来干活的数据库客户端。不是玩票，也不是做个 demo 发个朋友圈就完事。就是给自己用，目标很明确。

两个最核心的痛点

先说第一件事，查线上问题。

做后端的朋友应该都有这种经历。处理一个投诉或者排查线上故障，流程基本是这样的：

先查表 A，拿到某个订单的 ID 或者用户的状态码。然后拿这个值去查表 B，看看关联的操作记录。接着再查表 C、表 D…… 一层层往下挖。

麻烦就麻烦在，这些表往往不在同一个库里。比如订单数据在订单库，用户信息在用户库，日志又可能在另一个专门的日志库里。这种情况下没法直接写 JOIN，只能等上一条 SQL 跑完，把结果里的字段复制出来，然后手动填到下一条 SQL 的 WHERE 条件里。

一条链路走下来，复制粘贴十几次是常态。烦也就算了，关键是容易出错。有时候复制的时候多带了个空格，或者少复制了一位 ID，查出来的结果就是错的，还得回头检查是数据问题还是自己粘贴的问题。

所以我在 DataZen 里做了个叫 Workflow 的功能。用 YAML 把多步查询串起来，上一步的结果可以直接传给下一步的参数，而且不同步骤可以连不同的数据库。这样我只要把整条链路定义好，跑一次，所有步骤自动执行完，结果一次性出来。

举个例子，大概长这样：

steps:
  - name: 查订单
    connection: order_db
    query: SELECT user_id, status FROM orders WHERE order_id = '{{input.order_id}}'
  - name: 查用户
    connection: user_db
    query: SELECT name, phone FROM users WHERE id = '{{steps.查订单.result.0.user_id}}'
  - name: 查操作日志
    connection: log_db
    query: SELECT * FROM operation_logs WHERE user_id = '{{steps.查订单.result.0.user_id}}' AND created_at > NOW() - INTERVAL '7 days'

上一步查出来的 user_id，直接通过模板语法引用到下一步的 SQL 里。不用再手动复制粘贴了。

再说第二件事，老板要数据、要报表。

做开发的都懂。平时在工位上写代码写得好好的，突然老板在 IM 上甩过来一句：「帮我看一下上周的支付成功率」或者「对比一下这个月和上个月的活跃用户数有什么变化」。

每次遇到这种需求，流程都是一样的：打开数据库客户端，连上库，写一条 SQL，跑出来，导出成 CSV，再贴到飞书或者 PPT 里，有时候还得临时画个图表。做完发给老板，老板看完可能还会追问一句：「那下个月预测呢？」 然后又得重新来一遍。

所以我在 DataZen 里做了运营看板（Dashboard）功能。把常用的 SQL 和对应的图表类型保存下来，设置好定时刷新频率，多个指标放在同一个页面上。以后老板再要数据，我直接把看板链接发过去，他自己打开看就行了。不用每次重新查，也不用每次重新画图。

这两个功能，都是我自己日常真的会用到的东西。不是看竞品有什么功能就照着抄什么，而是我确实被这两个问题折磨了很久。

开发过程中踩的坑

一路做下来，说实话，踩了不少坑。

很多功能远看很简单，真正做深了才发现不容易。比如 SQL 编辑器，你以为就是放一个文本框，支持语法高亮就行。但实际上要做代码补全、要做关键字提示、要处理大文件不卡顿、要支持多标签页…… 每个点都能耗掉不少时间。

Schema 浏览也是。左边一个树形结构，列出数据库、表、字段、索引。看起来简单，但不同数据库的元数据获取方式完全不一样。MySQL 有 information_schema，PostgreSQL 有 pg_catalog，SQLite 又完全是另一套。你得为每种数据库写一套元数据查询逻辑，然后统一成自己的数据模型。

还有大结果集性能的问题。查出来 10 万行数据，不能一次性全渲染到界面上，会卡死。得做虚拟滚动，只渲染用户当前能看到的那部分。这里面的优化细节也很多。

不同数据库方言差异就更不用说了。日期函数、字符串拼接、分页语法、类型转换…… 每个数据库都有自己的脾气。你写一个功能，得在 MySQL、PostgreSQL、SQLite、Redis 上分别测试，确保行为一致。

AI 相关的能力我也做了，包括自然语言生成 SQL、SQL 报错诊断、EXPLAIN 分析这些。但说实话，对我来说，Workflow 和 Dashboard 才是最先想解决的。AI 功能是锦上添花，但上面那两个是刚需。

以前我总觉得自己还算懂产品，至少比纯写后端的同事更关心用户体验。但做着做着才发现，自己离「优秀的产品经理」还差得远。中间有好几次，我差点去做一些「技术上很酷、但日常根本用不上」的东西。比如我花了两天时间研究怎么实现一个自定义的 SQL 执行计划可视化图，做完了发现我自己平时根本不会去看那个图。

后来我慢慢学会在做任何功能之前先问自己一句：这个功能，是不是在解决我自己的真实问题？如果答案是「不是」，那就砍掉，不管技术上多有意思。产品还是要回到用户的痛点上。对我自己来说，痛点就是上面那两件事。

DataZen 现在有什么

DataZen 是一个开源的数据库客户端，技术栈是 Tauri + Rust + React。Tauri 做桌面壳，Rust 做后端逻辑，React 做界面。macOS / Windows / Linux 三平台都能跑。

除了 Workflow 和 Dashboard 这两个核心功能之外，还有这些：

日常查库

SQL 编辑器、Schema 树、结果集查看，这些基础功能都有。编辑器支持语法高亮、自动补全，结果集支持排序、筛选、导出。

支持的数据库

目前支持 PostgreSQL、MySQL、SQLite、Redis。更多的数据库可以通过 Driver 扩展机制来添加，这个后面细说。

安全特性

支持 SSH 隧道连接，连接信息在本地加密存储。不会明文保存密码。

AI 辅助

• 自然语言生成 SQL，会带上当前数据库的 Schema 信息作为上下文，生成出来的 SQL 更贴合实际表结构
• SQL 报错诊断，出错的时候 AI 会帮你分析错误原因
• EXPLAIN 分析，帮你解读执行计划，找出性能瓶颈
• 支持 OpenAI、Anthropic、DeepSeek 以及自定义接口（可以接本地部署的模型）

查询结果转图表

查完 SQL 之后，可以直接在结果集上生成图表。折线图、柱状图、饼图这些常用的都有，可以导出成 PNG 或者 SVG，方便贴到文档里。

MCP 支持

• 可以作为 MCP Server，把数据库能力暴露给 Cursor 等外部工具。也就是说，你可以在 Cursor 里通过 MCP 协议直接查数据库
• 也可以作为 MCP Client，接外部 MCP Server 到 AI Chat 里用
• 支持无头 stdio 模式，可以命令行调用

Driver 插件机制

数据库能力是通过 Driver API 扩展的。我定义了一套标准的接口，社区开发者可以按照这个接口规范，自己实现新的数据库支持，然后作为插件加载进来。这样就不用等官方慢慢支持了。

其他功能

还有 ER 图、Schema Diff（对比两个库的表结构差异）、数据同步（跨库数据迁移）、数据导出等。详细的用法文档里都有。

本地优先，开源免费

不用注册账号，连接信息和凭据都留在本机，不会上传到任何服务器。GPLv3 开源协议，代码完全公开。

关于 AI 写代码这件事

评论区有人问我是不是纯手写的，也有人质疑说 AI 用多了还真以为是自己写的。我统一回答一下。

开发过程用的是 Cursor，主力模型是 Opus 4.6 和 Composer 2.5。但我想说的是，AI 写代码不是说你扔一句「给我写个数据库客户端」就能出活。它需要你拆解任务、设计架构、定义接口、审查代码、调试问题。特别是在这种涉及多数据库方言、桌面端性能优化、安全加密存储的复杂项目里，AI 只是帮我加速写代码的工具，真正的架构设计和方向把控还是得自己来。

我比较自豪的是，这个项目的代码质量绝对不差，系统架构的可扩展性也做得比较好。整个开发过程走下来，我感觉自己这个老码农还能在 AI 浪潮下再抗几年。同时也趁着这个项目，积累了不少开发 AI agent 的经验——怎么给 AI 拆任务、怎么写 prompt 让它产出高质量代码、怎么审查和修正 AI 的输出，这些都是实打实的经验。

另外说一句，我们公司有明确规定，AI 不能碰生产数据，避免敏感信息泄露。所以我在开发过程中，所有测试数据都是本地生成的假数据，没有用任何真实的业务数据去喂 AI。

还不完美，但想开源

说实话，DataZen 离「极致好用」还有距离。很多功能能用，但还不够顺手。交互细节、边界情况、各数据库的打磨，都需要时间，也需要更多人的使用反馈。

我一个人做，速度有限。所以开源了——不是因为它已经很好，而是希望有人一起把它做好。如果你也天天和数据库打交道，欢迎来 GitHub 点个 Star，或者提 Issue 说 bug 或体验问题，也可以讨论功能方向，甚至直接贡献代码、Driver、文档。

• GitHub 项目地址：https://github.com/flyxl/datazen
• 下载地址：https://github.com/flyxl/datazen/releases
• 中文文档：https://flyxl.github.io/datazen/zh/manual.html

最后说两句

做一个「只为自己」的软件，听起来挺理想主义的，过程其实挺磨人的。会怀疑值不值得做，会在细节上卡住，也会在产品方向上走弯路。但如果你有一个你自己每天都会遇到的问题，值得花时间做一个能用的版本出来。先能用，再慢慢改。

另外，评论区有朋友提到了 DBX 和 DataGrip，说这个领域已经有很强的竞品了。我承认，DBX 确实做得好，DataGrip 也很成熟，Navicat 更是老牌玩家。但对我说，做 DataZen 的过程本身就有价值——它让我更深入地理解了数据库客户端的底层实现，也让我对产品设计有了更具体的认知。而且 Workflow 和 Dashboard 这两个功能，确实是基于我自己的真实痛点做的，目前市面上没有哪个客户端能完美解决这两个问题。

最后想问问大家：你平时用数据库客户端，最烦的一件事是什么？这个问题对我来说，比任何功能清单都有用。