We maintain two database MCP servers, DBHub and the one built into Bytebase. People keep asking which to use, so: DBHub when you're the only one affected, Bytebase MCP when other people are.
Note that's not the same as dev vs prod. A read-only replica only you touch is fine on DBHub; a staging database loaded with a copy of real customer data isn't. What matters is who pays if the agent does the worst thing it can do.
The rest is one difference, and everything follows from it.
Shared account vs your account
DBHub takes a connection string. In practice that's a shared service account, usually the one your app already uses, and every agent pointed at it connects as that same account.
Bytebase MCP takes an OAuth login. The agent connects as you.
So when your agent runs a DELETE at 2am, DBHub's database logs app_user, same as every other query from everyone else sharing it. You know it happened, not who it happened for, and you can't revoke it for one person without revoking it for everybody. Bytebase logs it under your account.
DBHub
One command, no server:
npx @bytebase/dbhub@latest --transport stdio --dsn "postgres://user:pass@localhost:5432/mydb"
Two tools by default, run SQL and search the schema, which keeps your context window free for the actual problem. Postgres, MySQL, MariaDB, SQL Server and SQLite, several connections in one process. You can start it read-only, cap the rows, set a query timeout.
No identity, though. Read-only is a flag on the process, so it protects you from the agent, not from whoever started the process.
Bytebase MCP
Nothing to install. If you run Bytebase it's at /mcp, and your agent inherits your account, which already has rules on it: masked columns come back ******, schema changes open a review instead of running, and every call is logged under your name.
Worth saying plainly: it inherits all your permissions. Connecting as yourself only helps if yourself isn't an admin.
| DBHub | Bytebase MCP | |
|---|---|---|
| Connects as | A shared account | You |
| Reads | As stored | Masked per policy |
| Writes | Run immediately | Open a review |
| Audit | Database login records | Every call, under your account |
| Needs | Nothing | A running Bytebase |
The catches
DBHub has no per-person access to grant or revoke, no masking, and nothing between the agent and the table if writes are on.
Bytebase MCP needs Bytebase running with an external URL, and it's HTTP only. You can't dry-run SQL, since the checks happen when the change is created. Results cap at 100 rows by default, 1,000 max, 30 second timeout.
Picking
Local Postgres, a scratch copy, a replica, read-only poking at prod: DBHub. Real customer data, masked columns, writes someone should look at first: Bytebase MCP.
Both, honestly, is the normal answer. DBHub in your client config for local work, Bytebase MCP for anything shared. What to avoid is the middle, where a connection string that happens to reach production ends up in an MCP config because it was the fastest thing to paste.
Top comments (0)