Supabase's MCP server ships inside Gemini Enterprise with two safety labels

Supabase became a prebuilt connector in Google Cloud's Gemini Enterprise on September 9th. Connect a Supabase organisation once and anyone in Gemini Enterprise can query it in English, next to GitHub, Linear, Notion, Slack and Salesforce.

What is underneath is not new, and Google says so. "Connecting Supabase's MCP Server to Gemini Enterprise means your backend is part of that conversation, grounded in live data from your actual projects," says Rayn Veerubhotla, a Google managing director for partner technical architects. This is the MCP server Supabase already had, with a Google badge and a place in a connector menu.

The sentence we would put on the whiteboard is much further down the post: "Connections are made at the Supabase organization level, and every tool the connector exposes is annotated as read-only or destructive."

Two labels. Is that the whole permission model? As described in the post, yes.

We are not being unfair to it. That annotation is probably the right axis, and it is more than many integrations bother with (most MCP servers ship no annotation at all). But consider what a two-valued flag cannot express. A read that returns forty million rows of customer records is read-only. A read that joins auth tables is read-only. select * from payments is read-only. On the other side, drop table and a routine migration are both destructive, and only one of them should ever happen from a chat box on a Tuesday afternoon.

The scoping story around it is thin in the same way. On the Business edition, Supabase "shows up in the connector menu. Once you select it and sign in to your Supabase organization, the connection is live, with nothing to configure on your end." Standard, Plus and Frontline editions route it through an admin console with a client ID and secret, which is the version an enterprise security team would recognise. Business is the one to think about, because the unit of connection is the whole organisation and the unit of authorisation seems to be a person clicking a menu item.

Supabase does answer the obvious data-residency question directly, and the answer is good: "Gemini Enterprise doesn't store or index your Supabase data: every response is fetched in real time from your organization, so what you see reflects the current state of your projects." Nothing is copied into a Google index. If a prompt touches several connected tools the results are combined at answer time, so you can ask about a feature and get the Supabase tables next to the Jira tickets tracking it.

Our read is that the sequencing tells you where this is going. Sixteen days earlier, on August 24th, Supabase shipped enterprise-managed auth for its MCP server. First you make the MCP server something an IT department can govern, then you put it inside somebody else's assistant. Expect roughly the same pair of posts, in the same order, from every database company with an MCP server this quarter.

And we would expect the read-only/destructive taxonomy to grow. A third value, or per-table scoping, or a row-count ceiling — some way to say that a query is safe for the schema and unsafe for the people in it (row-level security helps here and is not mentioned once). If that has not arrived within a year, either nobody has run this against a table with real customer data in it, or somebody has and we have not heard about it yet.

The stated case for all this is the person who does not live in the Supabase dashboard: IT and ops checking database metrics or table structure without direct access. That is a real user, and giving them a read-only English query is a genuinely nice thing to do. Which is exactly why the interesting question is not what the connector can do.

It is who, in your organisation, can now click one menu item and find out.