# WhoDB: a self-hosted database workspace with a schema graph and an MCP server > WhoDB is an Apache-2.0 Go and TypeScript tool that puts browsing, editing, query scratchpads, a schema graph and optional text-to-SQL in one self-hosted web UI, with a desktop build and a CLI that can serve MCP. It suits small teams that want one shared place to look at several databases, and not anyone who needs a scheduler or a governed data catalogue. **clidey/whodb** — Where data access meets operational intelligence - Repository: https://github.com/clidey/whodb - Website: https://whodb.com - Stars: 5,033 · Forks: 241 - Language: Go - License: Apache-2.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/clidey-whodb ## The problem WhoDB solves, and who actually has it Most engineers end up with a drawer of database clients. One for Postgres, a different one for MongoDB, a Redis GUI, and a terminal session for whatever is left. WhoDB's pitch is that a single self-hosted workspace covers all of them: the README describes one place to "explore your databases, edit data, run queries, and understand how a schema fits together", available in the browser, as a desktop app, or as a terminal CLI. The audience is narrower than the feature list suggests. The README names three situations: inspecting a local database, helping a teammate explore unfamiliar data, and working without installing a heavyweight database client. Those are all cases where the person looking at the data is not the person who owns the schema. A backend engineer who lives in psql will not gain much from a spreadsheet grid. A product manager, a support engineer or a new hire who needs to answer "what does this column mean" without a read-only replica and a SQL tutorial will. The secondary audience is AI tooling. The repository topics include mcp-server and text-to-sql, and the CLI ships an MCP server, so the intended use is letting an agent or an editor query your databases through a defined interface rather than through ad hoc credentials. That is a different buyer from the person who wants a nicer table browser, and it is worth deciding which of the two you are before you install anything. ## How WhoDB is put together: Go core, TypeScript frontend, pluggable AI The repository layout tells you most of the architecture. There is a core/ directory in Go, a frontend/ in TypeScript, a cli/ with its own README and an install script, desktop-ce/ and desktop-common/ for the packaged apps, an sdk/, and a go.work file tying the Go modules together. The release workflow is named release-ce.yml, which is consistent with the community edition being the published artifact. The data path is conventional for this class of tool. The Go core holds the connectors and connects to your database; the browser talks to the core, which serves the UI and executes queries. The README's deployment advice reinforces this: sessions are stored under /data, and the encryption key lives in the WHODB_ENCRYPTION_KEY environment variable rather than in the database. That means the server process is the trust boundary. Anyone who can reach port 8080 and authenticate reaches every connection profile configured in that instance. The database support list is broad but explicitly uneven. Community supports PostgreSQL, CockroachDB, YugabyteDB and QuestDB; MySQL, MariaDB and TiDB; SQLite and DuckDB; MongoDB and FerretDB; Redis, Valkey and Dragonfly; Elasticsearch and OpenSearch; ClickHouse and Memcached. The README is direct about the consequence: "Support varies by database because not every system has the same concepts or capabilities. The connection screen shows the options available for each source." Read that as a design decision, not a disclaimer. A schema graph makes sense for Postgres and much less sense for Memcached, and the UI adapts rather than pretending otherwise. AI is deliberately optional and provider-agnostic. Ollama, OpenAI, Anthropic, LM Studio and any OpenAI-compatible endpoint are listed. Hosted providers can be added from the Chat panel without a restart, and the README states that WhoDB fetches the model list after you enter a key. Nothing about the core browsing workflow depends on a model being configured, which is the right default for a tool you might hand to a teammate. ## Installing WhoDB with Docker and running a first query The fastest route is the one-line Docker command from the README. It starts the server and publishes port 8080, and the container is removed when you stop it, so nothing persists. ```bash docker run --rm -it -p 8080:8080 clidey/whodb ``` Open http://localhost:8080 and enter your database connection details on the connection screen. That screen is where you will see which options your particular database exposes, so it is worth reading before you assume a feature is missing. For anything beyond a trial, generate a key and mount /data. The README gives this exact sequence: first produce a key with openssl rand -hex 32, then pass it as WHODB_ENCRYPTION_KEY and mount a volume at /data. ```bash openssl rand -hex 32 ``` ```bash docker run -it -p 8080:8080 \ -v whodb-data:/data \ -e WHODB_ENCRYPTION_KEY=your_saved_64_character_hex_key \ clidey/whodb ``` Store that key somewhere you will still have it next quarter. The README is explicit that changing it invalidates existing sessions, which in practice means everyone reconnects. If you terminate TLS at a reverse proxy in front of WhoDB, also set WHODB_SECURE=true so the browser only sends the session cookie over HTTPS. If you would rather not run a server, the desktop builds are on the macOS App Store, the Microsoft Store for Windows, and Snapcraft. The CLI installs separately and gives you both a terminal UI and the MCP server. ```bash curl -fsSL https://raw.githubusercontent.com/clidey/whodb/main/cli/install/install.sh | bash ``` ```bash whodb ``` Running whodb with no arguments opens the terminal UI. Running whodb mcp serve starts the MCP server instead. The CLI README is the place to look for connection examples and the full command reference; the main README does not reproduce them. ## Where WhoDB stops: no scheduler, no lineage, thin rollback story The gap between the repository topics and the README is the most useful thing to notice. The topic list includes data-lineage, data-pipeline, data-governance and data-catalog. The README's feature list describes browsing and editing data, a schema graph, a query scratchpad, imports, exports and mock-data generation. Those are not the same product. A schema graph shows how tables relate right now; lineage shows how a value travelled from a source system to a report. WhoDB does the first and, based on the README, not the second. So the wrong-tool cases are concrete. If you need scheduled jobs that move data on a cron, there is nothing in the README about scheduling. If you need column-level lineage for a compliance review, a relationship graph will not satisfy the reviewer. If you need a catalogue with owners, tags and a search index across hundreds of tables, this is a browser with a graph view, not that. The operational gaps matter too. The README documents how to keep sessions across container replacement and how to set WHODB_SECURE behind a proxy. It does not document rollback, and it does not describe a migration step between versions. Given that 0.125.0, 0.126.0 and 0.127.0 were all released within August 2026, minor versions arrive often enough that you should treat the /data volume as state you back up before upgrading, not as something the project will migrate for you. Whether an older binary can read a newer /data directory is not stated anywhere in the README or the release notes. The security model deserves the same scrutiny. Connection credentials are encrypted with a key you supply, and the README warns that rotating it invalidates sessions. That is a reasonable design, but it means the key is the single point of failure for every stored connection. Losing it is not a password reset; it is a reconfiguration of every profile. ## WhoDB against Adminer, CloudBeaver and DbGate The obvious comparison is Adminer, which people search for alongside this project. Adminer is a single PHP file you drop next to a web server. It is smaller, it has no build step, and it covers MySQL, PostgreSQL, SQLite and others through a classic server-side form interface. WhoDB is a Go core plus a TypeScript frontend, which is more moving parts to deploy but buys a persistent schema graph, a multi-cell scratchpad and an MCP server. If your requirement is "one file, any shared host, edit a row", Adminer is the smaller answer. If your requirement is "a workspace a non-DBA can use without training", the graph and the grid are the argument for WhoDB. CloudBeaver is the other end of the spectrum. It is a full web IDE with a driver manager, and installation is a multi-step server setup rather than a single docker run. The difference in approach is breadth of drivers versus breadth of interaction. CloudBeaver wins when you need a database WhoDB does not list. WhoDB wins when you want to be running in one command and would rather have a schema graph than a driver catalogue. DbGate sits closer to WhoDB in spirit: a web and desktop client with a modern UI. The practical distinction to check is which databases each one treats as first class, because WhoDB's own README concedes that capability varies per source. Azimutt is a different category again, aimed at schema design and documentation rather than day-to-day row editing, so it is an alternative to the graph view specifically, not to the workspace. The honest summary: WhoDB is not competing on driver count. It is competing on how quickly one person can go from a connection string to understanding a schema, and on being embeddable in an AI workflow through MCP. If neither of those is your bottleneck, the alternatives are cheaper. ## Licence, upgrade cost and what a weekly release cadence means for you WhoDB is Apache-2.0, and the repository carries both a LICENSE and a NOTICE file, which is the normal Apache-2.0 arrangement. For internal use that is undemanding. If you redistribute WhoDB inside a product, Apache-2.0 section 4 requires you to ship the licence text and to preserve the NOTICE contents, and section 5 makes clear that the licence grants no trademark rights, so you cannot imply the project endorses your fork. That is a description of the licence text, not legal advice; get your own counsel if you are redistributing. The repository also contains an ee entry alongside core/ and desktop-ce/, and the release workflow is named for the community edition. The README does not describe what the enterprise edition contains or how it is licensed, so treat the split as something to confirm before you build a dependency on any particular feature. Upgrade cost is the practical concern. Three releases in August 2026 alone suggests the project moves quickly, and the README does not document a downgrade path or a data migration step. The safe procedure implied by the documentation is to snapshot the /data volume before pulling a new image, keep the WHODB_ENCRYPTION_KEY unchanged so existing sessions survive, and test the new container against a copy of your connection profiles before pointing your team at it. If you pin images by digest rather than by latest, you control when that happens instead of discovering it. ## Conclusion Adopt WhoDB if you want one self-hosted browser workspace over several databases, a schema graph you can share with teammates, and an MCP server for AI tools, and if you can keep the WHODB_ENCRYPTION_KEY stable across container replacements. Do not adopt it if you need a scheduler, a lineage graph or a governed catalogue; the repository topics name those areas, but the README describes browsing, editing, queries, imports and exports instead. Before rolling it out, verify two things: which capabilities your specific database actually exposes on the connection screen, since the README says support varies by database, and whether a cadence of roughly weekly minor versions fits your upgrade process, given that 0.125.0, 0.126.0 and 0.127.0 all shipped in August 2026. ## FAQ ### How do I install WhoDB? The README's quick start is a single Docker command that publishes port 8080: docker run --rm -it -p 8080:8080 clidey/whodb, after which you open http://localhost:8080 and enter your connection details. Desktop builds are on the macOS App Store, the Microsoft Store and Snapcraft, and the CLI installs with a curl script or npm install -g @clidey/whodb. ### Which databases does WhoDB support? Community supports PostgreSQL, CockroachDB, YugabyteDB, QuestDB, MySQL, MariaDB, TiDB, SQLite, DuckDB, MongoDB, FerretDB, Redis, Valkey, Dragonfly, Elasticsearch, OpenSearch, ClickHouse and Memcached. The README states that support varies by database because not every system has the same concepts, and that the connection screen shows the options available for each source. ### Does WhoDB need an AI provider to work? No. The README describes AI features as optional, and you only connect Ollama, OpenAI, Anthropic, LM Studio or another OpenAI-compatible provider if you want to ask questions in plain English. Hosted providers can be added from the Chat panel without backend configuration or a restart. ### Can I use WhoDB from the terminal without the web UI? Yes. The CLI includes an interactive terminal UI and an MCP server. Running whodb opens the terminal UI, and running whodb mcp serve starts the MCP server for AI tools. The CLI README holds the connection examples and the full command reference. ### What happens if I change the WHODB_ENCRYPTION_KEY? The README states that changing the key invalidates existing sessions, so users will have to reconnect. The key is generated with openssl rand -hex 32 and is passed to the container as WHODB_ENCRYPTION_KEY, with the /data volume holding the session state. ## Sources - [clidey/whodb on GitHub](https://github.com/clidey/whodb) - [License: Apache-2.0](https://github.com/clidey/whodb/blob/main/LICENSE) - [Project website](https://whodb.com) - [README](https://github.com/clidey/whodb/blob/main/README.md) - [Releases](https://github.com/clidey/whodb/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/clidey-whodb