SQLly logoSQLly

Tabularis and SQLly: two Rust SQL clients, two bets

Tabularis keeps three drivers and plugins for the rest; SQLly builds thirty engines in. An honest look at notebooks, web mode, admin tools and price.

By

Tabularis shipped its first release in January 2026. Nine months later it is at version 0.30, has more than five thousand GitHub stars and over a hundred contributors, and publishes a nightly build every morning. SQLly started in June and ships at about the same pace. Both are SQL clients with Rust underneath, both came out of the same year, and people keep asking us how they differ.

This is our answer. We build one of the two, so read it with that in mind. We have tried to state what Tabularis does from its own README and repository, not from our impressions, and to be plain about where it is the better tool.

Same language, different bets

"Written in Rust" covers less than it sounds. Tabularis is a Tauri app: the database work happens in a Rust backend, and the interface is a React application with the Monaco editor, drawn by your operating system's webview. SQLly is Rust from the driver to the pixels. It renders on the GPU through Metal, Direct3D or Vulkan, with no webview in between.

Neither choice is free. Tauri gives Tabularis the whole web ecosystem: Monaco, TanStack Table, React Flow for diagrams, Recharts for charts, and a second front end for almost nothing. That is how tabularis web can serve the same UI to a browser from a container. The native route costs us more per feature, since we build our own editor, grid and diagram canvas, but in return we control every frame, and a fifty-million-row result streams to disk instead of into a JavaScript heap.

Three drivers and plugins, or thirty built in

This is the biggest difference between the two. Tabularis ships three drivers: MySQL/MariaDB, PostgreSQL and SQLite, and its built-in PostgreSQL driver is being retired in favor of a plugin. Everything else is a plugin, a separate program the app talks to over JSON-RPC on standard input and output. Its README lists 26 of them: SQL Server, Oracle, DuckDB, ClickHouse, libSQL, Redis, and also MongoDB, DynamoDB, Firestore, Cassandra, Elasticsearch, BigQuery, Trino and even Google Sheets. Some are maintained by the project and some by community authors.

The design has real strengths. A driver can be written in any language, ships on its own schedule, and a crash stays in its own process. It is also how Tabularis reaches document stores and cloud warehouses that SQLly does not connect to at all. If your data lives in MongoDB or BigQuery, that settles it.

SQLly went the other way. SQL Server, PostgreSQL, MySQL and MariaDB, SQLite, DuckDB, ClickHouse, Oracle, libSQL/Turso and Redis are compiled into the app, which comes to thirty engines once you count hosted and wire-compatible variants. The reason is depth. When the driver is in-process, every engine gets the same IntelliSense, plan views, safety checks and admin tools, and we can test all of it against real servers. It is also why a feature like Schema Compare works across SQL Server, PostgreSQL, Oracle, ClickHouse and the rest instead of one engine at a time.

What Tabularis has that SQLly doesn't

  • It's free and open source. Tabularis is Apache 2.0 with no paid edition; sponsors fund it. SQLly has a free tier for hobbyists, but it caps you at two saved servers and isn't available inside companies with more than 100 employees.
  • SQL notebooks. SQL and Markdown cells in one document, where a cell can reference another cell's result as {{cell_3}} and it becomes a CTE at run time. Add charts, Run All with stop-on-error, and an HTML export, and you have a decent runbook format. We don't have notebooks.
  • A browser mode for teams. tabularis web runs the full UI from a Docker image or Helm chart, with password sign-in and session limits. SQLly's browser build is a single-user page that reaches your databases through a relay you control, not a shared server.
  • A plugin system. Drivers, UI extensions and theme packages, with a signed registry. SQLly has no plugins and doesn't plan any.
  • Twelve interface languages against our two.
  • Packaging. Signed builds for Apple Silicon and Intel Macs, plus WinGet, Homebrew, Snap, Flatpak and the AUR. SQLly's Mac build targets Apple Silicon only, and its Windows and Linux builds are still a supported beta.
  • A first-class MCP server with one-click setup for Claude Desktop, Cursor and Windsurf, and AI text-to-SQL against OpenAI, Anthropic, OpenRouter, Ollama or any compatible endpoint.

What SQLly has that Tabularis doesn't

  • Admin tools. An Activity Monitor with blocking chains, a Server Dashboard, Index Analyzer, security editors, backup and restore, SQL Agent and Extended Events. Tabularis covers SQL dump and import; beyond that it is a query tool.
  • Schema and data compare. Shipped in SQLly, risk-graded, with deploy and rollback scripts. Data compare is an open roadmap item for Tabularis.
  • A grid that does analysis. Pivot, charts, a map, conditional formatting and computed columns over any result, set by a one-line comment that stays with the query, and an Excel export that carries the pivot sheet with it. Tabularis exports CSV and JSON from the grid and keeps its charts in notebooks.
  • Autocomplete built from your data. SQLly offers a join's ON clause from real foreign keys, completes WHERE values from the column's actual contents, and catches GROUP BY mistakes as you type. We wrote about how that works.
  • Layered safety. Read-only connections that also block file-reading and shell-escape tricks, a hard stop on UPDATE or DELETE without WHERE, automatic rollback wraps, and production connections painted red. Tabularis has a per-connection read-only switch, which it also applies to its MCP server.
  • Enterprise sign-in. Microsoft Entra ID, AWS RDS IAM and Google Cloud SQL IAM tokens, still marked in progress in our docs.

Where they overlap

More than you might expect. Both have SSH and Kubernetes tunnels, keychain password storage, a visual query builder, ER diagrams, column masking, customizable keybindings, a command palette, and visual execution plans. Both import connections from other tools, though from different sets: Tabularis reads DataGrip, DBeaver, TablePlus, Sequel Ace and Beekeeper Studio; SQLly reads DataGrip, DBeaver, TablePlus, Navicat and Redis Insight.

On plans, Tabularis is honestly ahead for the engines it covers. Its visual EXPLAIN for PostgreSQL, MySQL and SQLite is shipped. Our plan views cover nine engines and add plan comparison, but the docs still mark them in progress.

Which one to pick

Tabularis fits you if you want free, open software you can extend, if your data lives in MongoDB, BigQuery or another store outside SQL, if notebooks are how you work, or if your team wants one deployment in a browser. It is a young project moving quickly, and some of what we list as missing may already be in tonight's nightly.

SQLly fits you if you work across SQL Server, PostgreSQL, Oracle and friends, if administration is part of the job, if you live in the results grid, or if you want guardrails between you and a production database.

Plenty of people will run both, and there's nothing wrong with that. The side-by-side table, with a status badge on every row, lives at SQLly vs Tabularis, and SQLly's download needs no account.