MCP Database Servers Compared: Cloud Relays vs Local MCP

A year ago, "let the AI look at my database" was a party trick. You wired up an MCP server, asked Claude to list your tables, watched it do the thing, and then closed the tab and went back to your real workflow. It was neat. It was also rough enough that you didn't trust it with anything that mattered.

That's changed. MCP support is now standard across the assistants people actually use — Claude Desktop, Cursor, Windsurf, Codex — and the servers have gotten better. Schema discovery works, query generation works, and the loop is reliable enough that I reach for it several times a day without thinking about it.

Which means the interesting question has shifted. It's no longer whether to connect an AI to your database. It's where the connection lives. That one decision determines who holds your credentials, what your data touches on the way to the model, and whether your teammates can use the same setup.

There are three architectures in common use, and they get lumped together in a lot of "MCP for databases" listicles as if they were interchangeable. They are not. I've set up all three and built one of them into a product, so I have opinions. But this isn't a hit piece on the cloud options — they solve real problems, and I'll say so. The point is a clear-eyed map so you pick deliberately instead of defaulting to whatever the first tutorial you read told you to do.

What an MCP database server actually is

Strip away the marketing and a database MCP server is a small, almost boring thing: it's a process that holds a database connection and exposes it to an AI assistant as a set of callable tools.

MCP — the Model Context Protocol — is an open protocol for exactly this. It's JSON-RPC based, which is a fancy way of saying the client and server exchange structured request and response messages. The client is the AI assistant you're chatting with. The server is a separate process that does the actual work. The client decides when to call a tool based on the conversation; you don't invoke anything manually. You say "show me the orders from last week" and the assistant figures out that it should call the query tool with some SQL.

A database server typically exposes a handful of tools along these lines:

list tables — enumerate the tables in the database
describe schema — return the columns, types, and constraints for a given table
run query — execute a SQL statement and return rows
execute — run a statement that changes data or schema (often gated behind a flag)

The exact names vary from server to server, but the shape is consistent. The AI reads the tool definitions when it connects, sees that a run query tool exists, and knows it can reach for it when a question calls for real data.

The part people miss is the split between the client and the server, and the fact that the server has to get from wherever it runs to your database somehow. Two transports are common. Local stdio means the server is a child process of the AI client, running on your machine, talking over standard input and output — no network involved at all. HTTP or SSE means the server is reachable over the network, which is what you need when it isn't running on the same machine as the client.

If you want the hands-on version of this — the actual config files and step-by-step setup — I wrote a full walkthrough in setting up a local MCP server for your database. This post is the comparison; that one is the tutorial.

Three architectures

There are three ways people put an MCP database server into production. They feel identical from the chat window. They are very different underneath.

Cloud relay

A cloud relay is a hosted MCP endpoint. Instead of running a server yourself, you sign up for a service, hand it your database connection details — a connection string, or an OAuth grant into your database — and it gives you a URL to drop into your MCP client config. The AI client sends tool calls to the vendor's cloud, the vendor's cloud runs the queries against your database, and the results come back the same way.

The appeal is obvious, and I want to be fair about it. Setup is genuinely zero: no process to install, no runtime to manage, no config file beyond a URL. It works from any machine, including a locked-down corporate laptop where you can't install software. And it's shareable — a whole team can point at the same endpoint, which is something local setups struggle with. If your organization has a central platform team that wants to offer "database access for AI" as a managed internal service, the relay model is a natural fit, and some of these services add query logging, rate limiting, and audit trails that a bare local server doesn't have.

The cost is equally obvious once you say it out loud: your connection credentials live on someone else's servers, and every query you run — the SQL and the rows it returns — transits their infrastructure. That's two separate exposures. The credential one worries me more, because a database credential is a key to the whole database, not just the one query you ran. The data exposure is the one people usually mention first, and it's real: the result set passes through the relay on its way back to you and on its way to the model.

None of that is a reason to call relays bad. It's a reason to be precise about what you're buying. A relay is a trust decision — you're deciding the convenience of zero setup is worth adding a third party to a path that would otherwise be two parties. For a read-only analytics database where the data is already broadly accessible, that trade can be fine. For a production database with customer records, it usually isn't.

Self-hosted remote

The middle option is to run the MCP server yourself, but not on your laptop. You stand it up on a VPS, a container, or an internal host, and your AI client connects to it over HTTP. This is the "I want the reach of a relay without the third party" option.

You control the host. You control the credentials — they're on infrastructure you own, not a vendor's. You can put it behind your VPN, put it on a private subnet, wire it into your existing auth, and log it however you like.

The tradeoff is that you've just taken on an always-on service. That server is now a long-running process with a database connection and a network listener, which means it has an auth surface, a patching cadence, and an availability story. It's reachable from the network by design — that's the point — so the question becomes who can reach it and with what. If it's exposed to the internet without solid auth in front of it, you've built a database proxy and left the door unlocked.

Self-hosting is the right answer for some teams — particularly ones with the operational maturity to run internal services well. It's a bad answer for a solo developer who just wants the AI to see their local Postgres, because the maintenance overhead buys them nothing.

Local MCP

Local MCP is the simplest of the three to reason about. The server is a process on your laptop. It talks to the client over stdio, or over HTTP bound to localhost. Your credentials never leave the machine, because the machine holding them is the machine the server runs on, and the client is on that machine too.

The flow is short enough to say in one line: AI client → local server process → your database, all on hardware you control. Nothing in that path crosses a network boundary it doesn't have to. When the database is itself local — a SQLite file, or a Postgres instance running in Docker — the entire loop can run with the wifi off, which is a property none of the other architectures have.

The tradeoff is that it's per-machine. Your config lives on your laptop. Your teammate's laptop has its own. There's no shared endpoint, no central place to update, and no way for one person's careful setup to benefit anyone else. If you rotate a database credential, you rotate it in one place on your machine and separately on everyone else's. For a solo developer or a small team, that's a rounding error. For an organization of fifty, it's the thing that pushes you toward one of the remote options.

There's also a wrinkle worth naming: local MCP is only as safe as the machine. If your laptop is compromised, so is the database connection it holds. That's true of any credential on the machine, though, so it isn't a point against local MCP specifically — it's just the standard endpoint security posture, and it's a smaller and more familiar problem than "a third party holds a key to my production database."

The comparison

Here's the side-by-side. The column that matters most is the last one, but the middle columns are where the real tradeoffs live.

Architecture	Where credentials live	Setup effort	Team sharing	Data leaves your machine?
Cloud relay	Vendor's servers	Minimal — sign up, paste a connection string, copy a URL	Built in — one endpoint for everyone	Yes — queries and results transit the vendor
Self-hosted remote	Your host (VPS/container/internal)	Moderate — deploy, secure, and maintain a service	Yes, if you share it — plus access management	Yes — leaves the client machine for your server
Local MCP	Your machine only	Low — install and configure per machine	No — per-machine by design	No — the server runs on your machine

A few things fall out of that table.

First, "does data leave your machine" and "does it reach the model" are two different questions, and it's easy to conflate them. With local MCP, your credentials never leave, and the query results still go to the AI provider, because the model needs to see them to answer you. That's fundamental to how all of this works — you cannot have an AI reason about your data without the AI seeing your data. What local MCP removes is the relay: the extra party sitting between your machine and the model. It doesn't remove the model itself, and no architecture does.

Second, the setup-effort column is misleading on its own, because it measures the first hour and not the hundredth. Cloud relay wins the first hour decisively. Self-hosted remote loses the first hour and keeps losing it every time you patch, rotate, or debug. Local MCP is easy the first hour and stays easy, but you pay for it in the "team sharing" column.

Third, team sharing is the one place the local model is genuinely weak, and I won't pretend otherwise. If your org needs a shared, managed, auditable database-access layer for AI, a remote architecture is the right call, full stop. Local MCP is a personal tool, and it's best evaluated as one.

What to look for in a database MCP server

Whichever architecture you pick, the server's own feature set matters enormously. A database connection handed to an AI is a powerful thing, and the difference between a careful server and a careless one is the difference between a tool you can use on real data and a liability. Here's what I actually check.

Read-only mode. This is table stakes. A good server can be configured to allow SELECT and schema inspection while refusing anything that writes — no INSERT, no UPDATE, no DELETE, no DDL. For any database you can't afford to lose, this should be the default, not an option you have to hunt for.

Per-source scoping. If you have several databases connected, the server should let you choose which ones are exposed to the AI. You want to be able to say "the AI can see the scratch database but not the production one" without disconnecting anything. This is one of the most underrated controls, because it lets you be generous with the AI on the databases that don't matter and strict on the ones that do.

Confirmation before destructive operations. The AI should not be able to drop a table or wipe rows without a deliberate step. Whether that's a mode that blocks writes entirely or a confirmation prompt, the point is that destruction is never a single unguarded tool call. This matters because models make mistakes and because prompt injection is real — if the AI reads hostile text from your data, you don't want that text to be able to turn into a DROP TABLE.

Localhost-only binding. If the server speaks HTTP, it should bind to 127.0.0.1, not 0.0.0.0. The difference is whether anyone else on your network can reach it. A database MCP server accidentally exposed on a coffee-shop wifi network is a bad afternoon.

Audit and log visibility. You should be able to see what queries the AI has actually run. When something looks off — an unexpected write, a query touching a column it had no business touching — you want a record to look at. Servers that expose this are giving you a feedback loop; servers that don't are asking you to trust blindly.

Database coverage. Check that the databases you actually use are supported, and supported well. A server that nominally "supports Postgres" but chokes on schemas with extensions, or one that can't handle SQLite's quirks, is worse than useless because it'll fail in confusing ways.

Can you point it at a replica? The single best hardening move for AI database access is to connect it to a read replica rather than the primary. If the server can be pointed at a replica — or if you can simply give it a read-only user on one — then even a catastrophic mistake by the model can't damage your production data. It's the database equivalent of working on a copy, and it's the advice I give most often.

The landscape

I'm going to describe this in categories rather than a product list, because the MCP ecosystem moves fast enough that any specific list is stale by the time you read it. But the categories are stable, and they're worth understanding.

Official and community servers for specific databases. There are MCP servers for Postgres, for SQLite, and for MySQL, maintained by a mix of the protocol's own community and independent developers. They generally take a connection string or a file path, connect directly to the database, and expose the query/schema tools described above. They're typically open source and auditable, which is a real virtue — you can read exactly what they do. The catch is that most of them are direct servers: they hold your credentials, they run wherever you run them, and they tend to be minimal on access controls. Many don't have a robust read-only mode, and most don't give you per-source scoping or an audit log. They're excellent for local development against a throwaway database and a poor fit for anything production-grade without additional wrapping.

Hosted offerings that wrap a database connection. These are the cloud relays. The category includes services whose entire product is "connect your database to your AI" — you sign up, they handle the connection, and you get an endpoint. Quality varies widely, and the security posture varies even more, which is exactly why the checklist above matters. The ones worth considering are the ones that are honest about their data handling, offer read-only and scoping controls, and can explain in plain language what happens to your credentials and your query results.

Desktop tools that ship their own local MCP server. This is the newest category and the one I'm closest to, since BaseVolt is in it. The idea is that the database tool you're already using to browse and edit data also runs an MCP server on localhost as one of its features. Because the tool already manages your connections and credentials, the MCP server inherits that management — credentials stay in the app, encrypted locally, and the AI client talks to a process on your machine rather than a remote endpoint.

BaseVolt is a local-first desktop app for macOS and Windows that connects directly to PostgreSQL, MySQL, SQLite, and Cloudflare D1. Its MCP server runs on localhost — the default endpoint is http://localhost:3107/mcp — and since it's local, the AI client is talking to a process on your own machine, not relaying through a third party. It supports read-only mode and per-data-source restrictions, so you can expose one database to the AI and keep another out of reach entirely, and it logs MCP tool calls so you can see what the AI actually did. You can see the whole workflow without installing anything at the live demo.

The reason I built it this way rather than shipping a standalone relay is precisely the credential problem. The tool already has to hold your database credentials to work at all — that's what a database client is. Giving it an MCP server means those credentials never have to be duplicated into a config file or handed to a vendor. The AI client never sees them, and neither does the model.

A security checklist before you connect an AI to your database

This is the part I'd print out. None of it is exotic; all of it is easy to skip.

Start with a read-only user or a replica. Create a database user with SELECT-only privileges, or point the server at a read replica. Do this before anything else. It's the single highest-leverage thing on this list, because it makes the entire rest of the risk surface dramatically smaller. If the AI can't write, the worst case stops being "data loss" and becomes "the model saw something it shouldn't have."
Never point it at production with write access. Not as a default, not "just to test," not for five minutes. Write access to production through an AI client is a mistake you only get to make once. If you need the AI to help with schema changes, do it against a copy.
Scope to one database. Don't hand the AI everything you can reach. Expose the specific database it needs for the task at hand, and nothing else. This limits both the blast radius of a mistake and the amount of data the model can wander into.
Keep it on localhost where possible. If the server can run on your machine, run it there. A localhost-bound server isn't reachable from the network, which removes an entire class of problem. Only go remote when you have a reason — team sharing, or a machine you can't install on — and when you do, secure the endpoint deliberately.
Treat query results as data the model now has. This is the mental model shift people resist. The moment a result set comes back through the MCP server, those rows are part of the conversation context and are on their way to the model provider. If a column contains something you wouldn't paste into a chat window, don't select it. Use SELECT with explicit columns instead of SELECT *, and filter out what you don't need.
Review what the server logs. Look at the query log regularly, at least at first. You're looking for surprises — writes you didn't ask for, tables you didn't expect the AI to touch. A log you never read is the same as no log.
Revoke credentials when you're done. If you spun up a dedicated user for AI access, delete it when the experiment is over. If you used a token, rotate it. Credentials that were created for a purpose should not outlive that purpose, because the next person to find them won't know why they exist.

The theme running through all of it is that you should be minimizing what the AI can reach, not just who can reach the AI. Most of the conversation about MCP security is about protecting the server. The bigger win is usually limiting what the server is allowed to touch.

How to choose

If you've read this far, here's how I'd actually decide.

If you're a solo developer or a small team working with databases you care about, go local. Install a tool that ships its own local MCP server, or run a direct server against a local database. Keep credentials on your machine. Accept that it's per-machine, because for a small team that cost is trivial. This is the architecture with the best security posture and the least ongoing maintenance, and it covers the overwhelming majority of use cases.

If your organization needs shared, managed, auditable access, go remote — and do it deliberately. Either self-host, so you own the host and the credentials, or pick a relay whose data handling you've actually read. Put real auth in front of it. Give it a read-only user or a replica. Treat it as an internal service with an owner, not a set-and-forget endpoint.

If you're just exploring, use whatever is fastest, but use a throwaway database. The relay's zero-setup experience is a genuine advantage when you're kicking the tires. Just don't let the throwaway database quietly become the production one. The migration from "fun experiment" to "load-bearing tool" is exactly when the architecture decision becomes expensive to reverse.

The one thing I'd avoid is the default a lot of people fall into without deciding: a cloud relay wired straight into a production database with write access, because it was the first tutorial and it worked on the first try. That combination is convenient and it's the one I'd least want to be running.

Bottom line

MCP database servers are genuinely useful now, and the question that matters isn't whether to use one — it's where the connection lives. Cloud relays buy you zero setup and team sharing, and they charge for it in trust: your credentials and your query results pass through a third party. Self-hosted remote servers give you control of the host at the cost of an always-on service with a network-facing auth surface. Local MCP keeps credentials and the database connection on your own machine and gives up easy team sharing in return.

There's no single right answer, and I'd be lying if I said there were. But there is a good default: keep the connection local whenever you can, put a read-only user or a replica in front of anything that matters, scope the AI to the one database it needs, and remember that whatever the model reads, it now knows. Do those four things and the architecture question mostly answers itself.

BaseVolt is my take on the local end of this — a desktop app that connects directly to your databases and runs its own localhost MCP server, so the AI client talks to a process on your machine instead of a relay. The Hobby tier is free forever and covers two data sources with no account required, and Pro is $99/year for unlimited data sources if you outgrow it. You can see the pricing or just try it — there's a 14-day trial with no credit card, and the demo shows the workflow without installing anything.

If you want the setup steps rather than the comparison, the local MCP tutorial walks through it end to end.