OneTUI: Why you many TUIs when you can use one?

tl;dr Code is at github.com/syndbg/onetui. If the idea of one consistent TUI across your databases and queues sounds useful to you too, I'd like to hear about it.

Note: Cross-published also at my blog https://syndbg.github.io/posts/2026-09-20-onetui-one-terminal-every-data-source/.

Over the years I've used DBeaver, DataGrip, psql, and whatever Kafka CLI happened to be the flavor of the month. Each one does its job, more or less. None of them feel like the same tool. Keybinds differ. Panels differ. Some support the data source I need that day, some don't. Some barely work.

What's missing across all of them isn't features or polish. It's one interaction model I can get used to and use consistently, whether I'm looking at Postgres rows or a Kafka topic. And why not a few more data sources too? Standing on prior tools

OneTUI isn't a from-scratch idea and I don't want to pretend it is. It borrows on purpose: K9s's resource and navigation model and adds a thin TUI layer over the raw protocol. DBeaver and DataGrip's breadth of data source support (minus the inconsistency), the Kafka/Redpanda support and expectations for various schema sources and decoding - Buf, Proto, Avro, Schema Registry. The point isn't novelty. It's picking the parts that already proved themselves and dropping the parts that didn't, inside one consistent shell.

Most useful tools work this way. Few are invented whole. K9s, and why it's the reference point

I admire K9s for lasting this long as a consistent tool. It has rough edges (looking at you slow timeouts when starting a new session), one set of keybinds, one mental model for every Kubernetes resource. People don't just tolerate K9s, they reach for it first. That's where I wish to get. The idea: OneTUI

My goal is not to sound like the XKCD comic about standards and develop one more tool to solve all problems before the next one comes and tries to do the same. :D

With the bold claim "OneTUI is one terminal UI for every database, message queue, or data source you connect to. The goal is consistent resources, consistent keybinds, and a consistent interaction model, no matter which data source is on the other end."

Today that's Postgres, Kafka, NATS, and Qdrant, each with a working provider: • Postgres: browse tables, inspect a row field by field, run a native query above the results. • Kafka: browse topics, follow live records, decode Protobuf and Avro payloads against a schema registry automatically. • NATS: browse subjects and follow live messages, same resource model as Kafka. • Qdrant: browse collections and points, and inspect cluster consensus state through the same resource browser used for a Postgres table.

None of these get a separate UI, all are integrated in the same consistent TUI. They all sit behind the same keybinds, the same panel layout, the same way of drilling from a resource list into a single item. That's the entire goal: the tool underneath can be anything, as long as what you see and press stays th…