I spent an evening going through a big directory of database GUIs — the Macs-and-menu-bars kind, forty-something of them. DBeaver, TablePlus, Beekeeper, Postico, DataGrip, a wall of Redis and Mongo clients, a couple of new AI-first ones. Good tools. Genuinely nice to use.
And somewhere around tool number thirty it clicked that almost every single one is the same shape: a connection sidebar, a SQL editor, and a data grid you can sort and filter and edit cells in. That's the archetype. It's a text editor for your database, with a spreadsheet stapled to the results.
Which is great — right up until the question you have isn't "let me write a query."
The questions an editor is bad at
Here's the thing I keep hitting, and I don't think I'm alone. The moments I actually open a database tool in anger are almost never "I want to author a SELECT." They're operational:
- Something is hung. Who is blocking whom?
- The app is throwing connection errors. Am I out of connections, and how close was I?
- A table feels bloated. Is autovacuum keeping up, or has it not run in three weeks?
- This index — is anything even using it, or am I paying to maintain dead weight?
Every one of those has a real answer sitting in a system view. pg_locks joined to pg_stat_activity. count(*) from pg_stat_activity against max_connections. n_dead_tup and last_autovacuum in pg_stat_user_tables. idx_scan = 0 in pg_stat_user_indexes.
And here's how a query-editor tool answers them: it hands you the editor. So you paste in the pg_stat_activity join you half-remember, get a column name wrong, look it up, run it, squint at the raw rows, and mentally reconstruct the blocking graph yourself. The tool didn't answer the question. It gave you a place to type the question, again, for the hundredth time.
That's the hole. The category optimized hard for authoring SQL and left reading the state of the database as an exercise for the user.
Editor questions vs. console questions
It's worth being precise about the split, because it's not "some tools are better." It's two different jobs:
| Editor question | Console question |
|---|---|
| What rows match this filter? | Who is blocking whom right now? |
| Let me edit this cell. | How many connections until I hit the ceiling? |
| Design this schema. | Has autovacuum touched this table lately? |
| Format and save this query. | Which indexes are dead weight? |
A SQL editor is the right tool for the left column. It is a genuinely bad fit for the right column — not because it can't run the query, but because "run the query and read raw rows" is the entire user experience it offers, and the right-column questions want a computed answer, not a result set.
The tell is that the operational answer is almost always a join across two or three catalog views plus a derived number — the blocking graph, the headroom percentage, the dead-tuple ratio. That's not something you want to retype. That's something you want a tool to have already turned into a line that says "session 4823 is blocking two others" or "you're at 71% of max_connections."
The one instinct that is spreading
There was one exception in the pile worth calling out, and it's a hopeful one. A couple of the newer clients lead with read-only by default — you connect, and the tool won't let you mutate anything unless you opt in. One AI-first Postgres client puts that right in its headline.
I found that genuinely encouraging, because it's the same instinct from a different direction: the tool taking responsibility for the state of the database instead of treating it as a dumb text target. Read-only-by-default says "I assume you're here to look, not to break things." That's a console instinct leaking into the editor category, and I'll take it.
(It's also the exact reason my own runner defaults to SET TRANSACTION READ ONLY at the server, not by parsing your SQL — but that's a whole other post.)
So build the console
None of this is a knock on the editors. If your job is writing and iterating on SQL all day, a great editor is the correct tool and you should use the nicest one you can find.
But there's a second job — reading the live state of a database and catching the thing about to fall over — and the market answers it, overwhelmingly, by handing you an editor and wishing you luck. The interesting product isn't a prettier editor. It's the tool that has already run the pg_stat join for you and put the answer on the screen: the blocking graph drawn as a graph, the connection headroom as a number with a ceiling, the unused indexes listed honestly, autovacuum's last pass with a timestamp you can actually read.
That's the shape of an operations console, and it's a strangely empty shelf. Which, after forty tools, is the part I keep thinking about.
This is one piece of cli2ui — a local-only web UI over the
psqlcommands you keep half-remembering, built to answer the console questions above without making you retype thepg_statjoin. No AI, no SaaS. MIT-licensed on GitHub. What's the operational question you keep pasting into a query editor?
Top comments (0)