A connector and an NL2SQL endpoint are not two ways of achieving the same thing. The first is used to talk to your base from Claude or ChatGPT. The second is to allow users of your own product to ask questions in natural language, regardless of which AI client they are using, or without using any. A backend whose nativeAI treats this second need as a product capability, verifiable in its code, rather than as a third-party service assembled after the fact.
The essentials
- Supabase launched an official Claude Connector on February 3, 2026 and an official ChatGPT App on May 8, 2026, documented on its official blog and on claude.com.
- An MCP connector plugs Claude or ChatGPT into a Supabase project: the natural language → action translation remains on the AI client side, not in the Supabase API itself.
- Native NL2SQL is a different architecture: an endpoint of the backend which translates and validates a question in SQL, callable by any application, regardless of the AI client used.
- A connector first serves the developer or operator who chats with his project from Claude or ChatGPT. Native NL2SQL serves the end users of the product built on that backend.
- No official Perplexity connector for Supabase could be confirmed at the time of writing: treat with caution if you come across any mention of it.
Two official launches, three months apart
On February 3, 2026, Supabase announced an official Claude connector. Since 2025, Claude.ai has offered a directory of connectors that allows you to connect a remote MCP server to a conversation in one click. On May 8, 2026, Supabase joined the ChatGPT Apps catalog, the program launched by OpenAI in 2025 to integrate third-party services directly into the chat interface.
Both announcements are documented on the official Supabase blog (supabase.com/blog) and, on the Claude side, on claude.com. They extend an older tool. Supabase has maintained an open source MCP server since 2025, already used in editors like Cursor or Windsurf to list tables and execute read queries. It is also used to apply a migration from the conversation.
The Claude connector and the ChatGPT App are, in all likelihood, a hosted and packaged version for two mainstream platforms, rather than an entirely new capability built for the occasion. The exact details of the tools exhibited by each could not be independently verified: treat this reading as a reasonable inference, not a confirmed technical specification.
Conversational connector and native NL2SQL do not solve the same problem
An MCP connector works like a remote control. Claude or ChatGPT receives the question, decides which tool to call among those exposed by the connector, then returns the answer in the conversation. Understanding the intention and choosing the action happens in the language model of the assistant, not in the Supabase API: Supabase exposes tools, Claude or ChatGPT decides their use.
A native NL2SQL endpoint reverses this responsibility. The backend receives the question directly, calls a configured LLM itself, validates the generated SQL, then executes a bounded query. This capability lives in the backend API: any application can call it for its own users, without ever going through Claude.ai or the ChatGPT app.
| Dimensions | Conversational connector | Native NL2SQL (backend) |
|---|---|---|
| Where does the language → action translation live? | In the assistant model (Claude, ChatGPT) | In the backend API itself |
| Typical end user | The developer or operator, in Claude or ChatGPT | Any user of the product built on the backend |
| Embeddable in your own product | No, you have to open Claude or ChatGPT | Yes, an API call from your own interface |
| Language model provider | Set by user-chosen AI client | Configurable on the backend side (e.g. OpenAI, Claude, Gemini) |
| Validation of generated SQL | Depends on connector implementation, opaque to a third party | Verifiable in the backend code that exposes it |
These two architectures are not competing: a backend can very well expose an MCP connector for its operators and a native NL2SQL endpoint for its end users, at the same time. What the Supabase timeline shows is where the development investment went first.
A distribution choice, not just a technical choice
Building an MCP connector costs less, in engineering terms, than building and maintaining your own NL2SQL endpoint. The connector reuses reasoning and security already developed by Anthropic or OpenAI for their models. The native endpoint requires the backend provider to manage the call to the LLM, the validation of the generated SQL, and the risk of hallucination itself.
There is also a distribution argument. Between them, Claude and ChatGPT have a much larger user base than that of any BaaS taken in isolation. Releasing an official connector puts Supabase directly into the daily workflow of millions of people who already open Claude or ChatGPT. He doesn’t need to convince them to visit his own site first.
The calendar reinforces this reading. Supabase already maintained an open source MCP server before these two announcements; official connectors extend an existing traction rather than opening a new site from scratch. This is consistent with a content and visibility strategy already very active at Supabase, more than a bet on a new product capacity.
Does a connector replace a need for NL2SQL in your product?
A Claude connector or ChatGPT App assumes that the end user opens Claude or ChatGPT, with a compatible account and subscription. This is very suitable for a developer who queries his own project while coding, or for an operator who debugs in production from a conversation. This is not suitable for an end user of your SaaS, who expects a response in your own interface, not in a Claude tab next to it.
The security question deserves to be asked separately. Connecting a general conversational assistant to tools capable of reading, and sometimes writing, in a production database broadens the attack surface: an ambiguous question or manipulation of the prompt can direct the assistant towards an unwanted action, a risk documented on MCP servers in general, not specific to Supabase. A native NL2SQL endpoint faces the same type of risk, but the backend provider then directly controls validation, rather than depending on a third party.
Perplexity often comes up in the same conversation as Claude and ChatGPT about AI connectors. No official source confirms, at the time of writing, a Perplexity connector dedicated to Supabase. If such an integration exists or appears, it deserves the same reading framework: a connector serves the user of the AI client, not automatically the end users of your own product.
Match the need to the architecture, not the most recent announcement
Take a first need: “I want to talk to my base from Claude or ChatGPT while I develop”. An MCP connector responds directly to it, regardless of the Postgres backend used underneath. This is an operator need, not a product need.
Take a second need: “I want users of my product to ask questions in natural language, in my interface, without depending on a Claude or ChatGPT account”. The right box to check, in a backend comparison, is a native NL2SQL exposed in API. This is a product capability, not a development tool. Aurabase, for example, exposes an NL2SQL endpoint that validates syntax tree-generated SQL and systematically bounds the number of rows returned, verified in its code. Our presentation of NL2SQL lays out the complete mechanics, and the step-by-step tutorial shows how to build the endpoint.
The choice of LLM provider behind this NL2SQL also matters. A backend that treats Claude, OpenAI and Gemini as dedicated native clients does not behave like a backend that routes them all through a single OpenAI compatible endpoint. Our comparison native AI Gateway vs OpenAI compatible details this difference. For an overview of the native AI capabilities available on Postgres, see our native AI page.
FAQs
Supabase's two announcements address a distribution question: being present where millions of people are chatting with an AI, rather than attracting these conversations to its own product. It's a defensible bet, but it's not a substitute for embedded NL2SQL capability in the backend for your own users.
Before checking an “AI” box in your comparison grid, check which of the two architectures really meets your needs. One serves the operator who discusses with his base; the other serves the end users of your product. To situate this choice in a broader comparison, see Aurabase vs Supabase.