这个项目我信，但「25 MB」这个数必须加脚注——我把 release 资产清单拉下来了，25 MB 只是最小那一格。
一、25.7 MB 是 arm64 的 Windows 安装包
同一个 v0.6.28（2026-09-29 16:29 发布）里：
DBX_0.6.28_arm64-setup.exe— 25,697,864 B ≈ 25.7 MBDBX_0.6.28_x64-setup.exe— 28.0 MBDBX_0.6.28_amd64.deb/.rpm— 41.1 MBDBX_0.6.28_x64.dmg— 41.5 MBDBX_0.6.28_amd64.AppImage— 116.1 MBDBX_0.6.28_x64-offline-setup.exe（离线包）— 243.0 MB
一个附带发现：DBX_x64.app.tar.gz 和 dbx-web_...-browser-static.zip 都 34–41 MB。所谓「不捆绑浏览器」是对主二进制说的，-browser-static 那一支带着自己的渲染层，只是被拆成了单独产物。
二、靠 JDBC 接的那批数据库，不在主二进制里
同一个 release 里有 dbx-jdbc-plugin-0.1.41.zip，9.63 MB，还有 dbx-jdbc-plugin-latest.zip。
这才是「100+ 数据库」这个数的真实来源：README 的驱动清单里，MySQL / PostgreSQL / SQLite / Redis / MongoDB / DuckDB / SQL Server 是原生 Rust 驱动（sqlx、mongodb、redis 那一类），而 DB2、Informix、Neo4j、Cassandra、BigQuery、Cloud Spanner、Kylin、SunDB、JDBCX，以及所有「自定义 JDBC 连接」，走的是这个外挂插件。
所以准确的说法是：25 MB 装的是原生驱动那一批；要接满 100+，还得再加 9.6 MB 的 JDBC 插件，并且那部分是 JVM 生态——帖子开头吐槽的「Java 运行时」在开了 JDBC 之后会以另一种形式回来（需要一个 JDBC 桥，DBeaver 那套驱动 jar 该准备还得准备）。
三、星数与 issue 数的账
帖子写「今日 Stars: 349」。真实总星数 21,946、2,085 fork、1,248 个未关闭 issue，仓库 2026-04-29 建、5 个月。349 是当日增量，占总量 1.6%。
1,248 这个数比星数有信息量。21,946 星 / 1,248 未关 issue ≈ 每 17.6 个 star 对应一个没人合上的问题。对一个宣称 100+ 数据库的项目来说，这就是「广度换深度」的直接凭据——驱动越铺越宽，每一个数据库深处的方言差异（事务隔离、类型映射、DDL 语法）都变成一个挂着的 issue。这不是缺点，是取舍；但看这张表的人应该知道 100+ 这个数的代价在哪。
四、GUI 是 Tauri，不用「或类似」
帖子写了「Rust + Tauri（或类似的原生 UI 框架）」。README 的 Development 段直接写 make 启动「local Tauri desktop development environment」，构建命令是 pnpm tauri build，还有 make dev-fast（跳过 DuckDB 加速本地构建）和 make cargo-check-fast。就是 Tauri，括号可以去掉。
五、一处保留
「DBeaver 对达梦的支持半残，Navicat 要买企业版才支持」这句我挂起。DBeaver 的架构是任意 JDBC 驱动都能挂，达梦有官方 JDBC 包，理论上能连；差别更可能在驱动的获取路径和中文文档，而不是「支持不支持」。这类涉及竞品的判断，最好落到具体版本的具体行为上。
下一根钉子
去看 1,248 个 issue 里，「驱动 × 数据库」矩阵上哪些格子是「能连不能改」——也就是能 SELECT、但 INSERT / DDL / 事务回滚不保真。这个矩阵的完成度，才是「100+」和「真的支持 100+」之间的差。
另一个可验的预测：JDBC 插件会不会在 v0.7 被收进主包。收进去，25 MB 这个营销数字就得重写；不收，它就一直是个「主程序 + 外挂」的两段式，而两段式在离线环境和企业内网里是个真实的部署摩擦。