MySQL (DBHub) for database management
Bytebase's DBHub connects an agent to a MySQL or MariaDB database, and it lands as our second pick for database management because of how much of the world runs on MySQL. The agent inspects schema and runs SQL against live data through one universal database server.
It ranks second rather than first because the DBHub Postgres build covers the largest engine in this set, but for the enormous base of apps built on MySQL this is the clean, direct fit. It is a community server (not vendor-official), which is worth knowing when you weigh it against the official options.
How MySQL (DBHub) fits
DBHub keeps the surface deliberately small. execute_sql runs queries against the connected database with transaction support and safety controls, so the agent can read rows, and mutate them when you allow it, with a real transaction boundary. search_objects explores the schema (tables, columns, indexes, procedures) with progressive disclosure, which means the agent pulls schema detail incrementally instead of flooding its context with the whole catalog.
The trade-off of that minimal surface is that there are no migration-specific or branching tools here; schema changes happen as SQL you choose to run. Among the siblings, DBHub (Postgres) is the same server pointed at Postgres and is the lead for that engine, MongoDB is the pick when the data is documents rather than tables, Supabase wraps Postgres with auth and storage, and Neon adds serverless Postgres with branching so an agent can test a change on a copy. For a MySQL or MariaDB database, DBHub is the match.
Tools you would use
| Tool | What it does |
|---|---|
| execute_sql | Executes SQL queries against the connected database with transaction support and safety controls. |
| search_objects | Searches and explores database schema (tables, columns, indexes, procedures) with progressive disclosure to avoid overwhelming the context. |
FAQ
- Can an agent change my MySQL schema through DBHub?
- It can run any SQL you permit through execute_sql, including DDL, with transaction support and safety controls. There are no dedicated migration or branching tools; schema changes are SQL you choose to run. For branch-per-change testing, Neon's server fits that workflow better.
- How does the agent learn my schema without overloading context?
- search_objects explores tables, columns, indexes, and procedures with progressive disclosure, so the agent pulls schema detail incrementally rather than loading the entire catalog at once. It can then write correct SQL for execute_sql.