VeloxDB: a desktop client for thirteen database engines, built on Tauri

Thirteen engines, one window, no server in the middle

VeloxDB is a desktop database client, MIT licensed and built for developers, and its central claim is that it connects directly to your databases with no cloud, no middleware and no telemetry. The tagline in the README is Databases, unleashed on your desktop.

The engine list is the headline feature, and the README says thirteen. They fall into families that the documentation makes explicit. Relational SQL covers PostgreSQL, MySQL, SQLite, Microsoft SQL Server and Azure SQL. Analytical and warehouse work covers DuckDB and ClickHouse. Distributed NoSQL covers Apache Cassandra and ScyllaDB. Edge and cloud SQLite covers LibSQL and Turso. Document stores covers MongoDB, and in-memory caches covers Redis.

The drivers are named per engine, which tells you a lot about how the connections actually work. PostgreSQL uses the native tokio-postgres with deadpool-postgres for pooling. MySQL and SQLite both go through sqlx. DuckDB uses a bundled native driver. ClickHouse is reached over an HTTP API with the FORMAT JSON response format rather than a wire protocol client. Microsoft SQL Server and Azure SQL share the tiberius TDS driver. Cassandra and ScyllaDB both use the scylla async CQL driver. MongoDB uses the native Rust driver, and Redis uses the redis tokio async driver.

That mixture is the honest shape of the project. There is no single abstraction over these engines, so each one gets a hand-picked client library, and the feature table in the README shows the result. PostgreSQL gets the full SQL workspace, ER diagrams, EXPLAIN ANALYZE, SSL/TLS, an SSH tunnel and keychain integration. Azure SQL requires SSL/TLS. Redis gets DB index selection and command completions, and nothing about schemas.

The platform story is a native desktop application on macOS, Linux and Windows, powered by Rust and Tauri 2, and the claim of zero latency from cloud proxies follows directly from connecting to the database rather than to somebody else's service.

The query workspace and the results grid

The query side is built on CodeMirror 6, and the dialect list is per engine, covering MSSQL, Cassandra, SQLite, StandardSQL, PostgreSQL and MySQL, with MongoDB JavaScript and the Redis CLI handled as well. The autocompletion is schema aware, with table and column suggestions derived from live introspection of the connected database rather than from a static list.

Several features here are the kind you only add after using the tool for a while. There is real-time linting, where syntax is validated live against the database server as you type, which catches a malformed statement before you run it. There is a multi-tab workspace, and each tab is independently attached to any connected engine, so you can have a Postgres query and a DuckDB query side by side. There is per-connection query history with full-text search, filtering and starred snippets. There is a virtual results grid with inline cell editing, row insertion and row deletion. There is EXPLAIN ANALYZE with visual node breakdowns for the engines that support it. Results export to CSV, JSON, PDF or SVG, and SQL formatting is one keystroke away, powered by sql-formatter.

The virtual results grid is the piece with the biggest effect on how the tool feels. The README describes virtual scrolling for massive result sets, loading only what is visible on screen so that million-row queries stay fast and responsive. This is a client-side decision, and it is the one that makes a desktop client viable against a warehouse, where a naive fetch-everything grid would fall over.

Behind the interface, the front end stack is React 19 with Vite, TanStack Query for server state and TanStack Table and TanStack Virtual for the grid, react-hook-form with zod for forms, and shadcn with Radix and Tailwind for the component layer. State is held in zustand and localisation runs through i18next, which is a detail worth noting for a tool whose audience is international.

The ER diagram is a schema editor, not a drawing

The second half of the application is a visual model workspace, built on ReactFlow 12, and the important thing about it is that it is connected to the live database rather than being a separate diagramming tool.

You introspect the schema, drag tables from the schema catalog onto the canvas, connect columns visually to define foreign key relationships, and the layout is handled for you with grid, topological and Dagre-based graph layout algorithms. The auto-layout choices matter, because a hand-placed diagram of fifty tables is not something anyone maintains.

Then the editing goes further than a picture. You can rename tables, alter data types, and add or drop columns directly on the diagram. The metadata inspector manages indexes, triggers, rules and row-level security policies. And before anything is executed, the migration preview shows the generated DDL so you can review the script against your database. That preview step is the feature that makes visual schema editing safe to use on anything you care about, and its presence says the author has seen visual editors change things by accident.

Diagrams can be exported as high-resolution PNG or PDF, and the export is done with html-to-image, which is why that library is in the dependency list.

The visual model workspace is the part most likely to be uneven across engines. The metadata inspector covers indexes, triggers, rules and row-level security, and those concepts differ sharply between PostgreSQL, MySQL, SQL Server, MongoDB and Redis. Expect to find that the deeper a metadata feature goes, the more likely it is to be a subset for a given engine rather than the full thing.

Credentials, tunnels and the trust boundary

The connection management section is where a database client earns its keep, and VeloxDB covers the parts that matter in a corporate environment.

Connection strings are first-class, with support for postgresql://, mysql://, clickhouse://, turso://, cassandra:// and mssql:// style URIs and real-time engine detection, so pasting a URL picks the right engine. SSH tunnelling is supported with public key or password authentication, which is how you reach a database that is not directly exposed. SSL/TLS modes can be set to Disable, Prefer or Require, with custom CA certificates, and the Azure SQL row in the table says SSL/TLS is required for that engine specifically.

Credentials go to the operating system keychain rather than into a config file. The README names macOS Keychain and Windows Credential Manager, and the row for every engine in the support table ends with Keychain, so this is applied uniformly rather than being an option for some connections.

The no telemetry and no cloud claim is the other half of the trust story. The application talks to your database and, when you configure one, to a bastion host. It does not phone home. For a tool that holds credentials to production systems, that is a meaningful property, and it is a design decision the project is making rather than a policy document, since the README is a product page rather than a security document. The repository does carry a CODE_OF_CONDUCT.md and a CONTRIBUTING.md, and the tree includes a docker-compose.pg.yml for running PostgreSQL locally, which is what you would expect from a project whose contributors need a database to develop against.

Release pace and the shape of the repository

The version history shows a project moving quickly through its first year. v0.3.1 was a stability pass on 2026-08-07, v0.4.0 on 2026-09-07 was the polyglot engine and CodeMirror migration, and v0.4.1 on 2026-10-18 was a reliability and engine fixes release. The last push was on 2026-10-18, the same day as the latest tag, so the project is being worked on rather than abandoned.

Two of those release titles are informative. The polyglot engine release in September is when the multi-database support landed, and the CodeMirror migration in the same release explains why the editor packages in the manifest are CodeMirror 6 with dialect language packages rather than the older view. The October release being about reliability and engine fixes is the expected shape of the first release after a large feature lands, and it is a good sign that it was followed up.

The repository is a pnpm workspace with the package manager pinned to pnpm 10.12.1, and the front end scripts show the shape of the loop: dev runs vite, tauri runs tauri dev, tauri:build runs tauri build, build runs tsc -b and vite build, lint runs eslint, and test runs vitest.

The Tauri layout is visible in the tree, with a src-tauri/ directory holding the Rust side and src/ holding the React side, plus a build/ directory, a public/ directory, a components.json for the shadcn component registry, and separate TypeScript configuration files for the app and the node tooling. The shadcn and Radix dependencies, along with tailwind-merge and class-variance-authority, are the standard stack for a shadcn based interface.

The version number is 0.4.1 in the manifest and the package is marked private, which is consistent with a desktop application rather than a published library. There is no separate server component to deploy, and no client package to consume.

Where VeloxDB is the wrong tool

The first wrong case is a team that needs a shared, governed client. VeloxDB is a desktop application with per-user local credentials in the operating system keychain. There is no shared configuration, no central policy, no audit trail of who ran which query, and no server mode. For a regulated team, that is a blocker rather than a limitation, and a web client with a backend is the shape that solves it.

The second is a support or on-call workflow. A database client that lives on your own machine cannot be reached from a phone, cannot be scripted by a colleague, and does not have a shared connection inventory. If part of your job is helping other people with their data, the tool that serves you is not the tool that serves them.

The third is a feature that the README does not list. Thirteen engines means thirteen different SQL dialects, and the dialect list for the editor covers MSSQL, Cassandra, SQLite, StandardSQL, PostgreSQL and MySQL, which is six dialects, not thirteen. DuckDB, ClickHouse, LibSQL, Turso, MongoDB and Redis are served by their own workspace types, and the per-engine feature table shows the variance clearly, with Redis offering command completions but no schema exploration, and ClickHouse offering EXPLAIN SYNTAX rather than EXPLAIN ANALYZE. The breadth is genuine and the depth is uneven, and that is the correct way to think about buying into it.

The fourth is a 0.x version with an unversioned API. There is no GitHub release for a distribution channel, the repository has a CHANGELOG.md but the README is a product page, and a release title like reliability and engine fixes does not tell you what changed. If you adopt this, pin a version and read the changelog before upgrading.

Editorial conclusion

Adopt VeloxDB if you switch between several database engines daily and want one native window with a schema-aware editor, an ER canvas and credentials in the operating system keychain, since the connections are direct and nothing leaves your machine. Be more cautious if you need a team-shared, audited tool or a stable release line, because the project is at version 0.4.1 with a 0.x version number and the README itself flags no telemetry as a design choice rather than a policy commitment. Before you install it, check which of the thirteen engines you actually need against the driver column in the support table, since features differ per engine, and note that the release is built with pnpm 10.12.1 and Tauri 2 with a Rust core.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. veloxbase/veloxdb on GitHub