Connecting Claude to MySQL or MariaDB: Three Architectures Compared

If you've tried to connect Claude or another AI coding tool to a database that isn't sitting on your laptop, you've probably run into the same fork in the road: where does the MCP server actually run, and how does it reach the database?

There are three common answers, and each one trades off stability, security, and maintenance burden differently. Here's how they actually compare in production, not just in a quick demo.

Option 1: Remote MCP hosted on the database server

You run the MCP server directly on (or next to) the box that hosts MySQL or MariaDB, and Claude connects to it remotely over HTTP.

• Stability: Good, as long as the server stays up. One less network hop between the MCP server and the database.
• Security: The weak point. You're exposing an MCP endpoint on a server that also holds your database — a compromised MCP process is a compromised database host. If you go this route, put it behind a VPN or a strict allowlist, never on the open internet.
• Maintenance: You now have server-side software to patch and monitor in addition to the database itself. Every client (your laptop, a teammate's laptop, CI) needs network access to that endpoint.

This is the right call when multiple people or services need shared access to the same MCP server and you're already running infrastructure to support it. It's the wrong call for a single developer who just wants Claude to see their data.

Option 2: Local MCP with a direct remote connection

The MCP server runs on your machine (stdio, no network exposure of the MCP protocol itself), and it opens a direct connection out to the remote database — over the public internet or a VPN.

• Stability: Simple, fewer moving parts than a tunnel. But you're now depending on the database being reachable from wherever you're working, which usually means it needs a public endpoint or you need to be on the VPN.
• Security: Depends entirely on how the database is exposed. A public MySQL endpoint, even with strong auth, is a bigger attack surface than one that's never reachable from the internet at all.
• Maintenance: Lowest overhead of the three — no tunnel process to manage, no bastion host.

Reasonable if the database is already behind a VPN you're on anyway. Not something to reach for if it means opening the database to the public internet just to make this work.

Option 3: Local MCP + SSH tunnel

The MCP server runs locally and forwards its database connection through an SSH tunnel to a bastion host, which reaches the database on a private network.

• Stability: The tunnel is the extra failure mode here — it can drop, and if your MCP server doesn't detect and reconnect, queries just hang or fail until you notice and restart it by hand.
• Security: The best of the three. The database is never exposed publicly, and access is gated by SSH key auth to a bastion you control. This is what most security-conscious teams end up doing.
• Maintenance: The highest of the three unless the tunnel handling is automated. Managing SSH keys, bastion hosts, and reconnect logic by hand across a team gets old fast — this is usually where people end up building or buying something to handle it for them.

Which one for production?

For a solo developer or small team with a database that's already reachable on a VPN, option 2 is the least amount of engineering for the security bar you probably need. For anything handling customer data, or a team bigger than a couple of people, option 3 is the real production pattern — the database stays private, and you're gating access at the bastion instead of at the database itself.

Option 1 is really a different problem: shared infrastructure for a team or service, not a personal AI-to-database bridge.

Where this gets automated

The maintenance cost in option 3 — tunnel lifecycle, reconnects, credential handling — is exactly what pushes people toward a packaged tool instead of hand-rolling it. That's the gap Bufflehead is built for: a native binary that handles the tunnel, IAM auth, and reconnect logic for you, so the security model of option 3 doesn't come with the maintenance tax.

Worth being direct about scope: Bufflehead's database connectors today are Postgres (direct, or over an AWS SSM tunnel using your existing IAM roles) and BigQuery, plus local files and S3. MySQL and MariaDB aren't supported yet. If that's what's blocking you from trying it, we're genuinely interested in hearing about it — open an issue on GitHub or reach out and it'll factor into what we build next.