"The world doesn't need another database GUI." That's what we told ourselves before we built one anyway. Here's why.
The Real Problem Wasn't Any One Tool
Our projects run MongoDB next to PostgreSQL next to SQL Server — with an Aerospike cluster here and a ClickHouse warehouse there. Each engine has capable clients. The problem is that they're different clients: different shortcuts, different result views, different ways of hiding the button you need. Half of them felt like they were designed in 2010, and none of them talked to each other.
Every context switch between tools costs a little focus. Multiply that by every day, and switching clients per database becomes the most expensive part of working with a mixed stack.
What We Actually Wanted
- One workspace for every engine. The real mongo shell, proper GO batches, session-pinned Postgres scripts, AQL, native ClickHouse SQL — not a lowest-common-denominator SQL box.
- Fast startup and response times. We're in flow state. Don't break it with loading screens.
- Keyboard-driven workflow. Mice are fine, but shortcuts are faster.
- Smart autocomplete. Suggest field and column names from our actual schema, not a generic keyword list.
- Respect for production. Preview scripts before they run, recover from bad deletes, abort queries server-side.
- Affordable. A genuinely good tool should be free for everyday work; the power features shouldn't need budget approval.
- Clean, modern interface. We stare at this thing all day. It should look good.
Building Sutido
We started Sutido as a side project to scratch our own itch. The first version was rough — a connection panel and a Monaco editor hooked up to the MongoDB driver. Then PostgreSQL moved in, then MSSQL with real GO batch handling, then Aerospike (whose native driver runs in its own process so a crash never takes the app down), then ClickHouse with server-side KILL QUERY on abort.
Along the way came the features we kept missing elsewhere: a results grid that behaves like a spreadsheet, delete recovery journaled before every destructive operation, SSH tunneling with trust-on-first-use host keys, and AI query generation for the days you know what you want but not the exact syntax.
Our Design Philosophy
Every feature in Sutido answers one question: "Does this help developers work faster?" If the answer is no, or if it adds complexity without proportional value, we don't build it.
Local-First, Privacy-Focused
Your data stays on your machine. We don't sync your connections to the cloud. We don't track your queries. Your credentials are stored encrypted with OS-level encryption, not in a config file or a remote database.
This isn't just a privacy stance—it's a performance decision. Local storage means instant access, no network latency, and no dependency on our servers being up.
What's Next
Sutido is ready for daily use, but we're just getting started. macOS and Linux versions are on the roadmap, and we're building features based on community feedback — several of the grid's clipboard formats exist because users asked for them.
If juggling database tools sounds familiar, give Sutido a try. We built it for developers like us—and hopefully, like you.