Let Cursor manage your Supabase project

Switching between the editor and the dashboard to check tables, logs and migrations breaks your flow.

4 stepsSimple

CursorClaude CodeSupabaseGitHub

How it connects

Your AI reaches your apps through small connectors called MCP servers.

Your AI

CursorClaude Code

Connectors

SupabaseGitHub

Your apps

SupabaseGitHub

This setup is for developers building on Supabase who keep switching to the dashboard to check tables, logs and migrations. The Supabase MCP server lets Cursor or Claude Code list tables, run SQL, read logs and draft migrations, and GitHub keeps those migrations in a reviewed branch. You end up asking database questions from the editor instead of clicking through the dashboard.

Set it up

4 steps. Open one for the details.

1Add the Supabase MCP server
In Cursor, open Settings > MCP and add Supabase's remote server at https://mcp.supabase.com/mcp, or run claude mcp add with the same URL in Claude Code. Sign in to Supabase in the browser window that opens and pick your organisation. Check that tools such as list_tables and execute_sql appear.
Tip: Connect a development project, not production, the first time.
2Start in read-only mode
Add read_only=true and project_ref=your-project-ref as query parameters on the server URL. Read-only mode runs SQL as a read-only Postgres user, and the project ref stops the agent from touching other projects. Ask the agent to list tables to confirm the scope.
Tip: You find the project ref in the project's URL or under Project Settings.
3Ask in context
Ask the agent to describe a table, explain a slow query, check the logs for errors, or draft a migration for a new column. It runs read queries and returns the SQL it plans for any change. Read the SQL before you apply anything.
Tip: Ask for the advisors check to catch missing RLS policies and indexes.
4Commit migrations
Save new migrations as files in supabase/migrations and ask the agent to commit them to a new branch through the GitHub MCP server or your local git. Open a pull request so someone reviews the SQL before it reaches production. Apply migrations through your normal deploy process.
Tip: Keep the agent out of production writes; let CI or the Supabase CLI apply migrations.

Then just ask

Things to say once it's connected. Click one to copy it.

Ask Cursor…Cursor

Good to know

What you need, what it won't do, and how to keep it safe.

What you need

A Supabase account and a development project
Cursor or Claude Code
A GitHub repository with a supabase/migrations folder
The Supabase CLI if you apply migrations locally

Limits

Read-only mode blocks writes, so the agent cannot test a migration against the database for you.
Table contents can include prompt injection text; review what the agent does after reading user data.
The agent only sees the scoped project, not your other environments.

Keep it safe

Keep read-only mode on for production projects.
Scope the server to a development project first.

Supabase MCP Server (database-read, database-write, project-admin) GitHub MCP Server (repository-read, issue-write, pull-request-write)

Questions

Straight answers before you start

Is it safe to connect the agent to my database?

Supabase recommends connecting the MCP server to development projects and using read-only mode. Scope it to one project with project_ref and keep tool approvals on in Cursor.

Which Supabase plan do I need?

The MCP server works with free and paid Supabase projects. Features such as branching depend on your plan.

Can the agent apply migrations?

With read-only mode off, it has an apply_migration tool. This setup keeps it read-only and sends migrations through GitHub review instead.

What about data in my tables?

Query results go into the conversation and to the model provider. Use a project with test data, or avoid selecting columns with personal data.