连接器和 NL2SQL 端点并不是实现同一目标的两种方法。第一个用于通过 Claude 或 ChatGPT 与您的基地交谈。第二个是允许您自己的产品的用户用自然语言提问，无论他们使用或不使用任何人工智能客户端。其本机AI 的后端将第二个需求视为可在其代码中验证的产品功能，而不是事后组装的第三方服务。
要点
- Supabase 于 2026 年 2 月 3 日推出了官方 Claude Connector，并于 2026 年 5 月 8 日推出了官方 ChatGPT 应用程序，记录在其官方博客和 claude.com 上。
- MCP 连接器将 Claude 或 ChatGPT 插入 Supabase 项目：自然语言 → 动作翻译保留在 AI 客户端，而不是 Supabase API 本身。
- Native NL2SQL 是一种不同的架构：后端端点，用于转换和验证 SQL 中的问题，可由任何应用程序调用，无论使用什么 AI 客户端。
- 连接器首先为通过 Claude 或 ChatGPT 与其项目聊天的开发人员或操作人员提供服务。本机 NL2SQL 为基于该后端构建的产品的 最终用户 提供服务。
- 在撰写本文时，尚无法确认 Supabase 的官方 Perplexity 连接器：如果您遇到任何提及它的情况，请谨慎对待。
两次正式发布，相隔三个月
2026 年 2 月 3 日，Supabase 宣布推出官方 Claude 连接器。自 2025 年以来，Claude.ai 提供了一个连接器目录，允许您一键将远程 MCP 服务器连接到对话。 2026 年 5 月 8 日，Supabase 加入 ChatGPT Apps 目录，该计划由 OpenAI 于 2025 年推出，旨在将第三方服务直接集成到聊天界面中。
这两项公告均记录在 Supabase 官方博客 (supabase.com/blog) 上，以及 Claude 方面的 claude.com 上。他们扩展了旧工具。 Supabase 自 2025 年以来一直维护开源 MCP 服务器，已在 Cursor 或 Windsurf 等编辑器中使用，用于列出表并执行读取查询。它还用于应用对话中的迁移。
Claude 连接器和 ChatGPT 应用程序很可能是两个主流平台的托管和打包版本，而不是专为该场合构建的全新功能。每个展示的工具的确切细节无法独立验证：将此读数视为合理的推论，而不是已确认的技术规范。
会话连接器和本机 NL2SQL 不能解决相同的问题
MCP 连接器的工作原理类似于遥控器。 Claude 或 ChatGPT 接收问题，决定在连接器公开的工具中调用哪个工具，然后在对话中返回答案。理解意图并选择操作发生在助手的语言模型中，而不是在 Supabase API 中：Supabase 公开工具，Claude 或 ChatGPT 决定它们的使用。
本机 NL2SQL 端点逆转了这一责任。后端直接接收问题，调用配置好的LLM本身，验证生成的SQL，然后执行有界查询。此功能位于后端 API 中：任何应用程序都可以为自己的用户调用它，而无需通过 Claude.ai 或 ChatGPT 应用程序。
| 尺寸 | 会话连接器 | 本机 NL2SQL（后端） |
|---|---|---|
| 语言→动作翻译在哪里？ | 在助理模型中（Claude、ChatGPT） | 在后端API本身 |
| 典型最终用户 | 开发者或运营者，在 Claude 或 ChatGPT 中 | 任何使用后端产品的用户 |
| 可嵌入到您自己的产品中 | 不行，你必须打开 Claude 或 ChatGPT | 是的，从您自己的界面进行 API 调用 |
| 语言模型提供者 | 由用户选择的AI客户端设置 | 可在后端配置（例如 OpenAI、Claude、Gemini） |
| 验证生成的 SQL | 取决于连接器实现，对第三方不透明 | 可在公开它的后端代码中进行验证 |
这两种架构并不存在竞争：后端可以很好地同时为其操作员公开 MCP 连接器，并为其最终用户公开本机 NL2SQL 端点。 Supabase 时间表显示的是开发投资首先流向的地方。
分发选择，而不仅仅是技术选择
从工程角度来看，构建 MCP 连接器的成本比构建和维护自己的 NL2SQL 端点要低。连接器重用了 Anthropic 或 OpenAI 为其模型开发的推理和安全性。本机端点需要后端提供商来管理对 LLM 的调用、生成的 SQL 的验证以及幻觉本身的风险。
还有一个分配论点。 Claude 和 ChatGPT 的用户群比任何单独的 BaaS 都要大得多。发布官方连接器可将 Supabase 直接纳入数百万已打开 Claude 或 ChatGPT 的用户的日常工作流程中。他不需要说服他们先访问他自己的网站。
日历强化了这种解读。在这两个公告之前，Supabase 已经维护了一个开源 MCP 服务器；官方连接器扩展了现有的吸引力，而不是从头开始打开一个新站点。这与 Supabase 已经非常活跃的内容和可见性战略是一致的，而不仅仅是对新产品产能的押注。
连接器是否可以取代您产品中对 NL2SQL 的需求？
Claude 连接器或 ChatGPT 应用程序假定最终用户使用兼容的帐户和订阅打开 Claude 或 ChatGPT。这非常适合在编码时查询自己项目的开发人员，或者通过对话在生产中进行调试的操作员。这不适合 SaaS 的最终用户，他们希望在您自己的界面中得到响应，而不是在旁边的 Claude 选项卡中。
安全问题值得单独提出。将通用对话助手连接到能够在生产数据库中读取（有时还可以写入）的工具会扩大攻击面：含糊的问题或对提示的操作可能会引导助手执行不需要的操作，这种风险通常记录在 MCP 服务器上，而不是 Supabase 特有的。本机 NL2SQL 端点面临相同类型的风险，但后端提供商直接控制验证，而不是依赖第三方。
在 Claude 和 ChatGPT 关于 AI 连接器的同一对话中，常常会出现困惑。截至撰写本文时，没有官方消息来源证实专用于 Supabase 的 Perplexity 连接器。如果这样的集成存在或出现，它应该具有相同的阅读框架：连接器为人工智能客户端的用户提供服务，而不是自动为您自己的产品的最终用户提供服务。
将需求与架构相匹配，而不是最新的公告
考虑第一个需求：“我想在开发时通过 Claude 或 ChatGPT 与我的基础人员交谈”。 MCP 连接器直接响应它，无论下面使用的 Postgres 后端如何。这是运营商的需求，而不是产品的需求。
考虑第二个需求：“我希望我的产品的用户在我的界面中以自然语言提问，而不依赖于 Claude 或 ChatGPT 帐户”。在后端比较中，要检查的右侧框是 API 中公开的本机 NL2SQL。这是一种产品能力，而不是一种开发工具。例如，Aurabase 公开了一个 NL2SQL 端点，该端点可验证语法树生成的 SQL，并系统地限制返回的行数，并在其代码中进行验证。 我们对 NL2SQL 的演示 列出了完整的机制，分步教程 展示了如何构建端点。
NL2SQL 背后的 LLM 提供商的选择也很重要。将 Claude、OpenAI 和 Gemini 视为专用本机客户端的后端的行为与通过单个 OpenAI 兼容端点路由它们的后端不同。我们的比较 原生 AI 网关与 OpenAI 兼容 详细说明了这种差异。有关 Postgres 上可用的本机 AI 功能的概述，请参阅 我们的本机 AI 页面。
常见问题解答
Supabase 的两项公告解决了一个分发问题：出现在数百万人与人工智能聊天的地方，而不是将这些对话吸引到自己的产品上。这是一个有道理的赌注，但它不能替代您自己的用户在后端嵌入的 NL2SQL 功能。
在检查比较网格中的“AI”框之前，请检查这两种架构中的哪一种真正满足您的需求。一个服务于与他的基地讨论的操作员；另一个服务于您产品的最终用户。要将此选择放在更广泛的比较中，请参阅 Aurabase 与 Supabase。