Are these actually two different servers?

They are the same Bytebase DBHub universal gateway pointed at two different engines. One uses a MySQL DSN, the other a Postgres DSN, so the tool surface and read-only safety features are shared.

Can DBHub connect to both at once?

DBHub connects per DSN, so a single instance targets one database. If you run both MySQL and Postgres, register two instances — one per connection string — and the agent can query each.

MySQL (DBHub) vs DBHub (Postgres)

Both of these MCP servers come from Bytebase's DBHub, a universal database gateway that connects an agent to a relational database through a DSN and lets it run SQL and explore schema. The difference is which engine sits behind the connection string. The MySQL entry points DBHub at a MySQL (or MariaDB-compatible) database; the Postgres entry points the same gateway at PostgreSQL. Because they share a codebase, the tool surface — list tables, describe schema, run queries, often with a read-only safety mode — looks nearly identical, so the real decision is almost entirely about which database your application already runs on and the SQL dialect, types, and operational features that come with it. Here is a balanced look at how the two ends of DBHub differ when you wire an agent into them.

How they compare

Dimension	MySQL (DBHub)	DBHub (Postgres)
Underlying engine	Targets a MySQL/MariaDB database — the most widely deployed open-source OLTP engine, common in LAMP-stack and PHP-era applications.	Targets PostgreSQL — known for strict standards compliance, rich types (JSONB, arrays, ranges), and extensibility via extensions like PostGIS and pgvector.
SQL dialect and types	MySQL dialect: simpler type system, lenient defaults historically, and ubiquitous tooling; great when your queries already speak MySQL.	Postgres dialect: window functions, CTEs, advanced JSON operators, and powerful indexing the agent can lean on for analytical-leaning queries.
Connection model	Same DBHub gateway, MySQL DSN. Runs locally over stdio; you supply credentials and the agent reaches your MySQL instance.	Same DBHub gateway, Postgres DSN. Runs locally over stdio; identical workflow, just a Postgres connection string.
Safety and scope	DBHub's read-only mode and DSN scoping apply regardless of engine, so you can constrain what the agent can touch on MySQL.	Identical safety posture on Postgres — read-only mode, DSN scoping, and schema introspection are the same gateway features.
Best-fit task	Letting an agent query and explore an existing MySQL/MariaDB application database without standing up a bespoke server.	Doing the same against a Postgres database, especially when you want richer SQL or already rely on Postgres extensions.

Verdict

Pick by the database your application already runs. Because both are the same Bytebase DBHub gateway, the tools, the read-only safety mode, and the explore-then-query workflow are effectively identical — what changes is the engine behind the DSN. Choose the MySQL endpoint when your data lives in MySQL or MariaDB and your queries already speak that dialect. Choose the Postgres endpoint when you are on PostgreSQL and want its richer type system, advanced SQL, and extension ecosystem. There is no need to migrate engines just to use MCP; point DBHub at whichever database you already have, and reach for both if you run a mixed fleet.

FAQ

Are these actually two different servers?: They are the same Bytebase DBHub universal gateway pointed at two different engines. One uses a MySQL DSN, the other a Postgres DSN, so the tool surface and read-only safety features are shared.
Can DBHub connect to both at once?: DBHub connects per DSN, so a single instance targets one database. If you run both MySQL and Postgres, register two instances — one per connection string — and the agent can query each.