ShayanAbbas1/dbdelve

如果你现在的数据库客户端基于 Electron 或 JVM、一开就吃掉大量内存，这个项目值得试；但要做好 macOS 版本未公证、功能仍在早期阶段的准备。

解决什么问题

日常流程通常是：打开客户端、连库、跑一条查询、在大结果里翻看、顺手改一个单元格。问题出在启动和内存上——浏览器运行时或 JVM 常驻后台，一天下来占用不低，遇到百万行的表时网格会卡顿，甚至直接限制行数。DBDelve 用 Rust 和 GPUI 重写这层体验，让启动、滚动和编辑都发生在更轻的进程里。作者给出的结果是约一秒启动，百万行结果可以继续滚动，项目也附了滚动演示。

有什么不同

核心机制是 GPUI 渲染加上原生数据库层，不打包 Electron 也不带 JVM。作者在基准测试表中给出自己的数据（2026-10-11，M1 Pro、32 GB，DBDelve 0.3.6 对比 DBeaver 25.3.1，各取 5 次中位数）：启动 1.1 秒对 5.2 秒，空闲内存 133 MB 对 606 MB，百万行查询 56 秒对 208 秒，内存 4.9 GB 对 17 GB。这些数字来自项目自测，不是独立验证；而且百万行那一项是刻意关掉行数限制、把整张表拉进内存，理解时应把它看作作者环境下的一次对比，而不是普遍承诺。

第二个差异是覆盖面：Postgres、MySQL、MariaDB、SQLite、Turso、DuckDB、Snowflake、SQL Server、MongoDB，以及 Redis/Valkey/KeyDB/Dragonfly 都在同一个界面后面。迁移摩擦也做了处理：可从 DBeaver 或 macOS 上的 TablePlus 导入已保存的连接，包括密码和 SSH 设置；把 CSV、Excel、Parquet、JSON 文件拖进窗口，就会用内存中的 DuckDB 打开成可修改的查询。代价是深度不足：项目年轻，README 承诺的是未来补齐功能，成熟客户端里积累的各引擎专属运维功能可能还比较少。破坏性操作会先询问，每个连接可以设成只读、读写或完全访问并用标题栏颜色区分，但这只是提醒，不能代替你自己确认连的是哪个环境。

谁值得试

适合：同时使用多个数据库引擎、日常以查看和筛选为主、偶尔改数据，并且介意客户端长期占内存的开发者。通过跳板机连库的人也会受益于 SSH 隧道设计——它直接调用你本机的 ssh，配置、agent 和硬件密钥都能沿用。也适合想要免费、没有付费墙功能的人。

不适合：依赖特定数据库管理功能或需要已公证 macOS 安装包的团队，因为安装步骤明确要求手动清除隔离标记。日常主要做 schema 迁移或性能调优的人，最好先确认对应引擎的功能是否齐全再考虑切换。

使用条件与边界

平台范围写得很明确：macOS 只支持 Apple Silicon 且要求 12 及以上（未列 Intel 版本）；Linux 为 x86_64/aarch64，可通过 AUR、tarball 或 AppImage 安装；Windows 为 x86_64 的 zip 包。macOS 的 cask 未公证，安装说明要求再执行一条清除隔离属性的命令，跳过就打不开。Linux 另有依赖要求，从源码构建是另一条路径。更新方式和数据存放位置也写在同一份文档里，所以日常维护有据可查，不是未知数。

功能边界来自项目年龄：更多引擎仍在"计划中"，项目自称处于早期阶段。连接导入只覆盖 DBeaver，以及 macOS 上的 TablePlus，其他客户端需要手动重新录入。程序唯一主动发起的网络请求是检查更新，可以关闭。

HotRepo 点评

仓库创建至今 70 天，日榜只记录到一天：2026-10-27，549 stars，当日 +27。这是一次带日期的快照，不是趋势曲线；缺少可比历史，无法判断关注度能否持续。真正值得核实的是基准数据——用你自己的引擎和数据量对照公开方法复核一遍，再决定是否信任这些数字。