Bytebase + MCP: Gate the Migrations Your AI Agent Writes
The agent writes the migration and it looks fine. Column name is sensible, the type is right, it even remembered the index. You skim it, approve it, and it ships.
Then at 2pm the ALTER TABLE takes a full lock on a forty-million-row table and the app is down for eleven minutes.
The agent wasn't wrong, exactly. The SQL did what it said. It just didn't know that this particular statement, on this particular table, at this particular hour, was a bad idea. And neither did you, skimming a diff in a chat window.
The fix isn't a better prompt. It's not handing the agent a database connection in the first place.
Give It a Change Request, Not a Connection
Bytebase sits between whoever wants to touch your database and the database itself. Humans go through the web UI, applications go through the API, and AI agents go through its MCP server. Everything lands in the same pipeline: a change gets proposed, reviewed against rules, and only then executed.
That's the whole idea. Your agent stops being a client with credentials and becomes a requester with a paper trail. We covered the same shape recently with OpenProject and MCP: give the agent a governed door rather than a key.
docker run --rm --init \
--name bytebase \
--publish 8080:8080 --pull always \
--volume ~/.bytebase/data:/var/opt/bytebase \
bytebase/bytebase:latest
Port 8080, data in /var/opt/bytebase. Current release is 3.22.1, shipped September 10.
Wiring the Agent In
The MCP server speaks HTTP, so the client config is short:
{
"mcpServers": {
"bytebase": {
"type": "http",
"url": "https://<your-bytebase-url>/mcp"
}
}
}
Now ask your agent to add a column. Here's what does not happen: the statement does not run.
Per Bytebase's own documentation, a proposed change "always creates a fresh sheet, plan, and issue". The agent's output becomes a change issue sitting in your pipeline, waiting for review. It also never edits an existing issue, so an agent can't quietly amend something you already looked at.
Every action is audit logged, which matters more than it sounds when three people and two agents all have access.
The Gate That Actually Does the Work
Human review is the part that fails first. You approve eleven trivial migrations, and the twelfth one has the table lock in it.
This is why SQL Review is the feature that earns its keep. Bytebase ships over 200 pre-deployment rules, and they run on every proposed change before a human sees it. Naming conventions, missing WHERE clauses, statements that will take destructive locks, dropping columns still in use. Rules carry a severity: an error blocks the change, a warning lets it through with a note.
A machine checking machine-generated SQL against explicit rules, every single time, does not get bored on the twelfth migration.
When something does get through, Community edition includes a changelog of every applied change and one-click rollback.
The Part Everyone Gets Wrong
Read this line from the MCP docs carefully: the assistant gains "all your permissions in Bytebase, including making changes to database or updating settings."
All of them. If you wire up MCP with your own admin account, you have handed your agent your admin rights. The change-issue pipeline still applies to database writes, but settings are settings.
Create a dedicated service account, scope it to the projects the agent should touch, and give it the minimum role that lets it open issues. Bytebase's built-in IAM with users, roles and permissions is in the free tier, so there is no excuse for skipping this.
What You Get Free, and What You Don't
Bytebase is open core. The bulk of the source is MIT, with directories containing "enterprise" and the code controlling feature and plan enablement under a separate commercial licence. Worth knowing exactly where the line falls before you build a process on it:
| Community (free) | Paid tiers |
|---|---|
| SQL Review, 200+ pre-deployment rules | Custom approval workflows |
| Declarative schema migration, schema sync | Risk assessment |
| Backup and one-click rollback | Custom roles |
| Rollout policies, progressive and scheduled | Dynamic data masking, just-in-time access |
| Changelog, built-in IAM, SQL editor | Extended audit log retention |
The honest read: the automated gate is free, and the customisable human gate is not. For the agent problem specifically that's the right way round, because the value is in rules that run every time without a person, not in routing approvals through three managers.
If you need risk-based approval routing or dynamic masking, price it before you design around it.
Troubleshooting
The agent edits an existing issue instead of opening a new one. It can't. Every proposal creates a fresh sheet, plan and issue by design. If you expected an update, you are looking at a new issue.
A migration ran without review. Check whether it went through Bytebase at all. An application holding direct database credentials bypasses the pipeline entirely, and that includes your agent if it also has a raw connection configured.
SQL Review passes things you expected it to block. Check rule severity. Warnings do not stop a change, only errors do.
The agent can change settings. Expected, and the reason you use a scoped service account rather than your own login.
Running It
Bytebase on Elestio starts at $11/month fully managed, with SSL, automated backups, monitoring and updates handled, across Hetzner, DigitalOcean, Vultr, Linode, Scaleway, Netcup, AWS or your own VM.
Start with one non-production database and a handful of SQL Review rules. Point the agent at it, ask for a schema change, and watch the issue appear instead of the change. That loop is the whole point, and it takes about twenty minutes to see it work.
Thanks for reading ❤️ See you in the next one 👋