← All guides

Supabase "permission denied for table" (42501) on a new table: the October 30, 2026 change and the fix

From October 30, 2026, new tables in public are no longer exposed to the Supabase Data API automatically. If a Lovable or Bolt app breaks on a new table, add explicit grants, keep RLS on, and add policies.

On October 30, 2026 Supabase applies a new default to all existing projects: tables you create in the public schema from then on are no longer reachable through the Data API (supabase-js, REST and GraphQL) until you grant access explicitly. Tables you already have keep their current grants and keep working. Apps that talk to Postgres over a direct connection string are not affected.

What it looks like

Your app worked yesterday, you (or Lovable, Bolt or another AI tool) added a new table, and now that feature shows empty data or fails. The browser Network tab shows a 401 or 403 from /rest/v1/your_table with this body:

{
  "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;"
}

Step 1: check which roles can reach the table

In the Supabase SQL Editor:

select grantee, privilege_type
from information_schema.role_table_grants
where table_name = 'your_table';

Step 2: grant only what each role needs

Most apps only need logged-in users to read and write. Grant per table, not to every table at once:

grant select, insert, update, delete on table public.your_table to authenticated;

Only grant to anon if logged-out visitors really need the data, and then usually select only.

Step 3: keep RLS on and add policies

Grants decide whether a role can touch the table at all. Row Level Security decides which rows it sees. Granting without RLS exposes the whole table to anyone holding your public key:

alter table public.your_table enable row level security;

create policy "own rows" on public.your_table
  for all to authenticated
  using (auth.uid() = user_id)
  with check (auth.uid() = user_id);

Step 4: put the grants in your migrations

If an AI tool or CLI script creates tables for you, make sure every create table is followed by its grant, RLS and policy statements in the same migration. Otherwise the next new table breaks the same way.

Do not fix it by opening everything

Granting all privileges on all tables to anon makes the error go away and can expose your data. Older tables that were already too open stay that way after October 30, so this is a good moment to check them too.

Not sure? Let us check.

The $19 DeployFix Scan checks your RLS policies and finds leaked keys in your code, and you get a ranked report in plain English. If we find something, we can open a fix PR too.

Scan my app – $19

Sources