Fix guides / Supabase: "42501 permission denied for table" (Oct 30 grants change)

How to fix Supabase "permission denied for table" (code 42501)

Your app worked, your AI builder added a new table, and now supabase-js returns code 42501, permission denied for table your_table. RLS policies look fine. The cause is a Supabase platform change: from October 30, 2026, new tables in the public schema are no longer exposed to the Data API automatically.

What changed

Until now, every table created in public was automatically granted select, insert, update and delete for the anon, authenticated and service_role roles. Supabase announced that this default is applied to all existing projects on October 30, 2026 (new projects have had it since a rollout that began May 30). See the official Supabase changelog entry.

• Existing tables keep their grants and keep working.
• New tables, however they are created (SQL editor, migration, Lovable, Bolt, an MCP agent), need an explicit grant before supabase-js can reach them.
• RLS is unchanged. Grants decide whether a role can touch the table at all. RLS decides which rows.
• If you only connect with a direct Postgres connection string (an ORM on a server), you are not affected.

How to recognise it

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

Compare: an empty list with no error usually means RLS is on but no policy matches. A 42501 means the grant is missing.

The safe fix: grant only what each role needs

Run this in the SQL editor for the new table, adjusting the privileges:

-- logged-in users can read and write (RLS still filters rows)
grant select, insert, update, delete on public.invoices to authenticated;

-- only if logged-out visitors must read it
grant select on public.invoices to anon;

-- server code using the service role key
grant select, insert, update, delete on public.invoices to service_role;

-- always keep RLS on for tables the browser can reach
alter table public.invoices enable row level security;

If the table uses an identity or serial column, inserts can also need grant usage, select on sequence public.invoices_id_seq to authenticated;.

The fix to avoid

Do not paste a bulk statement such as grant ... on all tables in schema public to anon, authenticated. It re-exposes every table, including any you deliberately locked down or ones with RLS turned off. And do not "fix" 42501 by disabling RLS: that makes the whole table readable by anyone with your public anon key.

Stop it recurring

Tell your AI builder: "Every time you create a table in public, add explicit GRANT statements for only the roles that need it, enable RLS, and add policies, all in the same migration." Supabase's Security Advisor also flags affected tables.

Check the fix

1. Reload the page that failed. The 42501 is gone.
2. Log out and confirm logged-out visitors cannot read anything they should not.

Last updated 2026-10-19.