Cursor and Supabase: An App Stack That Works Safely

To build a database-backed app with Cursor and Supabase, add the Supabase MCP server to Cursor's mcp.json with the URL https://mcp.supabase.com/mcp, scope it to one project with project_ref, and turn on read_only=true until you need writes. Supabase's Free plan costs $0 and Pro starts at $25 a month. Setup checked 31 October 2026.

The stack at a glance

Cursor's third-party models start on Premium; Plus covers Cursor's own models only. If you want Claude or GPT models on Cursor, plan for Premium, or see Cursor pricing.

What the stack is for

The pairing gives an agent two things it normally lacks: your real database schema and a safe place to run SQL. Without it, you describe your tables in prose and hope. With it, Cursor can list tables and extensions, read migrations, run queries, generate TypeScript types from the schema and search Supabase's docs, then write app code against what actually exists.

It is a common route for the kind of builds covered by vibe coding: a web or mobile app with sign-in, a Postgres database and a few serverless functions, written mostly by an agent and reviewed by you. See Cursor vibe coding for the working style.

Setup, step by step

1. Add the server

Put this in .cursor/mcp.json for one project, or ~/.cursor/mcp.json for all projects, per Supabase's guide:

{
  "mcpServers": {
    "supabase": {
      "url": "https://mcp.supabase.com/mcp"
    }
  }
}

For local development with the Supabase CLI, use http://localhost:54321/mcp instead.

2. Scope it

Add query parameters to the URL, joined with &:

A safe starting URL: https://mcp.supabase.com/mcp?project_ref=YOUR_REF&read_only=true. Do not use skip_elicitations until you have a reason.

3. Authenticate

No personal access token is needed for the default setup. Cursor opens a browser sign-in through Supabase OAuth; choose the organisation that holds your project. With the Cursor CLI:

agent mcp enable supabase
agent mcp login supabase
agent mcp list

If tools do not appear, restart Cursor. Check the connection under Settings, Cursor Settings, Tools & MCP.

4. Add rules

Tell the agent how to behave around the database. A short block in .cursor/rules or AGENTS.md:

## Database
- Use the Supabase MCP for schema questions; do not guess table names.
- Make schema changes as migrations, never by editing tables directly.
- Enable row level security on every new table and write policies in the same migration.
- Never run write queries against production. Use a branch or a dev project.
- Generate TypeScript types after every migration.

Cursor reads AGENTS.md as well as its own rules. See write a good AGENTS.md and the AGENTS.md starter template.

Tool groups

Supabase's guide lists what the server can do, and which groups to leave off:

For a first build, features=database,docs,development covers most needs. Add debugging when you are tuning, and leave Edge Functions off until you want the agent to deploy.

Safety: read this before you connect

Supabase's own warnings are blunt, and we repeat them because this is the part people skip.

• Prompt injection. Data in your database, such as support tickets, can contain instructions that trick the model into running harmful queries. Keep Cursor's manual tool-call approval on and review each call.
• Production data. Connect to production only when necessary. Use project scoping, read-only mode and restricted feature groups. Keep secrets and unrelated personal data out of prompts.
• Your permissions. The server acts with your permissions. Do not hand it to customers or end users.
• Unattended runs. For scheduled or background agents, use read-only mode and pre-approve only the read-only tools they need.
• Confirmations are guardrails, not guarantees. Cost and SQL confirmations may not catch every risk.
• Test on a branch. Use Supabase branching, which needs a paid plan, to try database changes before they reach production.

Practical set-up that follows from this: a separate Supabase project for development, with fake data, connected through the MCP server in write mode; a production project that is not connected to the agent at all, or only read-only and scoped. Apply production migrations by reviewing the migration file and running it yourself.

For an app that holds real user data, also read secure a vibe-coded app. The first thing to check in any generated Supabase app is row level security on every table that a browser client can reach.

What Supabase costs

From supabase.com/pricing on 31 October 2026:

The Free plan pausing after a week of inactivity is the gotcha for hobby projects: a demo you share a month later may be asleep. For anything with users, plan on Pro.

A first build

An illustrative sequence, using only the tools described above:

1. Create a Supabase project for development and note its project reference.
2. Add the MCP server with project_ref and read_only=true. In Cursor, ask: "List the tables in this project." You should see none, or the defaults.
3. Switch off read-only for the dev project only. Ask Cursor to propose a schema for your app (for example, projects and tasks) as a migration, and read it before it applies.
4. Ask it to enable row level security and write policies in the same migration.
5. Generate TypeScript types and ask for the app code against them.
6. Run the app and test sign-in and one real flow. Use the Debugging group's advisors to check security and performance.
7. Commit the migrations to git. They are the source of truth, not the dashboard.

For tests in a real browser, add Playwright MCP. For deployment steps see deploy a vibe-coded app.

Which Cursor plan do you need

Cursor's plans, from our Cursor page: Free (limited agent and Chat), Plus at $8, Premium at $30, Super at $100 and Ultra at $200 a month. Plus covers Agent with Cursor's own models only, and third-party models arrive on Premium, paid at API list price from prepaid credit. Usage is one weekly pool shared across the editor agent, the CLI and Cloud Agents.

For this stack, that means:

• Trying it: Free is enough to connect the server and see whether the workflow suits you.
• Building a real app: Premium, if you want a frontier third-party model writing your migrations and policies, since schema work rewards a strong model.
• Heavy daily use: Super, once a weekly pool on Premium runs out.

Database work is usually token-light compared with building a large interface, because the agent reads schemas and writes short migrations. The expensive part is the front end. Watch your usage on the first project before you upgrade.

Troubleshooting

• No Supabase tools in Cursor. Restart Cursor after authorising, then check Tools & MCP. With the CLI, run agent mcp list.
• Wrong organisation. The OAuth step asks you to choose one. Re-run login and pick the organisation that contains your project.
• The agent cannot see another project. With project_ref set, the server is limited to that one project and account tools are disabled. Remove it only if you need to list projects.
• Writes fail. With read_only=true, all queries run as a read-only Postgres user. Switch it off on the development project when you want migrations applied.
• Storage tools are missing. Storage is disabled by default, per Supabase's guide. Enable it deliberately through the features setting if you need it.
• Branching is unavailable. Branching is experimental and needs a paid plan.
• A free project went to sleep. Free projects pause after a week of inactivity. Restore it from the dashboard, or move to Pro.

Wiring the app itself

The MCP server helps the agent write code; your app talks to Supabase through its own client libraries and the project URL and keys. The Development tool group can return the project URL and API keys, so be careful: a key pasted into a prompt or committed to git is a leak. Keep keys in environment variables, use the public anon key in browser code only when row level security protects every table, and keep the service role key on the server side. Ask the agent to put new secrets in an .env file that is ignored by git, and review commits before you push.

For a mobile build, see Expo MCP, and for hosting see Vercel MCP and Cloudflare MCP.

Other agents

The same Supabase server works in other MCP clients; Supabase's guide has instructions per tool. If you prefer a terminal, Claude Code can use the same server. If you want a hosted builder with Supabase-style backends in one place, see Lovable and Bolt. For other databases, see Postgres MCP and Neon MCP.

Reviewing a migration the agent wrote

Before you apply any migration, read it with these questions.

• Does every new table enable row level security, and is there a policy for each action?
• Are columns that hold user data typed and constrained, and are foreign keys in place?
• Does it drop or rename anything? Destructive changes need a backup and a second look.
• Does it add indexes for columns you filter or join on?
• Can you roll it back, and have you tried that on the development project?

Ask the agent to explain each statement in plain words. If it cannot, rewrite the request. The migration file, committed to git, is your record of the database, so treat it as code that gets reviewed.

Finally, test your row level security from the client side. Sign in as a normal user in the browser and try to read another user's rows. If you can, the policy is wrong, whatever the agent said. This takes a few minutes and catches the most common serious flaw.

Our take

This is an editorial reading of the Supabase and Cursor documentation, not a test we ran.

The stack is a good match: Cursor is strong at writing app code, Supabase gives it a real schema and a managed Postgres, and the MCP server joins them. The risk is also plain in Supabase's own page. An agent that can run SQL on your database is a powerful tool, and data in that database can talk back to it.

Our rule would be simple. Connect the agent to a development project, never to production. Keep read-only on whenever you are only exploring. Treat migrations as code you review. Check row level security by hand before launch. Supabase's free tier is enough to build and demo, but its inactivity pause means you should move to Pro once real users arrive.

Checklist

• Create a separate Supabase project for development
• Add the server URL with project_ref and read_only=true
• Authenticate through the browser and confirm in Tools & MCP
• Add database rules to .cursor/rules or AGENTS.md
• Keep manual tool approval on
• Make every schema change a reviewed migration in git
• Check row level security on every table before launch
• Plan for Pro before real users arrive