Build and secure Supabase database applications

The Supabase skill guides work across Database, Auth, Edge Functions, Realtime, Storage, Vectors, Cron, and Queues, including client libraries and server-rendered applications. Its workflow checks relevant changelog entries and current product documentation before implementation because APIs, configuration fields, and CLI commands can change.

Verification matches the change: an appropriate local or test check, role-specific allowed and denied access cases, or the relevant application behavior. A SQL query does not verify every UI, authentication, or documentation change. When repeated attempts fail, inspect errors, documentation, and relevant logs, then change the approach instead of retrying indefinitely.

Use it for Supabase implementation, authentication or session issues, access policies, client integration, and schema changes. Confirm the actual project, environment, installed versions, and authorized scope before selecting commands or tools. Production mutations are not a substitute for an unavailable local verification step.

A service-role credential bypassing policy checks cannot prove that client row-level security works. Likewise, an HTTP 401 may establish endpoint reachability without establishing client authentication or usable MCP tools. Prefer read-only, project-scoped connector access when it satisfies the task.

Inputs include the product area, schema and migration history, Data API settings, user and ownership model, client framework, and installed CLI. Outputs can be scoped code or configuration, reviewed migration SQL, policy definitions, and verification evidence.

Table accessibility and row visibility are separate. Data API settings and explicit grants to anon or authenticated determine whether a table is accessible; RLS governs visible and writable rows. Enable RLS on tables in exposed schemas, including public by default, and create policies for the actual access model rather than applying the same ownership expression everywhere.

Schema work starts in an identified disposable local or test database. Create migration files through the CLI, inspect schema history, review any generated local diff, and recreate the authorized disposable database from migrations with synthetic fixtures. Reset destroys data, so verify its target. Inspect SQL, advisors, remaining findings, and rollback or forward-fix plans before separately authorized remote deployment. Direct remote DDL creates drift even when it avoids migration history.

Policy tests use synthetic users A and B: A can read and update A's row, B cannot, and neither can reassign ownership. Include the application's anonymous or guest behavior.

Client contexts include supabase-js, @supabase/ssr, supabase-py, Next.js, React, SvelteKit, Astro, and Remix. Pin package versions and commit lockfiles. Keep service_role and secret keys out of frontend code; publishable keys fit frontend access, while NEXT_PUBLIC_ variables reach the browser.

Authorization must not trust user-editable user_metadata. The app_metadata field is the appropriate authorization-data location, but JWT claims can remain stale until refresh. Deleting a user does not invalidate existing access tokens. Sensitive operations may require session revocation, appropriate expiry, and session_id validation against auth.sessions.

Views can bypass RLS. Postgres 15 and later support security_invoker views; older environments need revoked public access or an unexposed schema. UPDATE also requires a SELECT policy. Prefer role targeting with TO over deprecated auth.role(), but authenticated alone neither enforces ownership nor excludes anonymous sign-in users; verified is_anonymous claims distinguish guests when needed.

Write explicit USING and WITH CHECK predicates and review all permissive policies and column privileges. PostgreSQL can reuse USING for UPDATE/ALL checks, so omission alone does not imply ownership reassignment. SECURITY DEFINER runs with its owner's privileges and is not a permission-error shortcut. Where necessary, use an unexposed schema, least-privileged owner, safe search_path, explicit caller authorization, restricted EXECUTE grants, and advisor checks. New function EXECUTE privileges and schema exposure both need review. Storage upsert requires INSERT, SELECT, and UPDATE.

Discover CLI syntax through help. Version requirements include v2.79.0 for db query and v2.81.3 for db advisors, with execute_sql/psql and get_advisors fallbacks respectively. A version check is:

supabase --version

MCP troubleshooting checks reachability, actual client configuration, and OAuth 2.1 authentication followed by session reload. Documentation lookup prioritizes search_docs, then Markdown pages, then targeted search.

The skill serves developers maintaining Supabase applications and access boundaries. Skill feedback uses a separate permissioned public-issue process: draft the exact sanitized text, identify the problematic reference, remove private data, and obtain publication permission. Local-fix permission does not authorize public feedback. The upstream skill uses the MIT License.