MCP 数据库服务器对比：云中继 vs 本地 MCP

一年前，"让 AI 看看我的数据库"还是个派对把戏。你接上一个 MCP server，让 Claude 列出你的表，看着它做了那件事，然后关掉标签页回到你真正的工作流。它挺妙的。它同时也粗糙到你不会把任何要紧的东西托付给它。

这已经变了。MCP 支持现在在人们真正使用的助手里已是标配——Claude Desktop、Cursor、Windsurf、Codex——而服务器们已经变得更好。schema 发现能用了，查询生成能用了，这个循环可靠到我不假思索地一天用上几次。

这意味着有趣的问题已经转移了。它不再是是否把 AI 连到你的数据库。而是连接住在哪里。那一个决定决定了谁持有你的凭据、你的数据在通往模型的路上碰到什么，以及你的同事能不能用同一套设置。

有三种常用架构，它们在很多"MCP for databases"的清单文里被混为一谈，仿佛可以互换。它们不是。这三种我都设置过，还把其中一种做进了产品，所以我有观点。但这不是一篇打击云选项的文章——它们解决真实的问题，我会这么说。重点是一张清晰的图，让你刻意地选，而不是默认用你读到的第一个教程告诉你的做法。

一个 MCP 数据库服务器到底是什么

剥掉营销，一个数据库 MCP server 是个很小、几乎无聊的东西：它是一个持有数据库连接、并把它作为一组可调用工具暴露给 AI 助手的进程。

MCP——Model Context Protocol——正是为此而设的一个开放协议。它基于 JSON-RPC，用花哨的说法就是客户端和服务器交换结构化的请求和响应消息。客户端是你正在聊天的 AI 助手。服务器是一个做实际工作的独立进程。客户端根据对话决定何时调用一个工具；你不手动调用任何东西。你说"给我看看上周的订单"，助手自己弄明白它应该带着某个 SQL 调用查询工具。

一个数据库服务器通常暴露这样几个工具：

list tables —— 枚举数据库里的表
describe schema —— 返回某张表的列、类型和约束
run query —— 执行一条 SQL 语句并返回行
execute —— 运行一条改动数据或 schema 的语句（通常藏在一个 flag 后面）

确切的名称因服务器而异，但形状是一致的。AI 在连接时读取工具定义，看到存在一个 run query 工具，并知道当问题需要真实数据时它可以伸手去拿它。

人们漏掉的部分是客户端和服务器之间的分离，以及服务器必须以某种方式从它运行的地方到达你的数据库。两种传输方式很常见。本地 stdio 意味着服务器是 AI 客户端的一个子进程，在你的机器上运行，通过标准输入输出对话——完全不涉及网络。HTTP 或 SSE 意味着服务器可通过网络触达，当它不和客户端在同一台机器上运行时你就需要这个。

如果你想要这件事的动手版本——实际的配置文件和一步步的设置——我在为你的数据库设置本地 MCP server 里写了一篇完整演练。本文是对比；那篇是教程。

三种架构

人们把 MCP 数据库服务器投入生产有三种方式。从聊天窗口看它们一模一样。在底层它们非常不同。

云中继

云中继是一个托管的 MCP 端点。你不用自己跑服务器，而是注册一个服务，把数据库连接细节交给它——一个连接字符串，或者一个进入你数据库的 OAuth 授权——它给你一个 URL 放进你的 MCP 客户端配置里。AI 客户端把工具调用发给厂商的云，厂商的云对你的数据库跑查询，结果以同样的方式回来。

吸引力很明显，我想对此公平。设置真的是零：没有要安装的进程、没有要管理的运行时、除一个 URL 外没有配置文件。它从任何机器都能用，包括你没法装软件的锁定企业笔记本。而且它是可共享的——整个团队能指向同一个端点，这是本地设置吃力的一点。如果你的组织有一个中央平台团队想把"给 AI 的数据库访问"作为一个托管的内部服务提供，中继模型是天然契合的，而且其中一些服务增加了裸本地服务器没有的查询日志、限流和审计轨迹。

代价一说出口同样明显：你的连接凭据住在别人的服务器上，而你跑的每个查询——SQL 和它返回的行——都经过他们的基础设施。那是两种独立的暴露。凭据那个更让我担心，因为一个数据库凭据是通向整个数据库的钥匙，不只是你跑的那一个查询。数据暴露是人们通常先提到的那个，而且它是真的：结果集在回到你、以及去往模型的路上都经过中继。

这些都不是说中继不好的理由。它是精确说明你在买什么的理由。中继是一个信任决定——你在决定零设置的便利值得在一个本该是两方的路径上加入第三方。对一个数据本就广泛可访问的只读分析数据库，这个取舍可以是合适的。对一个有客户记录的生产数据库，通常不是。

自托管远程

中间的选项是自己跑 MCP server，但不在你的笔记本上。你把它架在一台 VPS、一个容器，或一台内部主机上，你的 AI 客户端通过 HTTP 连接它。这是"我想要中继的触达但不要第三方"的选项。

你控制主机。你控制凭据——它们在你拥有的基础设施上，不是厂商的。你可以把它放在你的 VPN 后面、放在私有子网里、接进你现有的认证，并随意记录日志。

取舍是你刚刚接手了一个常开的服务。那台服务器现在是一个长期运行的进程，带着一个数据库连接和一个网络监听器，这意味着它有一个认证面、一个打补丁节奏和一个可用性故事。它按设计可从网络触达——这正是重点——所以问题变成谁能触达它、用什么触达。如果它暴露给互联网而没有坚实的认证在前面，你就建了一个数据库代理并忘了锁门。

自托管对某些团队是正确答案——尤其是那些有运营成熟度、能好好跑内部服务的。对一个只想让 AI 看到自己本地 Postgres 的独立开发者，它是个糟糕答案，因为维护开销什么也没给他换来。

本地 MCP

本地 MCP 是三者中最容易推理的。服务器是你笔记本上的一个进程。它通过 stdio，或通过绑定到 localhost 的 HTTP 与客户端对话。你的凭据从不离开这台机器，因为持有它们的机器就是服务器运行的机器，而客户端也在这台机器上。

这个流程短到能用一行说清：AI 客户端 → 本地服务器进程 → 你的数据库，全在你控制的硬件上。那条路径上没有任何东西越过它不必越过的网络边界。当数据库本身就是本地的——一个 SQLite 文件，或者一个跑在 Docker 里的 Postgres 实例——整个循环能在 wifi 关掉时运行，这是其他架构都没有的性质。

取舍是它是逐机器的。你的配置住在你的笔记本上。你同事的笔记本有它自己的。没有共享端点、没有中央更新点，也没有办法让一个人的精心设置惠及任何人。如果你轮换一个数据库凭据，你在自己机器的一个地方轮换它，还要在别人每个人的机器上单独轮换。对一个独立开发者或小团队，那是个舍入误差。对一个五十人的组织，那是把你推向某个远程选项的东西。

还有一个值得点名的褶皱：本地 MCP 只和机器一样安全。如果你的笔记本被攻陷，它持有的数据库连接也就被攻陷了。不过机器上的任何凭据都是如此，所以这不是专门针对本地 MCP 的一点——它只是标准的端点安全姿态，而且它是一个比"第三方持有我生产数据库的钥匙"更小、更熟悉的问题。

对比

这是并排对比。最重要的列是最后一列，但中间几列才是真正取舍所在。

架构	凭据住在哪里	设置成本	团队共享	数据离开你的机器吗？
云中继	厂商的服务器	极小 —— 注册、粘贴连接字符串、复制 URL	内置 —— 所有人一个端点	是 —— 查询和结果经过厂商
自托管远程	你的主机（VPS/容器/内部）	中等 —— 部署、加固并维护一个服务	是，如果你共享它 —— 外加访问管理	是 —— 离开客户端机器去你的服务器
本地 MCP	仅你的机器	低 —— 逐机器安装配置	否 —— 按设计逐机器	否 —— 服务器在你的机器上运行

从那张表里能掉出几点。

第一，"数据是否离开你的机器"和"它是否到达模型"是两个不同的问题，很容易把它们混为一谈。用本地 MCP，你的凭据从不离开，而查询结果仍然去 AI 提供方，因为模型需要看到它们才能回答你。这对这一切的运作方式是根本的——你不可能让 AI 对你的数据推理而 AI 不看你的数据。本地 MCP 移除的是中继：坐在你机器和模型之间的额外一方。它不移除模型本身，而没有任何架构能移除。

第二，设置成本那一列单独看有误导性，因为它衡量的是第一个小时而不是第一百个小时。云中继决定性地赢下第一个小时。自托管远程输掉第一个小时，并在你每次打补丁、轮换或调试时继续输。本地 MCP 第一个小时容易并保持容易，但你在"团队共享"那一列为此付出代价。

第三，团队共享是本地模型真正弱的唯一地方，我不会假装不是。如果你的组织需要一个共享、受管、可审计的给 AI 用的数据库访问层，远程架构是正确的选择，句号。本地 MCP 是个人工具，最好作为个人工具来评估。

一个数据库 MCP server 该看什么

不管你选哪种架构，服务器自己的功能集都极其重要。一个交给 AI 的数据库连接是件强大的东西，而一个谨慎的服务器和一个粗心的服务器之间的差异，是一个你能在真实数据上使用的工具和一个负债之间的差异。这是我实际检查的。

只读模式。 这是基本要求。一个好的服务器可以配置成允许 SELECT 和 schema 检查，同时拒绝任何写入——没有 INSERT、没有 UPDATE、没有 DELETE、没有 DDL。对任何你输不起的数据库，这应该是默认，而不是一个你得去找的选项。

按数据源限定范围。 如果你连接了好几个数据库，服务器应该让你选择哪些暴露给 AI。你想能说"AI 能看到临时数据库但看不到生产数据库"，而不用断开任何东西。这是最被低估的控制之一，因为它让你在无关紧要的数据库上对 AI 大方，在要紧的那些上严格。

破坏性操作前确认。 AI 不应该能在一个不带刻意步骤的情况下 drop 一张表或清空行。无论那是一个完全阻止写入的模式，还是一个确认提示，重点是破坏永远不是一个毫无防护的工具调用。这很重要，因为模型会犯错，也因为提示注入是真的——如果 AI 从你的数据里读到敌意文本，你不会想让那段文本能变成一个 DROP TABLE。

仅绑定 localhost。 如果服务器讲 HTTP，它应该绑定 127.0.0.1，而不是 0.0.0.0。差异在于你网络上的其他人能不能触达它。一个意外暴露在咖啡馆 wifi 网络上的数据库 MCP server 是一个糟糕的下午。

审计和日志可见性。 你应该能看到 AI 实际跑了哪些查询。当有什么看起来不对劲时——一个意料之外的写入、一个碰了它无权碰的列的查询——你想要一条记录来看。暴露这个的服务器给你一个反馈循环；不暴露的在要求你盲目信任。

数据库覆盖。 检查你实际用的数据库被支持，而且被支持得好。一个名义上"支持 Postgres"但在带扩展的 schema 上卡壳的服务器，或者一个处理不了 SQLite 怪癖的服务器，比没用更糟，因为它会以令人困惑的方式失败。

你能把它指向一个副本吗？ 给 AI 数据库访问加固的最佳单一动作，是把它连到一个只读副本而不是主库。如果服务器能被指向一个副本——或者你可以简单地在一个副本上给它一个只读用户——那么即使模型犯下灾难性的错误也伤不了你的生产数据。这是数据库版的在副本上工作，也是我给出最频繁的建议。

全景

我会用类别而不是产品清单来描述这个，因为 MCP 生态动得足够快，任何具体清单在你读到它时都过时了。但类别是稳定的，值得理解。

针对具体数据库的官方和社区服务器。 有给 Postgres 的、给 SQLite 的、给 MySQL 的 MCP server，由协议自己的社区和独立开发者混合维护。它们通常接受一个连接字符串或一个文件路径，直接连接数据库，暴露上面描述的查询/schema 工具。它们通常开源且可审计，这是一个真正的优点——你能读到它们到底做什么。麻烦是它们大多是直接服务器：它们持有你的凭据，它们在你跑它们的任何地方运行，而且它们在访问控制上往往很简陋。很多没有健壮的只读模式，大多数不给你按数据源限定范围或审计日志。它们对一个一次性的本地开发数据库很出色，对任何生产级的东西如果没有额外的包装就很糟糕。

包装数据库连接的托管服务。 这些就是云中继。这个类别包括那些整个产品就是"把你的数据库连到你的 AI"的服务——你注册，他们处理连接，你得到一个端点。质量差异很大，安全姿态差异更大，这正是上面那份检查清单重要的原因。值得考虑的是那些诚实地对待自己的数据处理、提供只读和范围控制、并能用平实的语言解释你的凭据和查询结果会怎样的。

自带本地 MCP server 的桌面工具。 这是最新的类别，也是我最接近的，因为 BaseVolt 在其中。想法是，你已经用来浏览和编辑数据的数据库工具，也把在 localhost 上跑一个 MCP server 作为它的功能之一。因为这个工具已经在管理你的连接和凭据，MCP server 继承那份管理——凭据留在应用里、在本地加密，而 AI 客户端与你机器上的一个进程对话，而不是一个远程端点。

BaseVolt 是一款本地优先的桌面应用，支持 macOS 和 Windows，直接连接 PostgreSQL、MySQL、SQLite 和 Cloudflare D1。它的 MCP server 在 localhost 上运行——默认端点是 http://localhost:3107/mcp——而因为它是本地的，AI 客户端是在和你自己机器上的一个进程对话，不是经过第三方中继。它支持只读模式和按数据源的限制，所以你可以把一个数据库暴露给 AI，把另一个完全挡在触达之外，而且它记录 MCP 工具调用，让你能看到 AI 实际做了什么。你可以在在线演示不安装任何东西就看到整个工作流。

我之所以这样做而不是发布一个独立中继，恰恰是凭据问题。这个工具为了能工作本来就必须持有你的数据库凭据——那正是一个数据库客户端所是。给它一个 MCP server 意味着那些凭据永远不必被复制进一个配置文件或交给一个厂商。AI 客户端从不看到它们，模型也从不看到。

在你把 AI 连到你的数据库之前的安全检查清单

这是我愿意打印出来的那部分。没有一条是奇特的；每一条都很容易被跳过。

从一个只读用户或一个副本开始。 创建一个只有 SELECT 权限的数据库用户，或者把服务器指向一个只读副本。在做任何别的事之前先做这个。这是这份清单上单一最高杠杆的事，因为它让整个其余的风险面戏剧性地变小。如果 AI 不能写，最坏情况就不再是"数据丢失"，而变成"模型看到了它不该看的东西"。
绝不要带着写权限把它指向生产。 不作为默认，不"只是测试一下"，不为了五分钟。通过 AI 客户端对生产的写权限是一个你只能犯一次的错误。如果你需要 AI 帮忙做 schema 变更，对着一个副本做。
限定到一个数据库。 不要把你能够到的所有东西都交给 AI。只暴露它手上任务需要的那个具体数据库，别的都不要。这既限制了错误的爆炸半径，也限制了模型能晃进去的数据量。
尽可能让它留在 localhost。 如果服务器能在你的机器上跑，就在那儿跑。一个绑定 localhost 的服务器不可从网络触达，这消除了一整类问题。只在你有理由时才走远程——团队共享，或者一台你没法安装的机器——而当你这么做时，刻意地加固端点。
把查询结果当作模型现在拥有的数据。 这是人们抵触的心智模型转变。结果集一通过 MCP server 回来，那些行就成为对话上下文的一部分，并在去往模型提供方的路上。如果某一列含有你不会粘进聊天窗口的东西，就不要选它。用带显式列的 SELECT 而不是 SELECT *，并过滤掉你不需要的。
审阅服务器记录了什么。 定期看查询日志，至少一开始要这样。你在找意外——你没要求的写入、你没想到 AI 会碰的表。一个你从不读的日志等于没有日志。
做完后吊销凭据。 如果你为 AI 访问专门起了一个用户，实验结束时删掉它。如果你用了一个 token，轮换它。为某个目的创建的凭据不应该比那个目的活得更久，因为下一个发现它们的人不会知道它们为什么存在。

贯穿这一切的主题是，你应该在最小化AI 能够到什么，而不只是谁能到 AI。关于 MCP 安全的大多数对话都是在保护服务器。更大的收益通常是限制服务器被允许碰什么。

如何选择

如果你读到这儿，这是我实际会怎么决定。

如果你是独立开发者或处理你在乎的数据库的小团队，走本地。 安装一个自带本地 MCP server 的工具，或者对着一个本地数据库跑一个直接服务器。让凭据留在你的机器上。接受它是逐机器的，因为对小团队那个成本微不足道。这是安全姿态最好、持续维护最少的架构，而且它覆盖绝大多数用例。

如果你的组织需要共享、受管、可审计的访问，走远程——并刻意地做。 要么自托管，这样你拥有主机和凭据，要么挑一个你真的读过其数据处理的中继。在它前面放上真正的认证。给它一个只读用户或一个副本。把它当作一个有负责人的内部服务，而不是一个设好就忘的端点。

如果你只是在探索，用最快的东西，但用一个一次性数据库。 当你在试水时，中继的零设置体验是一个真正的优势。只是别让那个一次性数据库悄悄变成生产那个。从"有趣的实验"到"承重的工具"的迁移，正是架构决定变得昂贵到无法逆转的时候。

我会避免的一件事是很多人没做决定就掉进去的默认：一个直接接进带写权限生产数据库的云中继，因为它是一个教程而且第一次就成功了。那个组合很方便，也是我最不愿意在跑的。

总结一下

MCP 数据库服务器现在真的有用，而要紧的问题不是是否用一个——而是连接住在哪里。云中继给你零设置和团队共享，代价是信任：你的凭据和查询结果经过第三方。自托管远程服务器给你对主机的控制，代价是一个常开的、有面向网络的认证面的服务。本地 MCP 把凭据和数据库连接留在你自己的机器上，换出去的是轻松的团队共享。

没有单一的正确答案，如果我说有那就是撒谎。但有一个好的默认：尽可能让连接保持本地，在任何要紧的东西前面放一个只读用户或一个副本，把 AI 限定到它需要的那个数据库，并记住模型读过的任何东西它现在都知道了。做到这四件事，架构问题大多自己就回答了。

BaseVolt 是我对这件事本地那一端的理解——一个直接连接你数据库、并跑自己的 localhost MCP server 的桌面应用，所以 AI 客户端与你机器上的一个进程对话，而不是一个中继。Hobby 档永久免费，覆盖两个数据源、无需账号，而 Pro 是每年 $99 的无限制数据源，如果你用超了的话。你可以看看定价，或者直接试——有一个 14 天试用、无需信用卡，而演示不安装任何东西就展示这个工作流。

如果你想要设置步骤而不是对比，本地 MCP 教程端到端地走了一遍。