DBCatz is a free, open-source client for MySQL, PostgreSQL, SQLite, Redis, MongoDB and Elasticsearch with a Production mode that makes mistakes harmless.
Most of us have done it, or watched someone do it: a query meant for the local database, run in the tab that was connected to production. Same window, same colours, same confident Enter key.
DBCatz is built around one idea: the client should know which connection is production, and behave differently there. It is free and open source (GPL-3.0), for macOS, Windows and Linux.
Safety mode, per connection
Every connection has a safety mode:
Normal — what you would expect.
Production — a PROD chip on the tab, a confirmation before every write, and a destructive statement (a DELETE without a WHERE, a DROP, a TRUNCATE) needs the connection's name typed out before it runs.
Read-only — writes are refused, and the server session itself is set read-only, so nothing slips through.
Structure changes are checked before they run, too: a new primary key, foreign keys, values that would not fit a new type, duplicates before adding UNIQUE, and long table rebuilds are all named first. The client assumes you will make a mistake one day, and makes that mistake harmless.
Eight engines, one window
MySQL, MariaDB, PostgreSQL, SQLite, Redis, Valkey, MongoDB and Elasticsearch — a tab per connection, with an editor that speaks each one's language: SQL with suggestions, Redis commands, mongosh, and a Kibana-style console for Elasticsearch.
A data grid with filters (write a WHERE clause), editable cells and foreign keys you can click to jump to the row they point at
Structure, indexes, export and import, backups
A query editor with history; copy a result as CSV or JSON
Every way in
Local servers, a Unix socket, an SSH tunnel (key, password or ssh-agent, built in), AWS IAM for RDS (tokens signed locally and renewed every 10 minutes) and HashiCorp Vault (dynamic credentials or KV v2 secrets). No side scripts, no copied passwords.
Or just paste a URL — postgres://…, mysql://…, redis://…, mongodb+srv://…, even a whole DATABASE_URL= line from a .env — and DBCatz fills the form.
Passwords, SSH passphrases, AWS keys and Vault tokens are kept by your system: the macOS Keychain, Windows' protected storage, or your Linux keyring. Never in a plain config file.
AI that never touches your rows
Ask in plain words — "orders from last week that were paid but not shipped" — and the query lands formatted in the editor. It never runs on its own; you read it and press Run. Only structure is sent to the AI provider (tables, columns, types, keys, indexes, estimated row counts), never your data unless you switch on samples for a connection. Read-only connections only ever get SELECTs back. It is all off until you add your own key.
Better with DevCatz
If you use DevCatz for local development, every database it runs shows up in DBCatz by itself — no host, port or password to type. And from DialCatz, Check in DBCatz opens the table a request just touched.
The whole family working together, in two and a half minutes:
Try it
Download: catzoid.com/dbcatz/download — macOS (signed and notarized), Windows, Linux x64 and ARM64.
Homebrew:
brew tap catzoidhub/catz && brew trust catzoidhub/catz && brew install --cask dbcatz
Docs: catzoid.com/docs/dbcatz
Source: github.com/catzoidhub/DBCatz
Made in Indonesia by a small team, written with Claude. Tell me which engine or connection method you are missing — the issues on GitHub decide what comes next.
Top comments (0)