permission denied for table (42501): Supabase new tables after Oct 30, 2026

Exact error
{"code":"42501","message":"permission denied for table your_table"}
Also appears as (2)
  • permission denied for table <name>
  • Grant the required privileges to the current role with: GRANT SELECT ON public.your_table TO anon;
As reported (not yet reproduced) CI: pending

Built only from official docs and public reports, linked under Sources. We have not reproduced it yet. How we verify.

Last verified
Not yet (as reported)
Published
Repro
None yet
Fix ID
APP-32
Environment and versions
reported onSupabase Data API (PostgREST / supabase-js), all existing projects from Oct 30, 2026; new projects since May 30, 2026
tested by usnot yet reproduced

In brief

Since Oct 30, 2026, new Supabase tables are not exposed to the Data API until you grant access. The full fix gives least-privilege grant, RLS and policy SQL for each role, and the shortcut to avoid.

Get the full fix ↓

As reported, not yet reproduced. This error comes from a platform change Supabase announced and enforced on Oct 30, 2026. We haven't run it against a real Supabase project yet (we need a test project first). This page is based on Supabase's official changelog, linked under Sources.

Symptom

Your app, or your AI builder (Lovable, Bolt, Cursor, an agent with the Supabase MCP), creates a new table. Existing tables still work, but every supabase-js call to the new table fails with:

{
  "code": "42501",
  "message": "permission denied for table your_table",
  "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.your_table TO anon;"
}

Why it happens

  • Supabase changed a default. Before, every table created in the public schema was automatically granted select, insert, update and delete for the anon, authenticated and service_role roles, so it was reachable through the Data API right away.
  • Now new tables need an explicit GRANT. Per the changelog, this became the default for new projects on May 30, 2026, and is applied to all existing projects on Oct 30, 2026.
  • Existing tables are not affected. They keep their current grants.
  • Grants are not RLS. Grants decide whether a role can touch the table at all; RLS decides which rows. If the grant is missing, Postgres rejects the query before RLS runs.
  • Direct Postgres connections are unaffected (psql, an ORM, or a server using a connection string). This hits apps that use the Data API: supabase-js, the client libraries, /rest/v1/ or /graphql/v1.

What we could not test

  • A real Supabase project after the Oct 30 enforcement.
  • How each AI builder (Lovable, Bolt, Cursor agents) writes its table migrations today. We have not checked whether they already include grants.

The full fix

$4

The free part of this page tells you what's wrong. The full fix tells you exactly what to do. It includes:

  • Step-by-step fix, safest option first (the full page is 610 words)
  • 2 copy-paste blocks of commands, config or code
  • How to check it worked
  • What the official docs say, with every claim linked (not yet reproduced by us)

Launching soon. Checkout isn't open yet; prices may change at launch. Join the waitlist. You can check what you'll get: SHA-256 of the full fix e9e04207c3cd52d1… (how to check).

Sources

  1. Supabase changelog 45329: Breaking change, tables not exposed to Data and GraphQL API automatically
  2. Supabase docs: Securing your API

How this page was made

Drafted by an AI agent from the official docs and public reports listed above. Not yet reproduced on our test machine. Human review: not yet. No warranty: try fixes on a copy or staging environment first. Machine-readable versions: Markdown · JSON.

Found a mistake or a newer version where this breaks? Tell us.