Top 3 Open Source Multi-Database MCP Servers in 2026

This is a two-part series on database MCP servers:

1. Open Source Postgres MCP Servers, the single-engine post
2. Open Source Multi-Database MCP Servers (this one), the multi-engine companion

At Bytebase I work on database access control all day, so what an AI agent can do once it reaches a database is not academic for me. The companion post covered single-engine Postgres servers. This one is for where most shops actually are: more than one engine, and not all of them Postgres.

With MySQL next to Postgres next to a warehouse, you pick a server along two axes: how many engines it speaks, and how much it governs. Almost nothing scores on both. The universal servers speak everything and govern nothing. A control-plane toolkit curates what the agent may run but stops at the data. One spans engines and governs the data, and charges you a platform to stand up. Here is where the three land.

DBHub#

DBHub is the universal one: a single zero-dependency server speaking five engines. Point it at Postgres, MySQL, MariaDB, SQL Server, or SQLite with a connection string, and the agent works through the same two tools whatever is behind it. It connects straight to the database, not through the governed platform further down this list.

It stays deliberately thin. One binary via npx or Docker, plus a browser Workbench to see the exact SQL that ran. A single DSN gets you going; for more, one dbhub.toml holds every connection under [[sources]], each with its own timeouts and per-tool readonly and max_rows, hot-reloaded on save.

DBHub exposes five engines through one server and two tools, connecting straight to each database

Key Features:

• Five engines behind the same two tools (execute_sql and search_objects), about 1.4k tokens total, so the surface stays small however many databases you wire up.
• Read-only by default, plus row limits and connection and query timeouts to cap a runaway query.
• Real connectivity: SSH tunneling (including ProxyJump), SSL/TLS, and DNS-rebinding protection on HTTP.

Be clear on the limit: it connects with a connection string and stops there. No per-agent identity, no masking, no audit. The README says it plainly, "DBHub does not authenticate HTTP clients." A local tool honest about being one.

Best For: developers juggling several engines on a laptop who want one server, not five.

Verdict: the least friction of the three and the least governance, by design. Great on a laptop, and it does not pretend otherwise. Still under near-daily development.

Google MCP Toolbox for Databases#

MCP Toolbox for Databases (renamed from GenAI Toolbox) is Google's answer, and a different shape entirely. Not a SQL passthrough, a control plane. You define the allowed operations in a tools.yaml manifest, and the agent calls those curated tools by name instead of writing freehand SQL.

That is the whole point. A raw server lets the agent compose any statement; here you write and parameterize the queries, and the agent only fills in the blanks.

The agent calls MCP Toolbox, which curates the queries and connects to many databases: PostgreSQL, MySQL, BigQuery, Spanner, MongoDB, and more

Key Features:

• tools.yaml is the contract: sources define connections, tools are parameterized operations bound to a source, toolsets group what you expose to an agent. Change one centrally and every agent picks it up, no redeploy.
• Curation also controls context. A prebuilt engine toolset can run 28 tools and 19.0k tokens; expose just the one execute-SQL tool and it drops to 579, a 30x cut.
• Identity done right. Authorized invocations gate a tool behind an auth service, and authenticated parameters inject values from a verified OIDC claim server-side, so the model cannot forge who it acts as. Connection pooling and OpenTelemetry included.
• Database-agnostic despite the Google pedigree: AlloyDB, Cloud SQL, BigQuery, and Spanner, but also self-managed Postgres, MySQL, Oracle, MongoDB, and Snowflake, 40-plus sources in all.

Best For: teams whose agents should call a fixed, reviewed set of queries, not improvise SQL against production.

Verdict: curation is a genuine boundary here, the agent runs your queries, not its own, and authenticated parameters solve identity properly (though auth is Google Sign-In only today, Keycloak and Entra pending). The catch: it governs the tool surface, not the data. No masking, writes execute on invocation with no review, and guardrails are uneven across engines, a prebuilt execute-SQL tool may carry no read-only mode, row limit, or timeout, handing back the arbitrary-SQL door you just closed. GA since v1.0.

Bytebase MCP#

The Bytebase MCP server is the governed one, the opposite of DBHub. The agent does not connect to the database; it connects to Bytebase, and Bytebase connects to the database. That one move applies everything your humans already pass through, identity, masking, review, audit, to the agent too, across every engine Bytebase supports.

Bytebase is one control plane between consumers (human, AI agent, application) and databases, fronted by a GUI, an MCP server, and an API

Key Features:

• The broadest engine list here, not close: MySQL, Postgres, Oracle, SQL Server, TiDB, CockroachDB, Spanner, Snowflake, BigQuery, Redshift, MongoDB, and two dozen more.
• The agent badges in under its own identity (OAuth or a service account) and inherits exactly that identity's permissions, scoped by project, database, and role. Nothing the prompt says widens it.
• The same machinery humans pass through, at the MCP boundary: sensitive columns come back masked as ******, a write opens a change issue for SQL review and approval instead of executing on send, and every action is audit-logged under the account it acted as.

Best For: teams pointing an agent at production data across several engines, where masking, review, and audit are required, not optional.

Verdict: the only server here that governs the data, not just the connection or the tool surface. That is the reason to run it. HTTP-only with OAuth, self-hosted or on Bytebase Cloud. And the MCP server is one face of it, not the whole: the same governed path backs a GUI for people and a REST API for automation, so agents, humans, and scripts reach the database through one control plane.

Database MCP Server Comparison Table#

Star counts are from the time of writing and not apples to apples, DBHub is a dedicated MCP-server repo, mcp-toolbox a broad monorepo, and Bytebase's count the whole platform. A rough adoption signal, not a ranking.

Summary#

Back to the two axes, pick by where you sit:

• DBHub speaks five engines with the least ceremony and governs none of it. Right for poking at databases locally.
• MCP Toolbox governs the tool surface better than anything here but stops at the data. Right for giving an agent a fixed menu of reviewed queries.
• Bytebase governs the data across engines and makes you stand up a platform to get there. Right when an agent is about to touch production data you would hate to lose.

Part one covered why a raw connection string is fine locally and risky in production: prompt injection (the lethal trifecta) turns even a scoped credential against you. Across many engines that exposure only compounds, one more connection string and shared principal per database. So of the two axes, governance is the one that separates these three. Breadth is table stakes; what a server does when the prompt asks for something it shouldn't is not.

That last question is the whole point of a governed path like the Bytebase MCP server, which puts identity, masking, and change review in front of every engine it reaches.

• Top Open Source Postgres MCP Servers: the single-engine companion, covering Postgres MCP Pro, Supabase MCP, and pgconsole.
• Governed MCP vs. Raw MCP: a deeper look at the production side of agent database access.
• How to Govern AI Agent Access to Enterprise Data: identity, masking, and audit for agents.