[ overdb ] · a database client for environments
The same schema lives in local, staging and prod, and the interesting questions are comparisons across them. overdb makes that comparison the main gesture — and lets you branch your data like code.
[ the basics ] · everything you'd expect
Environments and branches are the reason to switch — but the everyday client comes first: an editor, a grid, your history, and answers in prose when you don't want to write the SQL.
[ one gesture ] · fan out, compare, act
Every member of an environment set answers on its own — a failure on one never aborts the rest — and each answer is compared with the baseline.
[ schema drift ]
Compare every member against its baseline, catalog to catalog, without running a statement. Findings are sorted into Breaks, Integrity, Behaviour, Performance and Cosmetic, plus what only one side has — a missing column and a differently-spelled varchar are not the same news.
[ branches ]
Copy a database to this machine as a small base, then branch it — a writable clone per experiment, made in seconds on macOS. Seed it with exactly the data you need, break it, reset it. Nothing you do in a branch touches the server.
[ the proxy ] · one connection, any branch
Point each service at the proxy once. From then on, which data it sees is a click in the title bar — your own server or any branch. The proxy forwards byte for byte, closes its connections on a switch, and every service's pool reconnects to the new one. After that first time, no .env edits and no restarts — a switch drops open connections, and each pool reconnects.
[ agents ] · read only, on your login
Register overdb once with Claude Code or any MCP client, and an agent can list your connections, read the schema and run the reads it needs — told what overdb already knows: the tenancy rule, your notes and the map of your code. Then ask in prose: “why is shop-prod slow right now?”
Nothing is exposed until you turn on a connection’s Agents chip, beside Writes — a prod connection asks you to type its name. A connection that isn’t on doesn’t exist, as far as an agent can tell.
Every session opens in the engine’s read-only mode whatever Writes says, and writes, DDL and batches are refused before they’re sent. 100 rows by default, 1,000 at most, a 30-second timeout.
Passwords, 1Password, IAM and SSH tunnels resolve inside overdb, as when you connect. The agent sees a connection’s name, never a secret.
The same read-only tools run without the app for hosted agents. Publish to your org’s server… hands a connection — no password — to overgo, where workers query it and every query is logged. See it on overgo →
[ plans ]
Rows are the water: the stream narrows where the server throws rows away and flares where a nested loop turns one row into thousands. Those two events are why a query is slow — and in a plan table they are invisible.
The stream is the rows. It necks down where the WHERE clause throws them away — those are the flecks falling out of it — and flares where a loop reads many rows for each one arriving. A ≈ marks a count the server estimated rather than measured. Thickness is on a square-root scale; the numbers on the labels are exact.
WORTH LOOKING AT[ safety ]
Writes are turned on per connection. On prod you type its name first, because the accident worth preventing is doing the right thing to the wrong server.
[ download ] · grab a build
Overdb is in beta, and from v0.1.1 it updates itself from GitHub Releases, so this is the last download you do by hand. The macOS builds are Developer-ID signed and notarized by Apple, with the same Developer ID as overcli and overgit, so they open on a double-click. Windows isn't code-signed yet, so SmartScreen may still flag it. The source is right there if you'd rather build it yourself.
Stable macOS builds open clean — signed with a Developer ID and notarized by Apple, so there's no Gatekeeper prompt. Windows isn't code-signed yet: SmartScreen may say “unrecognized app” → More info → Run anyway. Bases and branches need a local MySQL, MariaDB or Postgres server, which overdb can install with Homebrew, and database maps need the claude CLI.
[ faq ]
It's v0.3.0 and in beta: an early public build, so expect rough edges and tell us about them in the issues. Everything on this page is in it, and bases, branches and the background proxy are built for macOS first. Because every connection you add starts read-only, the safest way to try it is exactly how it starts.
Nothing. Like overcli and overgit, it's Apache 2.0, with no account, no server, and no paid tier. The AI features use a CLI you already have and are already logged in to.
Every connection you add starts read-only; the only ones overdb opens with writes on are the local branches it makes for you. Postgres uses BEGIN READ ONLY, MySQL uses START TRANSACTION READ ONLY, and SQLite opens with its readOnly flag. DynamoDB has no server-side read-only mode, so overdb fails closed on statements it cannot classify; use a read-only IAM policy as the durable boundary. Turning writes on for a prod connection means typing that connection's name. Seeds run only on a connection that is tagged local, has writes on and is really on this machine, and bases, copies and proxies are refused for production and untagged servers. None of those has an override.
Overdb does not intentionally add result rows or bound parameter values to prompts. Depending on the feature, a prompt can include your question, schema metadata, SQL text, server errors, and plan statistics, so literals or database errors may still contain sensitive values. A ticket you paste into Seed goes too. When you link a repo, the claude CLI reads your code for seeds, bases and database maps with Read, Grep and Glob only — no shell, no MCP servers, and .env and key files denied. The prompt goes to the claude, codex, or gemini CLI already on your machine, and proposed SQL goes into the editor without running. Agents are different, and opt-in: turn on Agents for a connection and an agent you connect can run read-only queries on it and sees what they return — 100 rows by default, 1,000 at most. The Agents sheet lists every call it made.
Ten: PostgreSQL, Amazon Redshift, Aurora PostgreSQL, CockroachDB, and TimescaleDB; MySQL, MariaDB, and Aurora MySQL; SQLite; and Amazon DynamoDB. They run on four drivers, and overdb detects which server it's connected to so it can handle the places they differ, like Redshift having no indexes or MariaDB's performance views. SQL Server, Oracle, and document stores like MongoDB aren't supported.
In the operating system's encrypted storage, in a separate file from the rest of the app's state. You can also use an environment variable, or a 1Password op:// reference that's resolved when you connect, so the secret is never saved in overdb at all.
[ family ] · over your tools, not instead of them
One window over your agent CLIs — then put them in a loop.
overgit →A better git client — and one ticket across many repos.
Every environment at once — and branches of your data.
overcli for your whole team — on your own server.