FluxDB vs DBX vs DBeaver：GPUI、Tauri、Eclipse 三种技术栈实测

数据库客户端看起来都差不多：左边对象树，右边 SQL 编辑器，下面结果表格。

但真正决定体验的，往往不是功能列表，而是执行查询之后的那几秒：

1 万行结果加载时内存涨多少；
滚动宽表时画面是不是跟手；
关闭结果页后内存能不能降回来；
同时开多个连接后，应用会不会越来越重。

我一直在做 FluxDB ，一个用 Rust + GPUI 构建的数据库客户端。这次拿它和两个成熟项目做一次同场景对比：

FluxDB ：Rust + GPUI，本次测试版本 0.1.14
DBX ：Rust + Tauri 2 + Vue 3/TypeScript，本次测试版本 0.5.30
DBeaver ：Java + Eclipse RCP/SWT，本次测试版本 26.2.0

先说结论：

在这台 Mac、同一张 20 万行表、同一句 1 万行查询下，FluxDB 的内存占用最低，滚动帧间隔也最稳定。DBX 的平均帧率已经很接近，但 P95 帧间隔和最大卡顿更差。DBeaver 的内存和流畅度最弱，但它的功能覆盖和插件生态仍然是三者中最成熟的。

这不是"语言之争"。DBX 同样使用 Rust，差异更多来自 UI 运行时、进程模型、结果缓存和滚动实现。

一、三种技术栈，到底差在哪？

先把三个项目的技术栈摆清楚。

FluxDB：Rust + GPUI

FluxDB 的桌面层基于 Rust + GPUI：

UI 由 GPUI 直接渲染，不依赖 Electron；
不使用系统 WebView；
应用逻辑、连接器和界面都在 Rust 工程内；
SQL 结果按页加载，MongoDB 文档区使用虚拟列表，只构建视口附近内容；
进程模型简单，本次采样通常只有 1 个进程。

GPUI 不是"传统系统控件套壳"，而是 Rust 生态里的 GPU 渲染 UI 框架。它的优势是渲染路径短、进程边界少，适合数据表格这种高频刷新界面。

DBX：Rust + Tauri 2 + Vue 3

DBX 同样是 Rust 项目，但桌面架构不同：

Rust 后端：数据库驱动、查询执行和文件处理；
Tauri 2：桌面壳和系统 WebView；
Vue 3 + TypeScript：前端界面；
CodeMirror 6：SQL 编辑器；
本次采样中运行了 4 个进程。

这是一套很成熟的跨端方案。Rust 负责底层能力和性能敏感部分，WebView 负责快速构建复杂界面。代价是多了前端运行时、WebView 进程和前后端通信边界。

DBeaver：Java + Eclipse RCP

DBeaver 是典型的大型 Java 桌面应用：

Java / OpenJDK 25 运行时；
Eclipse RCP 富客户端平台；
OSGi 插件体系，社区版包含 130+ 插件；
SWT / JFace 桌面 UI；
JDBC 连接数据库；
本次采样中统计到 1--2 个进程。

这套架构的优势非常明显：插件化、数据库驱动覆盖广、功能成熟。代价是 JVM、Eclipse 平台和插件体系本身会占掉一部分固定内存。

二、测试环境

测试机器：

项目	配置
机器	MacBook Pro
芯片	Apple M3，8 核
内存	16 GB
系统	macOS 14.2
主屏	3024 × 1964 Retina

测试数据：

项目	配置
数据库	PostgreSQL 16
位置	本机 Podman 容器
表	`public.bench_orders`
数据量	20 万行，30 列，约 278 MB
内容	包含 JSONB 嵌套对象、长文本、数字和普通字符串
查询	`SELECT * FROM public.bench_orders ORDER BY id LIMIT 10000`

为了让结果尽量可比：

三个客户端连接同一个数据库；
执行同一句 SQL；
窗口宽度保持一致，约 3022 × 1750；
单独测试，每个应用结束都完全退出；
内存每 0.5 秒采样一次，子进程一并统计；
录屏统一为 60fps，并裁剪掉开头准备和结尾停止操作。

三、内存实测

内存使用 macOS 的 footprint -t 统计，不只看 RSS。-t 会把应用子进程一起计算，避免漏掉 WebView 或 JVM 进程。

最终数据取最近两次有效运行的中位数，单位 MiB：

场景	FluxDB	DBX	DBeaver
空闲平均	134.6	200.1	411.2
查询峰值	264.5	551.8	827.8
滚动平均	272.7	624.7	625.9
滚动峰值	279.5	710.4	687.1
关闭结果后稳态	191.3	411.3	467.8

从这组数据看：

空闲内存：FluxDB 比 DBX 低约 33% ，比 DBeaver 低约 67%；
查询峰值：FluxDB 比 DBX 低约 52% ，比 DBeaver 低约 68%；
滚动平均：FluxDB 比两者都低约 56%；
关闭结果后稳态：FluxDB 比 DBX 低约 53% ，比 DBeaver 低约 59%。

空闲内存

FluxDB 约 135 MiB，DBX 约 200 MiB，DBeaver 约 411 MiB。

这是三种运行时差异最直观的地方。数据库客户端通常整天开着，空闲内存不是一次性数字，而是全天都在占用的资源。

查询峰值

1 万行、30 列结果加载完成后：

FluxDB 峰值约 265 MiB；
DBX 峰值约 552 MiB；
DBeaver 峰值约 828 MiB。

三者拿到的是同一批数据。差异来自结果模型、表格构建、缓存策略和运行时开销，而不是数据库返回速度。

关闭结果后

关闭结果页 30 秒后的稳态：

客户端	空闲	关闭结果后
FluxDB	134.6	191.3
DBX	200.1	411.3
DBeaver	411.2	467.8

DBX 从空闲的 200 MiB 涨到 411 MiB，说明结果页关闭后仍保留了不少内存。它不一定已经泄漏，可能只是缓存策略更激进，或者 WebView 进程尚未释放。但对需要长时间开多个连接的数据库工具来说，这部分占用会累积。

四、滚动流畅度

FPS 不能只看应用自己的计数器，因为三款应用的内核和渲染方式不同。

这次统一用 macOS 窗口录屏：

只录制目标应用窗口；
持续滚动结果约 20 秒；
裁剪掉开头准备和结尾停止；
取 5--30 秒 有效区间；
去掉重复帧，统计有效帧率、P95 帧间隔和最大卡顿。

结果如下：

客户端	有效 FPS	估算掉帧率	P95 帧间隔	最大卡顿
FluxDB	52.64	12.27%	16.67 ms	300 ms
DBX	50.48	15.87%	33.33 ms	516.67 ms
DBeaver	43.48	27.53%	33.33 ms	483.33 ms

平均 FPS 上，DBX 和 FluxDB 很接近：

FluxDB：52.64 fps
DBX：50.48 fps
DBeaver：43.48 fps

但真正拉开体验差距的是帧间隔：

FluxDB 的 P95 是 16.67ms，大部分时间维持接近 60fps 的节奏；
DBX 和 DBeaver 的 P95 是 33.33ms，相当一部分时间掉到 30fps 的节奏；
DBX 的平均帧率不低，但最大卡顿达到 516.67ms，滚动时更容易感觉到一顿一顿。

平均 FPS 接近，不代表看起来一样顺。

如果帧间隔在 16ms 和 33ms 之间来回跳，眼睛会感知为轻微顿挫。对数据表格这种大面积滚动内容，P95 帧间隔比平均值更接近真实体感。

五、为什么 FluxDB 更轻？

1. 没有 WebView 这一层

FluxDB 使用 GPUI 直接渲染桌面界面，不经过 HTML/CSS/DOM 和系统 WebView。

DBX 使用 Tauri 2 + Vue 3，这是很成熟的技术选择，开发效率高、界面能力强；但它依然需要 WebView 进程、前端运行时和 Rust/前端通信。本次采样中 DBX 运行了 4 个进程。

这不是说 WebView 不好，而是它确实有额外的固定成本。

2. 结果分页和文档虚拟列表

1 万行结果不是 1 万个控件。

FluxDB 的 SQL 结果按页加载，不会一次把整张表的结果全部构建成控件；MongoDB 文档页使用虚拟列表，只构建当前视口附近的卡片，并缓存整页解析结果，避免滚动时重复解析 JSON。

对宽表尤其重要。30 列 × 1 万行，如果真的构建 30 万个单元格，内存和布局开销会迅速放大。

3. 关闭页面后更积极地释放

FluxDB 关闭结果页后，内存从查询/滑动的两百多 MiB 回落到约 191 MiB。

这并不代表它"没有缓存"，而是缓存没有长期占着不放。对需要不断切换数据库、Schema 和标签页的用户来说，稳态内存比峰值更能决定一天的使用体验。

4. 进程模型更简单

本次采样中：

FluxDB 通常 1 个进程；
DBeaver 1--2 个进程；
DBX 4 个进程。

footprint -t 已经把子进程合并统计，所以这些数字已经算在总内存里。进程越多，基础运行时和跨进程通信的固定成本通常越高。

六、DBeaver 和 DBX 的优势也必须说

这不是一篇"FluxDB 全面碾压"的文章。

DBeaver 的优势

支持超过 100 种数据库驱动；
130+ 插件，生态成熟；
功能覆盖极广：数据编辑、ER 图、迁移、执行计划、空间数据等；
Java + Eclipse RCP 的插件体系适合大型团队扩展。

代价是 JVM、Eclipse 平台和插件体系会带来更高的固定内存。

DBX 的优势

100+ 数据库、25 MB 安装包；
Tauri 2 + Vue 3 让界面迭代很快；
支持桌面、Docker、CLI、MCP；
本次测试中平均 FPS 已经接近 FluxDB。

它的内存和帧节奏不如 FluxDB 稳定，但产品成熟度和跨端能力很强。

FluxDB 的定位

FluxDB 当前支持 9 种数据库：

MySQL
PostgreSQL
SQL Server
Oracle
SQLite
TiDB
达梦 DM8
MongoDB
Redis

它把重点放在原生桌面交互、SQL 编辑、数据编辑、MongoDB/Redis 工作台和 AI 权限边界上，而不是追求"所有数据库都支持"。

七、复现方式

测试 PostgreSQL：

bash 复制代码

podman run -d \
  --name fluxdb-bench-pg \
  -e POSTGRES_USER=bench \
  -e POSTGRES_PASSWORD=bench_only \
  -e POSTGRES_DB=bench \
  -p 127.0.0.1:55433:5432 \
  -v fluxdb-bench-pgdata:/var/lib/postgresql/data \
  postgres:16-alpine

连接信息：

text 复制代码

Host: 127.0.0.1
Port: 55433
Database: bench
User: bench
Password: bench_only

查询：

sql 复制代码

SELECT *
FROM public.bench_orders
ORDER BY id
LIMIT 10000;

内存采集：

bash 复制代码

scripts/bench-memory-macos.sh fluxdb
scripts/bench-memory-macos.sh dbx
scripts/bench-memory-macos.sh dbeaver

FPS 分析：

bash 复制代码

scripts/bench-fps-macos.sh FluxDB ~/Desktop/fluxdb-scroll.mov --start 5 --end 30
scripts/bench-fps-macos.sh DBX ~/Desktop/dbx-scroll.mov --start 5 --end 30
scripts/bench-fps-macos.sh DBeaver ~/Desktop/dbeaver-scroll.mov --start 5 --end 30

最后

这次对比最有意思的地方，不是"Rust 赢了谁"，因为 DBX 也是 Rust。

真正的差异是：

GPUI 直接渲染、单进程、结果虚拟化和更积极的缓存释放，让 FluxDB 在长时间打开、宽表滚动这个场景里更轻。

Tauri + Vue 让 DBX 的开发效率和跨端能力更强，代价是 WebView 和多进程带来的固定成本。

Java + Eclipse RCP 让 DBeaver 拥有最成熟的功能和插件生态，代价是更高的运行时开销。

如果你经常同时管理多个数据库、查询宽表、长时间滚动结果，欢迎试试 FluxDB：

github.com/fluxdb-alt/...

项目是 GPL-3.0 开源，支持 macOS、Windows 和 Linux。