TiDB vs MySQL (DBHub)
TiDB MCP and the DBHub MySQL MCP server both connect an agent to a MySQL-compatible database, but they sit at opposite ends of the scale spectrum. TiDB is PingCAP's open-source, MySQL-compatible distributed SQL database with an HTAP architecture — a row-based TiKV engine for transactions and a columnar TiFlash engine for analytics, kept in sync in real time — plus native vector search. Its official MCP server ships as part of PyTiDB and gives an agent cluster-aware navigation: show_databases, switch_database, show_tables, query and execute SQL, and even user management (create and remove database users). DBHub is Bytebase's universal database gateway; pointed at a MySQL DSN it exposes a deliberately small surface — execute_sql with transaction support and safety controls, plus search_objects to walk schema, tables, columns, indexes, and procedures. The deciding question is whether you are working against a distributed TiDB cluster and want first-party, cluster-aware tooling, or against a standard single MySQL and want a lean, safe gateway that happens to speak many SQL dialects. Here is a balanced look.
How they compare
| Dimension | TiDB | MySQL (DBHub) |
|---|---|---|
| Database under the hood | TiDB — an open-source, MySQL-5.7-protocol-compatible distributed SQL database with HTAP (TiKV row store + TiFlash columnar) and native vector search. | Standard MySQL via one DSN (DBHub also fronts Postgres, MariaDB, SQL Server, SQLite) — single-instance MySQL semantics, no distributed layer. |
| Official status | PingCAP's official server, shipped as part of PyTiDB, PingCAP's AI SDK for TiDB. | Bytebase's DBHub — a universal, vendor-neutral gateway rather than a MySQL-first-party server. |
| Tool surface | Cluster navigation plus SQL: show_databases, switch_database, show_tables, db_query, db_execute, and user management (db_create_user, db_remove_user). | Two universal tools: execute_sql with safety controls and search_objects for progressive schema discovery — the same surface across every backend. |
| User and access management | Built in — the agent can create and remove TiDB database users directly through dedicated tools. | Not exposed as dedicated tools; any user management would run as raw statements through execute_sql, subject to the connection's privileges. |
| Best-fit task | Working against a scaled-out TiDB cluster — navigating databases and tables, running mixed transactional/analytical SQL, and managing users from the agent. | Querying and exploring a standard MySQL (or other SQL engine) with a minimal, safe gateway that is easy to point at any database via DSN. |
Verdict
Pick by where your data lives. Reach for the TiDB MCP server when you run TiDB and want PingCAP's first-party, cluster-aware tooling — database and table navigation, mixed transactional and analytical SQL on its HTAP engine, and built-in user management — all from the agent. Reach for DBHub when you have a standard MySQL and want a lean, safe, universal gateway: two tools to run SQL and explore schema, with the bonus that the same setup also covers Postgres, MariaDB, SQL Server, and SQLite by swapping the DSN. In short: TiDB MCP for a distributed, HTAP MySQL-compatible cluster with first-party tooling; DBHub for a minimal, portable gateway to ordinary MySQL.
FAQ
- Is TiDB really MySQL-compatible?
- Yes. TiDB speaks the MySQL 5.7 protocol, so existing MySQL clients, drivers, and ORMs generally work unchanged. The difference is the architecture underneath: TiDB is distributed with separate row (TiKV) and columnar (TiFlash) engines for HTAP, where DBHub talks to a conventional single MySQL instance.
- Which server can manage database users?
- The TiDB server exposes dedicated db_create_user and db_remove_user tools. DBHub has no dedicated user-management tools; you would run such statements through its single execute_sql tool, limited by the connection's privileges.