FluxDB vs DBX vs DBeaver: A Real-World Test of GPUI, Tauri, and Eclipse Stacks

Database clients all look similar: an object tree on the left, a SQL editor on the right, and a results table below.

But what truly determines the experience is often not the feature list, but the few seconds after a query runs:

• How much memory grows when loading 10,000 rows of results;
• Whether the view stays responsive when scrolling a wide table;
• Whether memory goes back down after closing a results page;
• Whether the app gets heavier with multiple connections open.

I've been building FluxDB, a database client built with Rust + GPUI. This time I compared it against two mature projects in identical scenarios:

• FluxDB: Rust + GPUI, this test version 0.1.14
• DBX: Rust + Tauri 2 + Vue 3/TypeScript, this test version 0.5.30
• DBeaver: Java + Eclipse RCP/SWT, this test version 26.2.0

Conclusion first:

On this Mac, with the same 200k-row table and the same 10k-row query, FluxDB used the least memory and had the most stable scroll frame intervals. DBX's average FPS was close, but its P95 frame interval and maximum stalls were worse. DBeaver was weakest on memory and smoothness, but its feature coverage and plugin ecosystem remain the most mature of the three.

This is not a language war. DBX also uses Rust. The differences come more from the UI runtime, process model, result caching, and scrolling implementation.

1. Where the Three Stacks Differ

First, let's lay out the three projects' tech stacks.

FluxDB: Rust + GPUI

FluxDB's desktop layer is based on Rust + GPUI:

• UI is rendered directly by GPUI, no Electron dependency;
• No system WebView;
• App logic, connectors, and UI all live inside the Rust project;
• SQL results load page-by-page, and the MongoDB document area uses a virtual list that only builds content near the viewport;
• Simple process model; this sampling usually sees only 1 process.

GPUI is not a wrapper around traditional system controls. It is a GPU-accelerated UI framework in the Rust ecosystem. Its advantages are a short rendering path and few process boundaries, making it suitable for high-refresh interfaces like data tables.

DBX: Rust + Tauri 2 + Vue 3

DBX is also a Rust project, but its desktop architecture is different:

• Rust backend: database drivers, query execution, and file handling;
• Tauri 2: desktop shell and system WebView;
• Vue 3 + TypeScript: frontend UI;
• CodeMirror 6: SQL editor;
• This sampling showed 4 processes running.

This is a mature cross-platform stack. Rust handles the low-level and performance-sensitive parts, while the WebView handles building complex UIs quickly. The cost is an extra frontend runtime, a WebView process, and a frontend-backend communication boundary.

DBeaver: Java + Eclipse RCP

DBeaver is a typical large Java desktop application:

• Java/OpenJDK 25 runtime;
• Eclipse RCP rich client platform;
• OSGi plugin system; the community edition includes 130+ plugins;
• SWT/JFace desktop UI;
• JDBC for database connectivity;
• This sampling counted 1-2 processes.

This architecture has obvious strengths: plugin-based, wide database driver coverage, and mature features. The cost is that the JVM, Eclipse platform, and plugin system themselves consume a fixed amount of memory.

2. Test Environment

Test machine:

Item	Configuration
Machine	MacBook Pro
Chip	Apple M3, 8-core
Memory	16 GB
OS	macOS 14.2
Main display	3024 x 1964 Retina

Test data:

Item	Configuration
Database	PostgreSQL 16
Location	local Podman container
Table	public.bench_orders
Data amount	200k rows, 30 columns, ~278 MB
Content	includes JSONB nested objects, long text, numbers, and plain strings
Query	SELECT * FROM public.bench_orders ORDER BY id LIMIT 10000

To keep results comparable:

• All three clients connect to the same database;
• They execute the same SQL;
• Window width is consistent, about 3022 x 1750;
• Each runs separately, and each app fully exits after its test;
• Memory sampled every 0.5 seconds, child processes included;
• Screen recording unified at 60fps, with intro preparation and ending operations trimmed.

3. Memory Measurements

Memory usage was measured with macOS's footprint -t, not just RSS. The -t flag totals subprocess memory, so WebView or JVM processes are not missed.

The final numbers are the median of the last two valid runs, in MiB:

Scenario	FluxDB	DBX	DBeaver
Idle average	134.6	200.1	411.2
Query peak	264.5	551.8	827.8
Scroll average	272.7	624.7	625.9
Scroll peak	279.5	710.4	687.1
Post-close steady	191.3	411.3	467.8

From these numbers:

• Idle memory: FluxDB is ~33% lower than DBX and ~67% lower than DBeaver;
• Query peak: FluxDB is ~52% lower than DBX and ~68% lower than DBeaver;
• Scroll average: FluxDB is ~56% lower than both;
• Post-close steady: FluxDB is ~53% lower than DBX and ~59% lower than DBeaver.

Idle memory

FluxDB sits around 135 MiB, DBX around 200 MiB, DBeaver around 411 MiB.

This is the most direct illustration of runtime differences. Database clients are typically left open all day. Idle memory is not a one-time number; it's a resource consumed for the entire session.

Query peak

After loading the 10k-row, 30-column result set:

• FluxDB peaks around 265 MiB;
• DBX peaks around 552 MiB;
• DBeaver peaks around 828 MiB.

All three received the same data. The differences come from result models, table building, caching strategies, and runtime overhead, not from how fast the database returned the data.

After closing the result page

Steady state 30 seconds after closing the result page:

Client	Idle	Post-close
FluxDB	134.6	191.3
DBX	200.1	411.3
DBeaver	411.2	467.8

DBX goes from 200 MiB idle to 411 MiB after closing. This indicates the result page retains a significant amount of memory. It may not be a leak; it could be a more aggressive caching strategy or the WebView processes not releasing yet. But for a database tool that needs to be open for long periods with multiple connections, this buildup adds up.

4. Scroll Smoothness

FPS cannot rely only on the app's own counters, because the three applications have different kernels and rendering methods.

This time we uniformly recorded the macOS window:

1. Record only the target application's window;
2. Continuously scroll the result set for about 20 seconds;
3. Trim the beginning preparation and ending stop;
4. Take the valid 5-30 second interval;
5. Remove duplicate frames, then calculate effective FPS, P95 frame interval, and max stall.

Results:

Client	Effective FPS	Estimated dropped frame rate	P95 frame interval	Max stall
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

On average FPS, DBX and FluxDB are close:

• FluxDB: 52.64 fps
• DBX: 50.48 fps
• DBeaver: 43.48 fps

But the real differentiator is frame interval:

• FluxDB's P95 is 16.67ms, staying close to a 60fps cadence most of the time;
• DBX and DBeaver's P95 is 33.33ms, meaning a significant portion of time drops to a 30fps cadence;
• DBX's average FPS is not low, but its max stall reaches 516.67ms, making scrolling feel more jerky.

Average FPS being close does not mean they look equally smooth.

If the frame interval oscillates between 16ms and 33ms, the eye perceives slight stutter. For data tables with large scrolling areas, P95 frame interval is closer to real perceived smoothness than the average.

5. Why FluxDB Is Lighter

1. No WebView Layer

FluxDB uses GPUI to render the desktop interface directly, without going through HTML/CSS/DOM or the system WebView.

DBX uses Tauri 2 + Vue 3, a mature choice that offers high development efficiency and strong UI capabilities. But it still requires a WebView process, a frontend runtime, and Rust/frontend communication. This sampling saw 4 processes for DBX.

This is not to say WebView is bad, only that it carries extra fixed costs.

2. Paginated Results and Virtualized Document Lists

10,000 rows of results are not 10,000 widgets.

FluxDB loads SQL results page by page; it does not build the entire result set into widgets at once. The MongoDB document page uses a virtual list, building only cards near the current viewport, and caches the full page's parsed result to avoid reparsing JSON when scrolling.

This matters especially for wide tables. 30 columns x 10,000 rows would mean 300,000 cells if actually constructed, quickly inflating memory and layout costs.

3. More Aggressive Release After Closing Pages

After closing a result page, FluxDB's memory falls from the 200-something MiB used during query/scroll back to about 191 MiB.

That does not mean there is no cache; it means cached data does not stay occupied indefinitely. For users who constantly switch databases, schemas, and tabs, steady-state memory matters more than peak for the whole-day experience.

4. Simpler Process Model

In this sampling:

• FluxDB typically runs 1 process;
• DBeaver runs 1-2 processes;
• DBX runs 4 processes.

footprint -t already aggregates subprocess memory, so these numbers are included in total memory. The more processes, the higher the fixed cost of base runtime and cross-process communication.

6. DBeaver and DBX's Strengths Must Also Be Stated

This is not an article claiming "FluxDB dominates everything."

DBeaver's strengths

• Supports over 100 database drivers;
• 130+ plugins, mature ecosystem;
• Very broad feature coverage: data editing, ER diagrams, migration, execution plans, spatial data, etc.;
• Java + Eclipse RCP plugin system suits large team extension.

The cost is that the JVM, Eclipse platform, and plugin system bring higher fixed memory.

DBX's strengths

• 100+ databases, 25 MB installer;
• Tauri 2 + Vue 3 allows rapid UI iteration;
• Supports desktop, Docker, CLI, and MCP;
• Average FPS in this test already approached FluxDB's.

Its memory and frame pacing are not as stable as FluxDB's, but its product maturity and cross-platform capability are strong.

FluxDB's positioning

FluxDB currently supports 9 databases:

• MySQL
• PostgreSQL
• SQL Server
• Oracle
• SQLite
• TiDB
• DM8 (Dameng)
• MongoDB
• Redis

It focuses on native desktop interactions, SQL editing, data editing, MongoDB/Redis workbenches, and AI permission boundaries, rather than trying to support every database.

7. Reproduction Steps

Test PostgreSQL:

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

Connection info:

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

Query:

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

Memory collection:

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

FPS analysis:

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

Final Thoughts

The most interesting part of this comparison is not that "Rust won," because DBX is also Rust.

The real difference is:

GPUI's direct rendering, single process, result virtualization, and more aggressive cache release make FluxDB lighter in the long-session, wide-table scrolling scenario.

Tauri + Vue gives DBX stronger development efficiency and cross-platform ability, at the cost of WebView and multi-process fixed overhead.

Java + Eclipse RCP gives DBeaver the most mature feature set and plugin ecosystem, at the cost of higher runtime overhead.

If you often manage multiple databases at once, query wide tables, and scroll through results for long periods, give FluxDB a try:

https://github.com/fluxdb-alt/fluxDB

The project is open source under GPL-3.0 and supports macOS, Windows, and Linux.