Should I use the service role key or the anon key?

For most 'ask Claude about our data' questions, service role (or a SELECT-only Postgres role). The anon key is for browser clients and is limited by RLS — analytics-style questions often see nothing useful.

Does the service role bypass RLS?

Yes. That's why it can answer dashboard-style questions — and why you treat it like a password, prefer a staging project, and restrict tables in Synra.

Can I use the Postgres connection string instead?

Yes. Supabase is Postgres. Use the direct URI (port 5432), not the pooler (6543), under PostgreSQL in Synra. Same database either way.

Should Claude talk to my production Supabase project?

Prefer a staging project or sanitized data first. If you need current prod-shaped numbers, use a careful read path — see point AI at a read replica / staging-first.

Does this work in Claude.ai and Claude Desktop?

Yes if your plan supports custom connectors / MCP. Paste the Synra HTTPS endpoint; no local Supabase MCP process required on the managed path.

Is this different from Connect Cursor to Supabase?

Same Synra connection. Different client steps (Claude connectors vs Cursor mcp.json). Cursor guide: connect-cursor-to-supabase. Older overview: mcp-server-for-supabase.

Connect Claude to Supabase | Claude MCP Setup

Supabase is Postgres plus Auth and a SQL editor. Claude is already where people ask for numbers. Usually the bridge is copy-paste from the dashboard.

With MCP, Claude runs read-only SQL on your project through a gateway URL. This is the Claude setup: credentials, RLS, connector UI. Cursor: Connect Cursor to Supabase. Shorter overview: Supabase MCP server.

Also: staging first, SELECT-only, table allowlists.

What you can ask once it’s connected

“How many rows in profiles vs auth users that never got a profile?”
“Subscriptions stuck in trialing older than 14 days — count by plan.”
“Any orders with null user_id that our RLS assumes is always set?”

Claude inspects schema, runs SELECT, answers from rows. Follow-ups don’t need another dashboard trip.

Service role vs anon (the Supabase-specific part)

| Key | Role | For Claude + Synra? | |-----|------|---------------------| | anon | Browser / RLS-limited | Usually too weak for ops questions | | service_role | Bypasses RLS | Common choice — treat like a password | | SELECT-only Postgres user | Your grants only | Best when you can create one |

If you paste anon and Claude “sees no rows,” that’s often RLS — not Synra broken.

Service role sees what RLS would hide from end users. Prefer a staging Supabase project, or a Postgres role with SELECT on specific tables, before production service role in chat. Where query results go still applies.

Step 1 — Credentials

Option A — Project URL + service role

Supabase project → Project Settings → API
Copy Project URL (https://….supabase.co)
Copy service_role (not anon)

Option B — Direct Postgres URI

Project Settings → Database → Connection string → URI
Port 5432 (direct), not pooler 6543
In Synra you’ll pick PostgreSQL and paste the URI

Step 2 — Save in Synra

mcpserver.design → Connections → Add
Supabase (Option A) or PostgreSQL (Option B)
Paste credentials → name it supabase-staging (be honest)
Test → Save
Open table access — allow reporting tables, leave secrets/identity off if you can

Encrypted at rest. Claude only gets the MCP endpoint URL later.

Step 3 — Copy the MCP endpoint

Endpoints tab:

https://app.mcpserver.design/api/mcp/aB3xY7zQ9mNpLkRv2wTs

Treat the token like a password. Rotate if it hits Slack. Team sharing if more than you will use it.

Step 4 — Add to Claude

In Claude (web or desktop, with custom connectors):

Customize → Connectors (menus move; look for custom / MCP connectors)
Add custom connector
Name: Synra Supabase staging
Paste the Synra URL
Auth: none / as Synra docs — token is in the URL
Save and confirm tools appear (list_tables, describe_table, query_table, execute_sql)

If tools don’t show: MCP troubleshooting.

Step 5 — Smoke test

“List tables in this Supabase database.”
“Describe profiles.”
“How many signups in the last 7 days?” (use real table names after inspect)
Deliberate write → should fail

Then verify against the SQL editor once.

Supabase habits that save pain

Staging project first. Free tier second project is cheaper than explaining a PII paste.

Don’t commit service role keys. Synra holds them; Claude holds the endpoint only.

RLS ≠ gateway read-only. RLS shapes what anon sees. Synra blocks writes at the gateway. Different layers.

auth schema. Questions about auth.users need a role that can read it — service role usually can; a tight custom role might not. Say so in the prompt if you’re limited.

Pooler flakiness. If Option B misbehaves, switch to direct 5432.

Same Synra URL elsewhere

One connection works in Cursor and ChatGPT if you paste the same endpoint. Separate endpoints if staging vs prod — don’t reuse names.

Credentials into Synra, endpoint into Claude, ask something you already know the answer to.

7-day trial: mcpserver.design.

Related reading:

Connect Cursor to Supabase — same DB, Cursor
MCP Server for Supabase — shorter overview
Ask Claude About Your Database — plain-English workflow
Point AI at a Read Replica — when you outgrow staging
Share AI Database Access With Your Team — don’t Slack prod service-role endpoints
Staging First — environment ladder