Why I chose Tauri, and what it cost me | Tabularis Blog

/blog/Why I chose Tauri, and what it cost me

In January I had to choose how to build Tabularis. Electron was the obvious option. Three native applications were the romantic option. Tauri looked like the compromise.

Six months and 64 releases later, I still think it was the right choice. But not for the reason usually printed at the top of Tauri comparison pages.

Yes, the Windows installer is 12 MB. This is nice. It is also the least interesting part.

The sentence that decided the architecture was this:

A database client is a systems program with a UI problem, not a web app with a database problem.

That sentence explains why I chose Tauri. It does not explain the bill. This post is about both.

The program behind the pixels

Below the data grid, Tabularis speaks MySQL, PostgreSQL and SQLite through SQLx. It opens SSH tunnels, asks the OS keychain for credentials, invokes kubectl for port forwarding, encrypts connection backups, and starts plugin drivers as subprocesses speaking JSON-RPC over stdin and stdout.

You can build all of this in Electron. Of course you can. But then I would either implement the backend in JavaScript, maintain native Node modules for every target, or add a Rust sidecar and recreate the same architectural split while still shipping Chromium. Electron's own documentation says native modules usually need to be rebuilt after an Electron upgrade. I did not want the database engine of the application to depend on how well node-gyp felt that morning.

With Tauri, the backend is an ordinary Rust program. SQLx, Tokio, rustls, keyring, AES-GCM: they are normal Rust dependencies, with normal Rust types between them. The backend is not a helper attached to the product. It is the product.

Then the frontend gets the part web technology is genuinely good at: Monaco, a virtualized data grid, forms, diagrams, themes. This separation felt natural to me. More importantly, it was a separation I could maintain alone.

There is also a security argument, but it is easy to exaggerate it.

Code in a Tauri webview has normal web capabilities, including network requests. What it does not get by default is Node.js or arbitrary access to the operating system. Privileged work crosses a defined IPC boundary through Tauri commands and plugin capabilities. In Tabularis I can inspect the command registration and capability files and see what the frontend is allowed to ask for.

This does not make a Tauri application secure by magic. A bad command is still a bad command. A loose capability is still loose, XSS still matters, and the Rust and npm dependency trees are still part of the attack surface. But for an application holding production credentials, I prefer starting from an explicit privilege boundary instead of adding one later.

And then there is size.

These are decimal megabytes from the Tabularis 0.16.0 and Beekeeper Studio 5.9.2 release assets. Beekeeper is a good database client. Its package sizes are not a failure of Beekeeper; they are the price of shipping Chromium, and shipping Chromium also buys you consistency.

Still, a 12 MB Windows installer for a database IDE makes me smile.

The harder comparison is native

Electron is the easy comparison. Native applications are the ones that made me hesitate.

An AppKit application does not care which WebKitGTK version Arch happens to ship. Native controls can offer better input latency, scrolling, text rendering and platform integration. Tauri does not ship a browser engine on most targets, but it certainly runs one, and the webview's memory does not disappear because the installer is small.

Size is not even a native-versus-Tauri argument. Sequel Ace is small too. The small-package story is mostly an anti-bundled-Chromium story.

So why not native? Because native to what?

Sequel Ace gives the honest answer: macOS. It is a focused application and a very good one. TablePlus began on macOS; when its small team built the Windows version, it rewrote the application in C# and C/C++. That is not a criticism. It is what “native on two platforms” actually means.

For Tabularis, native meant three user interfaces: three grids, three editors, three settings screens, three sets of bugs. A cross-platform widget toolkit would move the compromise somewhere else, not remove it.

The web has a component economy that is hard to ignore. Tabularis uses Monaco, the editor inside VS Code. I get multi-cursor editing, folding, search and the keyboard behavior developers already know. I can render an ER diagram and a visual EXPLAIN plan with the DOM. Reproducing that experience with native widgets on three platforms would not be a side quest for me. It would become the project.

When Tabularis started, one person was working on it: me. Yet it had to run on Linux, macOS and Windows, and it now ships in ten languages. Native might win the benchmark while losing the more important test: whether I could actually ship the...