Claude Code connects to Supabase through the official @supabase/mcp-server-supabase MCP server, letting the agent query schemas, run migrations, and manage Edge Functions directly from the terminal instead of manual dashboard work.\n\n## Short Answer\n\nClaude Code uses Supabase's official MCP server to read schemas, run SQL, apply migrations, and manage Edge Functions via natural language. Configure it read-only or project-scoped by default, since agent-driven writes and destructive SQL are the primary risk in 2026 production workflows.\n\n## Why Claude Code and Supabase Are a Natural Pairing in 2026\n\nSupabase's schema is plain Postgres, which is far easier for an LLM to introspect and reason about than Firestore's NoSQL document model or a bespoke security-rules DSL. That structural advantage, combined with Supabase shipping a first-party MCP server earlier than most backend platforms, has made it one of the most cited stacks for agentic and \"vibe-coded\" app development. Claude Code adds terminal-level Bash and filesystem access on top, so it can pair MCP-driven database operations with local actions — editing a Next.js data-fetching layer, running supabase db diff, or writing migration files straight into supabase/migrations/. For teams evaluating backend platforms for Claude for GraphQL API Development-style projects, this Postgres-first, agent-friendly design is the deciding factor over Firebase in most 2026 comparisons.\n\n## Setting Up the Supabase MCP Server\n\nThe server runs via npx @supabase/mcp-server-supabase and is registered with Claude Code using claude mcp add or an .mcp.json config entry, depending on the client. Authentication uses a Supabase Personal Access Token (PAT), which can be scoped per-organization or per-project — project-scoping is the safer default. Two flags matter most for production use: --read-only, which blocks the agent from executing writes, and --project-ref, which limits the agent's reach to a single project rather than an entire org. A third option, --features=database,docs,debugging, lets teams enable only the tool groups they need, reducing tool-overload and the chance the model picks the wrong tool among dozens of similarly named ones. Most teams start read-only, verify the workflow, then selectively enable write access per project.\n\n## MCP-First vs. CLI-First Development Patterns\n\nThere are two common architectures for Claude Code and Supabase, and the choice affects how much human review happens before code touches a database.\n\n| Approach | How it works | Best for |\n|---|---|---|\n| MCP-first | Natural language drives schema queries, SQL, and migrations directly through MCP tools | Prototyping, exploration, solo founders moving fast |\n| CLI-first | Claude edits declarative schema files in supabase/schemas/*.sql; supabase db diff generates migrations for PR review | Teams wanting version-controlled, reviewable migrations |\n| Manual dashboard | Developer copies SQL from Claude Code into the Supabase SQL Editor | Highest caution, lowest speed, used for one-off destructive changes |\n\nCLI-first is increasingly preferred by teams with existing CI/CD, since generated migrations land in version control and get reviewed like any other pull request before reaching production — a pattern also common in Claude for DevOps Kubernetes and Terraform workflows.\n\n## Workflow 1: Scaffolding a Full Backend from a Feature Description\n\nA common 2026 use case is describing a feature in plain language — \"add a comments table with RLS so only the author can edit their own comment\" — and having Claude Code generate the schema, Row Level Security policies, and Supabase Auth wiring in one session. Because PostgREST auto-generates REST endpoints from the schema, there is no separate API layer to hand-write; the agent's job is largely correct schema and policy design rather than boilerplate CRUD code. This is the workflow most cited by solo founders and indie hackers using Supabase to ship an MVP backend in a single sitting, and it pairs well with Claude Code's ability to also write the frontend queries against the new tables in the same pass.\n\n## Workflow 2: Migrating from Firebase to Supabase\n\nTeams moving off Firestore use Claude Code to translate document-based data models and Firebase Security Rules into normalized Postgres tables with equivalent RLS policies, and to convert Cloud Functions into Supabase Edge Functions. This is a heavier lift than greenfield scaffolding because Firestore's flexible document shape rarely maps one-to-one onto relational tables, so the agent typically needs several iterations reviewing sample documents before proposing a schema. The MCP server's ability to inspect the target Supabase project's existing tables in the same session — rather than working from a static schema dump — is what makes Claude Code notably faster at this than manually writing a migration script.\n\n## Workflow 3: Debugging RLS Policies with Advisor and Logs\n\nSupabase's MCP server exposes Postgres, API, and Auth logs plus the Advisor tool, which flags security and performance issues such as missing indexes or overly permissive RLS policies. Instead of switching to the dashboard mid-session, Claude Code can pull logs and Advisor output directly, correlate a failing request with the specific policy blocking it, and propose a fix. A frequent point of confusion here: operations run through MCP or the CLI often use elevated (service role) credentials that bypass RLS entirely, so a query that "works" in an agent session may still fail for a real anon-key client. Testing fixes with an anon-scoped client, not just the admin connection, is the standard safeguard.\n\n## Workflow 4: Safe Schema Changes Using Branching\n\nSupabase's branching feature (a Pro-plan capability) creates an ephemeral copy of a project for testing schema changes before they touch production — directly comparable to Neon's branching model. Claude Code can create a branch via MCP, apply and test a migration against it, and only merge to production once the change is verified. Combined with supabase start for a fully local Docker-based stack, this gives two layers of isolation between an agent's SQL and a live database, which is the primary mitigation teams cite when asked whether it's safe to let an agent run migrations.\n\n## Workflow 5: Building RAG Applications with pgvector\n\nSupabase's built-in pgvector support makes it a frequent pairing for retrieval-augmented generation apps. Claude Code can scaffold the vector column, an embedding ingestion pipeline, and a similarity-search RPC function in one flow, then wire the frontend query against it. This workflow benefits particularly from the CLI-first pattern, since vector index configuration (list vs. HNSW, dimension counts) is easy to get wrong and worth reviewing in a migration file rather than applying live. Teams building agent tooling on top of this stack often reference patterns from Best MCP Servers for Claude in 2026 when deciding which additional MCP servers to combine with Supabase's.\n\n## Security Practices That Matter Most\n\nThe dominant risk in Claude Code plus Supabase workflows is an agent executing unreviewed destructive SQL against production. The standard mitigations, in order of adoption: use a read-only PAT for exploration and switch to write access only when actively migrating; scope tokens to a single project rather than an org; require migration files for human review instead of direct DDL execution against prod; and use branching or local supabase start for anything schema-changing. A second, less obvious risk is prompt injection through untrusted database content — since MCP tools let the model read arbitrary table rows and act on what it finds, malicious user-submitted text stored in a table could attempt to influence the agent's next action. Scoping tool permissions tightly and avoiding auto-approval of write actions addresses both risks simultaneously. Teams codifying these rules often add them directly to a project's CLAUDE.md file, as described in Claude Code Permissions and Security.\n\n## Frequently Asked Questions\n\n### Is it safe to let Claude Code run SQL directly against a production Supabase database?\n\nOnly with safeguards: use a read-only or project-scoped Personal Access Token by default, test schema changes on a Supabase branch or local supabase start instance first, and require the agent to generate a reviewable migration file rather than executing DDL directly against production.\n\n### Does Claude Code bypass Row Level Security when using the Supabase MCP server?\n\nOften yes — MCP and CLI operations typically use elevated service-role credentials that bypass RLS, so queries can appear to work during development. Always test policies with an anon-key-scoped client to confirm real user requests are actually restricted as intended.\n\n### How does Claude Code with Supabase compare to using Claude Code with Firebase?\n\nSupabase's plain-Postgres schema and RLS model are easier for an LLM to introspect and reason about safely than Firestore's document model and separate security-rules DSL. Supabase's MCP and CLI tooling for agentic workflows are also generally further along as of 2026.\n\n### Should Claude Code use the Supabase MCP server or the Supabase CLI directly?\n\nMCP is faster for natural-language exploration and prototyping.