把一张 100 万行、100 多列的 Postgres 表全量塞进内存，老牌工具 DBeaver 要吃掉 17 GB 内存、耗时 208 秒；而刚开源的原生数据库客户端 DBDelve 0.3.6 只用了 4.9 GB 内存和 56 秒。开发者 Shayan 用 Rust 语言加上 Zed 编辑器同款的 GPUI 框架，给苦于内存爆炸的程序员递上了一把快刀。但如果你以为这又是一出 Rust 吊打 Java 的爽文，去翻翻它代码仓库里的测试文档和最近三周的提交记录，看到的会是另一番景象。
跑分表上的降维打击，与被折叠的 0.1 秒
桌面数据库客户端长久以来困在三个选项里：DBeaver 和 DataGrip 这类 JVM 工具有深度管理和智能补全，但吃内存极狠；Beekeeper Studio 等 Electron 工具界面现代，却摆脱不了 Chromium 的资源臃肿；原生的 TablePlus 轻快好用，但闭源收费。Shayan 因为早年用旧电脑跑 DBeaver 和 PostGIS 频繁崩溃，决定效仿 Zed 和终端工具 Ghostty，自己写一个主打性能的原生客户端。
在 2026 年 10 月 11 日发布的 DBDelve 0.3.6 中，作者放出了一组基于 M1 Pro（32 GB 内存）、对同一张 Postgres 表运行 5 次取中位数的对比数据：
| 测试项目 | DBDelve 0.3.6 | DBeaver 25.3.1 | 核心差异 |
|---|---|---|---|
| 启动耗时 | 1.1 s | 5.2 s | 提速近 4 倍 |
| 空闲内存 | 133 MB | 606 MB | 节省 78% |
| 1,000 行查询 | 0.21 s | 1.96 s | 渲染更快 |
| 100 万行全量耗时 | 56 s | 208 s | 极限压测差距 |
| 100 万行全量内存 | 4.9 GB | 17 GB | 紧凑行优化 |
DBDelve 能把内存压下来，核心动作是采用了紧凑行结构（packed rows），将加载一张 4 GB 大表的内存开销直接砍掉了 40%，从 8.1 GB 降到了 4.9 GB。同时它支持只读、读写和完全访问三种模式，自带毛玻璃主题、全键盘自定义快捷键、按项目组织连接、按列名导航、启动时恢复表标签页，还能直接从 DBeaver 和 TablePlus 导入连接，以及从 Zed 和 VS Code 导入主题。
但只要拆开仓库里的 BENCHMARKS.md，这组悬殊数据背后的边界就会立刻显形。
测试实际跑在 macOS 26 上，Postgres 15 运行在 amd64 的 Docker 模拟环境里，测试表 events 实际是 100 万行乘 107 列，且为了跑通测试，DBeaver 被手动加上了 -Xmx16g 的堆内存上限。更关键的事实藏在文档角落，在正常流式加载或首屏响应上，DBDelve 和 DBeaver 其实都在 0.1 秒左右就渲染出了第一批数据行。所谓 56 秒对 208 秒的鸿沟，是人为关闭分页限制、强行把一亿多个单元格全量拉进内存的极端压力测试。此外，官方用来测量从按键到画面重绘（含 3 秒 CPU 稳定检查）的 60 fps 录屏计时套件并未开源，也没有公布单次原始记录。
- 结论.DBDelve 真正省下的是日常挂在后台那近 500 MB 的空闲内存和冷启动等待，而不是让你每次查表快上四倍。
25 天狂飙四个大版本，GPUI 与 AI 成了加速器
比跑分更值得盯住的，是这个独立项目惊人的演进速度和悄然转向的商业防御。
2026 年 10 月 11 日发布 0.3.6 时，它支持 macOS 12+（Apple Silicon，Intel 未测）、Linux（x86_64 与 aarch64，Ubuntu 22.04 glibc 基线，支持 X11 与 Wayland）和 Windows 便携包；数据库涵盖 PostgreSQL、MySQL、MariaDB、SQLite，以及功能尚有缺失的 Snowflake（缺内联编辑）、SQL Server 2017+（缺 Explain）和 MongoDB（不支持事务）。到了 2026 年 11 月 5 日，也就是仅仅 25 天后，项目已经狂飙到 0.7.0 版本，一口气把支持列表扩充到了 Turso、DuckDB、Redis、ClickHouse 以及各类 ODBC 引擎。
一个独立开发者为什么能推进得这么快？答案在工具链。
Shayan 点名感谢了 Zed 团队的 GPUI。虽然官方没有及时维护 crates.io 上的包，但社区已经攒出了打包 GPUI、GPUI-component 并加入实验性保留模式（retained mode）的 GPUI-kit。更重要的是，GPUI 类似 HTML 的结构不仅让 Web 背景的开发者极易上手，而且非常适合 AI 编程 Agent 直接生成代码。过去写原生桌面软件，UI 布局和状态同步是泥潭；现在借着社区封装组件和 AI 辅助，单兵作战也能在几周内搭起一个跨平台数据客户端。
就在功能狂飙的同时，仓库的许可证悄悄变了。0.3.6 发布时它还是极其宽松的 MIT 协议，而截至 11 月 9 日，最新仓库已经切换为具有传染性的 GPL-3.0 协议（仅变更前的旧代码保留 MIT）。这种先用宽松协议攒人气、验证潜力后再收紧协议防止被大厂白嫖或闭源套壳的做法，在如今的独立开源项目里越来越常见。
赢下帧率只是上半场，生产环境不相信裸奔
我更在意的是，当新鲜感过去，一个数据库客户端到底靠什么留在程序员的 Dock 栏里。
二十多年前，Firefox 靠着轻快把臃肿的 IE 浏览器打得满地找牙；可等到 Web 应用变成重度生产力工具，真正决定生死的是开发者工具、扩展生态和稳定性。数据库客户端也是同理，只不过它的容错率比浏览器低得多。
快，只能决定别人愿不愿意下载你；稳，才决定别人敢不敢拿你连生产库。
看看社区里数据工程师们的真实反馈，就能明白 DBDelve 距离替换主力工具还有多远。有人指出，在里面随手关掉一个已保存查询的标签页，那个保存好的查询竟然会被直接删掉；有人抱怨详情面板连大小都调不了，宽表的水平滚动体验也还糙；还有重度用户直接伸手要 pgAdmin 级别的完整运维管理功能。
最要命的有两件事：第一，它目前缺少生产环境与测试环境的颜色区分标识，老手都知道，半夜维护时没有那一抹刺眼的红色警告，一个手滑就可能把删表语句发到生产库；第二，macOS 版本至今没有完成苹果签名与公证。
- 风险.让一位工程师或者 DBA 在自己电脑上绕过系统安全拦截，去运行一个未签名的二进制程序，还要把公司核心数据库的账号密码填进去，这在任何规范点儿的团队里都是合规红线。
那些被骂臃肿的 DBeaver 和 DataGrip，内存到底花在哪了？除了 JVM 本身的底噪，很大一部分花在了复杂的 SQL 语法树解析、跨库元数据缓存、事务安全兜底和防呆设计上。“糜不有初，鲜克有终。”用 Rust 和 GPUI 把表格渲染帧率拉满，解决的是最显眼的性能痛点；但接下来要把苹果签名跑通、把误删查询的交互修好、把生产环境的防呆护栏立起来，全是枯燥且不性感的苦力活。
对于厌倦了电脑风扇狂转、平时只拿客户端查查本地开发库或跑跑简单分析的开发者，DBDelve 已经是个让人心情舒畅的玩具；但如果你手头管着线上核心资产，不妨等它把安全签名和防呆细节补齐了再动手。毕竟在数据库的世界里，省下 10 GB 内存只能让你爽一下午，误删一次生产表却能让你记一辈子。