multi database support
dashboard with AI
dashboard builder
query editor
multiple theme support
schema designer
setting to fit your style

VeloxDB

The database studio I wished existed — built from Ethiopia, for anyone tired of waiting on their own tools.

A native desktop client that runs queries across 10+ databases, understands your schema with AI, generates visual data models, and turns results into BI dashboards — without eating your RAM.

Website · GitHub

Inspiration

I am from Ethiopia. I did not start VeloxDB because I wanted another side project. I started it because pgAdmin was winning a fight I never signed up for.

A simple query. That was all I needed. Instead my laptop heated up, RAM climbed, and the UI felt like it was thinking in geological time. When I wanted to migrate a schema, the tool had almost nothing for me. No visual model I could trust. No preview of the DDL. No “here is what will change, now apply it.” I was a developer being slowed down by the thing that was supposed to help me talk to my data.

Then the ambition grew.

At work I kept building analytics dashboards for the company — the same charts, the same KPIs, the same “can you make a dashboard for this?” loop. I would leave the database client, open another stack, wire charts by hand, and ship something that should have been a conversation with the data. One night the thought stopped being quiet:

Why am I building dashboards for a living, when one tool could create them with ease — next to the query, next to the schema, next to the model?

I did not want a heavier pgAdmin. I wanted a studio. A place where query, model, AI, and BI live in the same window. Built on my machine. Fast enough that a developer in Addis, or anywhere else with a laptop that is not a workstation, can still feel fast.

That is VeloxDB.

What it does

VeloxDB is a local-first desktop database studio. You connect. You ask. You see. You ship.

Query anything that matters. Run SQL (and engine-native commands) against more than 10 databases and dialects — PostgreSQL, MySQL, MariaDB, SQLite, DuckDB, MongoDB, Redis, and Postgres-compatible platforms like Neon, Supabase, CockroachDB, Timescale, and more. One workspace. Multiple connections. Tabs that remember where they belong.
AI that actually understands your system. Veloxy does not guess table names from a blog post. It searches your catalog, describes tables, follows foreign keys, and writes SQL against the schema you have — not the schema it invented.
BI dashboards without leaving the client. Turn a result set into charts, KPIs, and a grid you can rearrange. Generate a dashboard from the schema when you do not want to start from a blank canvas.
A visual model you can mutate. Introspect the ER diagram, drag tables onto a canvas, draw relationships, edit columns in place, then preview the migration DDL before it ever touches production.
Built for machines that are not infinite. Virtualized result grids, bounded reads, Rust-side pooling. Million-row curiosity should not require closing Chrome.

No cloud in the middle of your connection. Credentials stay in the OS keychain. Data travels from the app to your database — the way a desktop tool should work.

How we built it

Two languages. One job: keep the heavy work off JavaScript.

Layer	Choice
Desktop shell	Tauri 2 — small binary, native feel, OS keychain
Backend	Rust — tokio, connection pools, SSH tunnels, per-engine adapters
Frontend	React + TypeScript — Monaco editor, React Flow, TanStack Query
AI	Schema-aware agent (Veloxy) with catalog tools, not a chatbot taped to a text box
BI	Dashboard grid, chart widgets, AI composer that proposes layout from your tables

The architecture is stubborn on purpose:

React UI  →  Tauri IPC  →  Rust engines  →  your database

Each engine (Postgres, MySQL, SQLite, DuckDB, Mongo, Redis, …) implements the same operations: connect, ping, query, introspect. The UI stays one product. The Rust side stays the athlete. Virtual scrolling and row caps keep payloads honest, because a “show me everything” query should not become a memory incident.

We built it the way we wanted to use it: keyboard-first, command palette, dark by default, workspace that survives a restart.

Challenges we ran into

The first challenge was emotional. Replacing a tool the whole industry treats as “good enough” means you cannot be 10% nicer. You have to be obviously faster.

Then the technical ones arrived in a queue:

RAM is a feature, not a setting. pgAdmin taught us what happens when a result grid is just a giant DOM. We had to treat large results as a systems problem: cap rows on the Rust side, virtualize on the React side, never ship an unbounded IPC payload. If it feels slow, we failed.

“One client” is a lie until the tenth engine. Postgres identifiers are not MySQL identifiers. Mongo is not SQL. Redis is not a table. DuckDB wants files. Every new engine tried to leak into the UI. We fought that with a dispatcher, engine-specific quoting, and the discipline to say “this feature is SQL-shaped” instead of pretending every database is Postgres in a costume.

AI that hallucinates users.email is worse than no AI. The model had to search the catalog first. Tools, ranking, and “describe this table before you write JOIN” became the product, not a demo prompt.

Migrations without fear. A visual model is cute until it emits DROP COLUMN. Previewing DDL, undo/redo on the canvas, and applying only what the user reviewed took more humility than drawing boxes.

Shipping from Ethiopia. Time zones, payment rails, notarizing macOS, explaining a native app to people who assume every database tool is a SaaS. The internet is global. The friction is not. We shipped anyway.

Accomplishments that we're proud of

We did not just “build a client.” We changed the conversation around what a database tool is allowed to be.

It went viral. Over 200,000 views. Developers who had never heard of us opened the demo, felt the speed, and sent it to someone else.
GitHub answered. 500+ stars — not because we bought a launch, because people who live in SQL recognized the pain.
Query + model + BI + AI in one native app, with Rust doing the work that used to melt laptops.
A migration path that exists. You can see the schema, change it on a canvas, and review the SQL before it runs — the feature I was missing when this started.
Proof that world-class developer tools can come from Ethiopia. Not as a footnote. As the origin.

The moment I am proudest of is not the view count. It is a stranger running a query that used to freeze their machine, and watching it return like it was obvious.

What we learned

Speed is respect. If a tool makes you wait, it is telling you your time is cheap.

We learned that local-first is a product decision, not a slogan. People will not paste production credentials into a random cloud proxy if you give them a real alternative.

We learned that AI is only impressive when it is grounded. Schema tools beat vibes. A model that can search_schema and describe_table is a teammate. A model that invents columns is a liability.

We learned that the dashboard I kept rebuilding at work was a symptom. Analysts and engineers do not want another BI login. They want the chart to appear where the SQL already lives.

We learned that shipping in public compounds. 200K views and 500 stars are not the destination. They are a signal that the wound is shared — from Addis to everywhere else a developer still opens pgAdmin and sighs.

And we learned that constraints sharpen taste. Building on a machine that cannot hide slowness made us allergic to it.

What's next for VeloxDB

The momentum is real. We are not treating it as a trophy. We are treating it as a mandate.

Deeper engines. More databases, better dialect intelligence, and the same fast path for every connection you actually have at work — not only the ones that demo well.

Veloxy as a copilot for the whole studio. Not just “write this SELECT.” Propose the dashboard. Explain the query plan. Draft the migration. Catch the destructive statement before it runs.

BI that teams can live in. Saved dashboards, tighter chart builders, and analytics that stay next to the data instead of in a fifth SaaS.

Collaboration without giving up local-first. Share a query, a model, a dashboard — without making your database a tenant of someone else’s cloud.

A sharper desktop. Performance budgets we can measure. Installers that feel boring in the best way. A tool you forget is an app because it feels like part of the OS.

VeloxDB started as frustration in front of pgAdmin. It became a studio because one developer in Ethiopia refused to keep building the same dashboard in a different window.

The next chapter is simple: keep making the database feel fast, visual, and a little bit like it finally understands you.

Built with Rust and React. From Ethiopia. For anyone who still believes a query should not cost a gigabyte of RAM.