veloxdb

Talk to your database. VeloxDB is a local-first, AI-native desktop client for 13 engines fast SQL, visual schema design, and your data stays on your machine.

Comment

Inspiration

I live in Ethiopia, in Africa, and I spend a huge part of my day inside a database client. That is the job. Schema, queries, a broken join, then another query. For a long time that tool was pgAdmin. It worked, until it did not. It was slow to open, heavy while I was just trying to look at a table, and every extra click added up across a full day of work.

The frustration was not one bad afternoon. It was the hours. When you live in a database client, a sluggish one is not a small annoyance. It is the place you work. I kept thinking the client should know the schema I was staring at, and that I should be able to ask for the query instead of writing the same kind of SQL from scratch again.

That is what pulled me toward AI. Not as a demo, and not as a chatbot in another tab. I wanted it in the tool I already had open all day, writing SQL for the database I was actually connected to. I am in Ethiopia, and I did not want my tables or passwords shipped to some random server just so the assistant could help. So I started building VeloxDB.

What it does

VeloxDB is a native desktop client for 13 engines: PostgreSQL, MySQL, SQLite, DuckDB, ClickHouse, Redis, MongoDB, LibSQL, Turso, ScyllaDB, Cassandra, SQL Server, and Azure SQL.

You connect directly. There is no cloud proxy in the middle. Credentials go into the OS keychain, and you can tunnel through SSH when the database is not on the public internet.

Day to day it is the workspace I wished pgAdmin had been:

  • A CodeMirror editor with dialect highlighting, schema autocomplete, and live linting
  • Tabs so one query can be Postgres and the next can be Redis
  • A virtualized results grid that stays usable on big result sets, with inline edits and CSV or JSON export
  • A visual ER canvas where you can drag tables, draw foreign keys, and export the DDL
  • Veloxy, the copilot. You ask in English. It writes the query in the dialect of the connection you are on, using your schema, not a guessed one

Ask it for monthly signups and you get SQL. Ask the same thing on ClickHouse or Cassandra and the syntax actually changes. If the server throws an error, Veloxy can read that error and propose a fix you run yourself.

How we built it

The UI is React 19 and TypeScript. The desktop shell is Tauri 2. Anything that talks to a database lives in Rust, so the app is not dragging a JVM or a bundled browser just to run SELECT 1.

Each engine has its own driver instead of one leaky abstraction. Postgres goes through tokio-postgres, MySQL and SQLite through sqlx, SQL Server through tiberius, Cassandra and Scylla through the scylla driver, and ClickHouse, Turso, and LibSQL over HTTP. Mongo and Redis have their own clients too. The frontend never opens a socket. It calls a repository, and Tauri IPC carries that into Rust.

Veloxy is the part I spent the most time on, because that was the whole point after years of living in pgAdmin. Before a prompt goes out, we build a small picture of the schema: tables, columns, types, and keys. The system prompt then gets dialect rules for that engine. T-SQL wants TOP, ClickHouse wants countIf, CQL wants partition keys, Mongo wants an aggregation pipeline. The model sees metadata. It does not see your rows.

The editor is CodeMirror 6. Diagrams are React Flow with a Dagre layout so a 200-table schema does not land in one pile. The grid is TanStack Virtual, because rendering a million DOM rows is how database apps freeze.

The site at veloxdb.dev is a separate Next.js app. Installers ship for macOS, Windows, and Linux.

Challenges we ran into

Thirteen databases do not share a query language. LIMIT is not TOP. CQL will refuse a query that SQL would happily scan. Redis is not SQL at all. Every time I added an engine, something in autocomplete, history, or the AI prompt assumed "it is basically Postgres."

SSH tunnels plus TLS plus the OS keychain was another long week. A connection can fail in five different places, and the error the user sees has to say which one. macOS Keychain, Windows Credential Manager, and Linux Secret Service do not behave the same, and a desktop app that loses your password on restart is not a database client.

The results grid was the performance fight. Loading every cell into React works until someone runs SELECT * on a real table. Virtualizing rows fixed the scrolling, then inline editing and exports had to work on the rows you cannot see.

Schema diagrams had the same shape of problem. Introspecting a large catalog is fast in Rust. Laying it out so a human can read it is not. Auto-layout helped, and people can still drag tables onto the canvas instead of dumping the whole database at once.

Building this from Ethiopia also meant I cared a lot about the app working offline and on a normal laptop. If the tool is heavy, or if the AI only works by uploading your database, it is not useful where I work.

Accomplishments that we're proud of

I shipped a real app, not a demo that only talks to one local Postgres. v0.4.0 runs on three operating systems, with native drivers for all 13 engines, and people can download it and connect to a database they already have.

The part I am most proud of is Veloxy. I used to lose time in pgAdmin writing and fixing the same queries. Now I can ask in English, get SQL that matches the engine I am on, and keep the rows on my machine. You can bring your own key, or run a local model. The copilot sits in the editor, next to the error, not in a separate browser tab.

The unglamorous pieces are there too: SSH, SSL, keychain storage, query history, ER diagrams, and a grid that does not fall over. Those are the things you notice at 11pm when the tool either works or you go back to psql.

What we learned

A database client is mostly edge cases. The happy path is one query and a table. The product is the bad connection string, the expired cert, the query that returns more rows than the screen, and the model that invents a column.

I also learned that "AI for SQL" is useless without the schema in the prompt and the dialect written down as rules. A strong model still writes LIMIT on SQL Server if you do not tell it not to. Giving it less data, just the catalog, made the answers better and made the privacy story obvious.

Spending that many hours in pgAdmin is what made the AI part obvious to me. The model is not the product. The product is getting a correct query back while I am still in the flow of work. Rust was the right call for drivers and pooling, and it was slower to start. The payoff showed up when I added engine number eight and the UI did not have to know how the socket worked.

What's next for veloxdb

The editor and the copilot work for one person at one machine. Next is making that useful for a team: shared queries, saved dashboards, and a place to keep schema notes without standing up a BI server.

I want Veloxy to go further than writing the first query. When something is slow, it should read the plan, point at the sequential scan, and suggest the index. When a query fails, the fix should be one click, and you should still be the one who runs it.

After that, the same local client should be a safe way for an agent to inspect a database: schema in, answer out, rows staying where they are. I am building that from Ethiopia, and I want it to be a tool people anywhere can trust with a production database.

Built With

Share this project:

Updates

Submission history