supabase

Combine the TO authenticated clause with an ownership predicate in USING, such as auth.uid() = user_id, and add WITH CHECK for UPDATE policies. Avoid the deprecated auth.role() function and never rely on user-editable user_metadata for authorization.

Iterate on schema changes using execute_sql or supabase db query, then run supabase db advisors, generate the migration with supabase db pull <name> --local --yes, and verify with supabase migration list --local. Avoid apply_migration for iterative work.

Newly created tables may not be automatically exposed through the Data API depending on project settings. Check the Data API settings and explicitly GRANT access to the anon and authenticated roles, then enable RLS on the table.

In Postgres RLS, an UPDATE requires a matching SELECT policy first; without it, updates silently return zero rows with no error. Add a SELECT policy and ensure the UPDATE policy includes both USING and WITH CHECK clauses.

No. SECURITY DEFINER functions bypass RLS and run with creator privileges, silently removing access control. Prefer SECURITY INVOKER, and if SECURITY DEFINER is truly required, keep the function in a non-exposed schema with an auth.uid() check.

First check reachability with curl to https://mcp.supabase.com/mcp (a 401 means it is up), then verify your .mcp.json configuration, and finally complete the OAuth 2.1 authentication flow in your agent and reload the session.