DBX and SQLly: two Rust database clients, measured

DBX is an open-source database client whose first commit landed on 29 April 2026. Six months later it has around 9,300 commits, 28,000 GitHub stars, and a README that opens with “100+ databases in 25 MB”. Like SQLly, it is written in Rust. Its macOS download is 45.2 MB, and SQLly’s is 65.6 MB.

The obvious question is why two Rust database clients end up so far apart. The answer is one architectural decision, and following it explains most of the other differences between the two apps as well: features, performance, and who each one is for. The side-by-side table lives on the SQLly vs DBX page. This post is the reasoning behind it.

Same language, different interface

DBX is a Tauri 2 app. Its database drivers are Rust: sqlx, tiberius, redis-rs and the MongoDB driver. Its interface is a Vue 3 web app with Tailwind and CodeMirror 6, running in the browser engine the operating system already has: WebKit on macOS, WebView2 on Windows, WebKitGTK on Linux. That engine is tens of megabytes of code DBX never has to ship.

SQLly draws its whole interface itself, on the GPU, through Metal, Direct3D or Vulkan. The editor, the grid, the text shaping and the layout are all compiled Rust inside the app binary. There is no browser engine anywhere. That costs size, and it is a deliberate trade.

Where the megabytes go

Both projects ship a single Mach-O executable on Apple Silicon, so the two can be opened up and compared section by section. DBX’s binary is 80.4 MB and SQLly 1.27’s is 195.8 MB. The macOS size tool splits them into parts:

size -m DBX.app/Contents/MacOS/dbx
size -m SQLLY.app/Contents/MacOS/SQLLY

Part of the binary	SQLly	DBX
Machine code	106.0 MB	56.9 MB
Symbol table	52.6 MB	0.7 MB
Unwind tables	15.1 MB	0.1 MB
Constant data	13.3 MB	17.7 MB

Four things account for nearly all of the gap.

• The symbol table. SQLly ships function names inside the binary so a panic backtrace in the crash log reads as code rather than raw addresses. DBX strips them, which its release profile sets with strip = true.
• Unwind tables. DBX builds with panic = "abort", so a panic ends the process and the unwinding metadata can go. SQLly unwinds, because a few background jobs, the self-updater among them, catch a panic and report it instead of closing the window.
• DuckDB. SQLly compiles DuckDB’s C++ engine into the app, about 53,000 symbols of it. DBX runs DuckDB as a separate helper process, so none of it sits in the main binary.
• Compiler settings and the renderer. DBX builds with opt-level = "s", which tells the compiler to prefer smaller code. SQLly builds for speed, and its machine code also contains the GPU renderer, text shaping and widgets that DBX gets from the webview.

The constant data row runs the other way. DBX’s interface is stored there as JavaScript and CSS. Its interface is compact data interpreted by a browser engine it borrows. SQLly’s interface is compiled code.

What stripping would buy

The symbol table looks like a free 50 MB, so it was tested. Stripping a copy of the SQLly 1.27 binary took it from 195.8 MB to 146.9 MB on disk. Compressed the way a download is, the same change saved only about 6 MB, from 60.5 MB to 54.9 MB, because function names are repetitive text and compress very well.

So most of the download gap is the renderer and the embedded DuckDB. The symbols are still worth moving out of the app into a separate debug file kept per release. That shrinks the install and, done with line tables, makes crash reports more useful than they are today, since a separate file can carry file and line numbers that the shipped binary currently does not.

What the architecture means for speed

Both apps keep their drivers in Rust, so neither pays for a Java or Node.js runtime on the query path. The difference is the trip from the driver to your screen. A side-by-side benchmark of the two running apps has not been done yet, so what follows describes each design rather than timing it.

In DBX, result rows cross the Tauri bridge from Rust into JavaScript. The project ships MessagePack and CBOR codecs to keep that crossing cheap, and the rows then land in a virtual-scrolled grid with pagination. The webview also runs in its own content processes, and DuckDB, plugins and the optional JDBC agent run as helpers of their own.

In SQLly, rows never leave the process. A dedicated engine thread reads them off the wire in batches, hands them through a bounded queue that pushes back when the grid falls behind, and spills a result to a typed file on disk once it passes 50,000 rows or 64 MiB. Memory stays flat at 50 million rows, and the grid paints straight from that file. The details are in how SQLly streams huge result sets.

There is a consistency point too. A webview app looks and performs like whatever engine each operating system provides, which differs between WebKit, WebView2 and WebKitGTK. SQLly runs the same renderer on all three, so a layout or performance fix lands everywhere at once.

Wide versus deep

The feature lists follow from the same split. A web interface makes breadth cheap: a new data source needs a driver and some Vue screens. DBX lists more than 100 data sources, many through a Java-based JDBC agent, including MongoDB, Elasticsearch, vector databases, Snowflake and BigQuery. It has consoles for Kafka, RabbitMQ, Pulsar and MQTT, a signed plugin store with Go and TypeScript SDKs, an MCP server and CLI, and the same app as a Docker-hosted web version. It is Apache 2.0, with no paid edition.

SQLly connects to 30 engines, relational, analytical and Redis, and spends its effort on what happens after you connect. Autocomplete offers a column’s real values and writes a join’s ON clause from actual foreign keys. Safety settings stop an UPDATE with no WHERE and inherit down a client, project and environment tree. Admin tools such as the activity monitor, backup and restore, and schema compare open destructive work as SQL to read first. A one-line comment can pivot or chart a result and keep that layout with the query. The bridge and relay reach a private database without opening a port.

Choosing between them

The two tools answer different questions, so the choice comes down to a few concrete conditions.

• Choose DBX if you need MongoDB, a search or vector store, a message queue, or a JDBC-only warehouse such as Snowflake today. Choose it too if the tool must be open source or free at any company size, if a team needs a hosted web version, or if you are on an Intel Mac or Windows 7.
• Choose SQLly if most of your day is SQL against relational or analytical databases and you want the client to know your data: completions from real values, guardrails per environment, and results that stay responsive at tens of millions of rows.
• If download size decides it, DBX’s standard downloads are 20 to 27 MB smaller on macOS, Windows and Linux. Most of that gap comes from the interface choice, so it is unlikely to close completely.

DBX is pre-1.0 and ships around 50 commits a day, so check its repository for the current state of anything that matters to you. The full feature table, with SQLly’s honest status badges, is on the SQLly vs DBX page.