大家好，我是 Shayan，几个月前我开始做一个 DB 客户端 DBDelve，重点是性能，同时让它用起来顺手（本着 Zed、Ghostty 以及其他那些用起来就是舒服的工具的精神）。就我的工作流而言，我一直追求性能，尤其是之前我用过一台特别老的机器，任何臃肿都特别明显，我记得用 DBeaver 的时候它好几次直接崩溃，我还得用 postGIS，更是雪上加霜。我把所有常用的开发工具都换成了注重性能的那些（Zed、Ghostty 等），唯一缺的就是 DB 客户端。大家的主要选择是 DBeaver，它吃内存，而且在我看来对大多数任务来说都过于臃肿。其他选项比如 Datagrid、Beekeeper、TablePlus，要么基于 electron，因此臃肿又吃内存，要么收费且闭源。

DBDelve 0.3.6 对比 DBeaver 25.3.1，同一个 Postgres 表，各取 5 次运行的中位数（2026-10-11，M1 Pro，32 GB）。时间从执行操作到行渲染完成。

                            DBDelve   DBeaver
  启动                       1.1 s     5.2 s
  空闲内存                   133 MB    606 MB
  1,000 行查询               0.21 s    1.96 s
  1M 行，耗时                56 s      208 s
  1M 行，内存 [1]            4.9 GB    17 GB

[1] 故意把整张 100 万行、100 列的表全部拉进内存，关闭了行数限制。这不是常规使用场景；为了这个基准测试，DBeaver 的堆上限不得不手动调高。加载 100 万行、每行 100 列时的滚动性能：https://youtu.be/V2MOhJYFqIE它包含了大多数开发者 90% 工作流所需的大部分功能，另外我还加了一些自认为不错的细节： 只读、读写和完全访问模式 玻璃主题（如果你喜欢的话，我喜欢） 以键盘为中心，每个快捷键都可自定义 把连接按项目组织我和其他一些人已经把它作为日常主力用了一个多月，大部分好评都集中在它的 UI 非常简单易用、以它的年纪来说非常稳定，当然还有性能。我在这里分享也是因为那些人告诉我它有成长潜力，所以我在尝试把它分发出去。这里要特别感谢 Zed 团队做的 GPUI，用起来非常顺手，前提是你能接受他们没有在 crates.io 上正式更新这个 crate，不过社区已经找到了解决办法，你只需要深入挖掘一下。它的性能极好，而且类似 HTML 的结构让有 web 开发背景的人很容易理解，agent 也很擅长写它。GPUI component 也解决了很多问题，让我们能有一个好用的组件库。我觉得对现在任何开始 GPUI 项目的人来说，GPUI-kit 很合理，它把 GPUI、GPUI-component 打包在一起，还做了一些优化，加入了实验性的 retained mode，可能带来很多好处，所以综合来看它应该是默认方式。我做的主要优化就是通过使用 packed rows 降低内存开销，在大型数据集上把内存使用降低了 40%（在应用内加载一个 4GB 的表时，从 8.1GB 降到 4.9GB），其他大部分都是 Rust 和 GPUI 自带的，或者它们让事情变得很容易。限制： 它没有签名和公证，苹果那边的身份验证简直是噩梦，但应该很快就能签名。 目前别指望功能上和更成熟的客户端持平，现在的总体方向是采用 zed 那种逐步加功能的方式，但要先确保核心工作流以高质量完成。一定要试试，你可以从 dbeaver 和 tableplus 导入连接。https://github.com/ShayanAbbas1/dbdelve 评论 URL：https://news.ycombinator.com/item?id=50427934 点数：9

评论数：0