Thoughts on Database Tooling and UX
On one side, there are powerful, commercial tools that try to be everything at once. They support every engine, every workflow, every edge case. The result is often a heavy application with long startup times, dense UIs, and a constant feeling that you’re navigating a system rather than inspecting data.
On the other side, there are lightweight or open-source tools that are fast and simple—but quickly hit a wall as soon as you need anything beyond basic querying.
What’s missing is not raw functionality, but UX discipline.
Many database managers feel like they’ve grown without ever being pruned. Features accumulate, interactions become implicit, and simple actions require unnecessary context switching. Over time, you end up paying a UX tax: more clicks, more waiting, more mental overhead.
For developers who frequently jump between databases or just want to explore data quickly, this friction adds up fast. It’s often easier to drop back to the terminal, even when a graphical tool should be the better option.
I started experimenting with a small database manager mainly to address this gap: fast startup, explicit actions, minimal abstraction, and a UI that stays out of the way.
That experiment eventually became debba.sql, an open-source database manager written in Rust and built with Tauri. It’s intentionally limited in scope and still very much a side project.
The more interesting question, though, is broader than any single tool:
Why are we still accepting poor UX as the default for database tooling?
If you’re curious, feedback is welcome—but even more welcome is the discussion around what “good UX” for developer tools should actually look like.
Link repo: https://github.com/debba/debba.sql
Ideas, stars and contributions are welcome.