DEV Community

Cover image for I built a 30MB database client in Rust. Here's what it cost me.
Raphael
Raphael

Posted on

I built a 30MB database client in Rust. Here's what it cost me.

DBeaver takes about 8 seconds to start on my machine. It idles around 800MB of RAM before I've opened a single connection. It does everything - and that's exactly the problem. Somewhere along the way, we accepted that database tools have to feel like operating systems.

Six months ago I decided to find out whether that was actually true. The result is QoreDB, an open-source desktop database client that ships as a ~30MB binary and starts in under a second. This post is about the technical bets that made that possible, and the ones I regret.

The core bet: Tauri over Electron

The obvious path for a desktop app in 2026 was Electron. I went with Tauri v2 instead, and the trade is simple to state: Electron bundles Chromium with your app; Tauri uses the OS webview (WebView2 on Windows, WebKit on macOS/Linux) and runs your backend as a native Rust binary.

What I gained, measured on my own builds: an installer around 30MB instead of 150MB+, cold start under a second, and idle memory that stays low enough that users don't notice the app is running. For a tool that positions itself as a "daily driver" you leave open all day, idle footprint matters more than any benchmark.

What it cost me: three rendering engines instead of one. A CSS behavior that works in WebView2 can break subtly in WebKitGTK on Linux. I now maintain a small set of workarounds I would never have needed with Electron's "one Chromium everywhere" guarantee. If your app has heavy, pixel-critical UI, this tax is real. For a data grid and an editor, it turned out to be manageable — annoying, not fatal.

Rust where it counts

The frontend is React + TypeScript, and honestly, that part is boring in the best way. The interesting layer is the Rust backend: connection management, query execution, and streaming results over Tauri's IPC.

Two things Rust bought me that I couldn't have gotten as cheaply elsewhere:

Streaming large result sets without choking. Query results stream from the driver through Tokio into the webview in chunks, and the frontend virtualizes rendering (TanStack Virtual). Scrolling through a million-row table doesn't load a million rows into the DOM — or into memory. The Rust side holds the cursor; the UI only ever sees a window.

Fearless concurrency for connection pools. A database client is fundamentally a concurrency problem: multiple connections, multiple in-flight queries, cancellation, timeouts. The borrow checker made this genuinely harder to write and genuinely easier to trust. I've had exactly zero data races in production. I cannot say that about any concurrent code I've written in other languages.

What it cost me: velocity, especially early. Rust's ecosystem for database drivers is good (SQLx is excellent) but not uniform. Every engine beyond the majors meant evaluating a crate, sometimes wrapping a C library, sometimes writing more protocol code than I'd like. There were weeks where I shipped nothing visible because I was fighting a driver's async model.

One abstraction over SQL and NoSQL

QoreDB currently speaks to 15 engines — PostgreSQL, MySQL/MariaDB, MongoDB, Redis and others — through a single internal abstraction layer. The hard part isn't connecting to 15 databases; it's designing an interface where a document collection and a relational table can be browsed, filtered, and edited with the same UI and the same keyboard shortcuts without lying about their differences.

That abstraction deserves its own post (it's coming), but the short version: I model everything as "resources" with capabilities, rather than pretending everything is a table. A Redis keyspace declares it can't do joins; the UI adapts instead of erroring.

What I'd tell you if you're considering this stack

Tauri is production-ready if your UI tolerates webview differences and you're comfortable in Rust when things break — the escape hatches are Rust, not Node. The performance story isn't hype: the numbers above are real and users notice them immediately. But you're trading Electron's ecosystem maturity for a smaller, sharper toolset. For a solo developer, that trade only works if performance is the product. For QoreDB, it is.

The project is open source (Apache 2.0 core) and I'm building it in public: github.com/QoreDB/QoreDB. Happy to answer anything about the stack in the comments, especially if you've fought the same webview battles.

Top comments (0)