"Permission denied for table"? Here's the safe fix.

Updated 26 October 2026 · Postlaunch

What changed

Supabase used to grant select, insert, update and delete on every new table in public to the anon, authenticated and service_role roles automatically. That became opt-out for new projects in May 2026, and on 30 October 2026 it applies to existing projects too. Row-Level Security behaves the same as before, and direct Postgres connections aren't affected.

How you'll notice

• A feature your AI builder just added shows an error or an empty list.
• The browser console or API response shows code 42501 and "permission denied for table …", often with a hint naming the missing GRANT.
• Older features keep working, which makes it look random.

The tempting fix is the dangerous one

The fastest way to make the error disappear is to grant every privilege to every role, including anon. That makes the table reachable by anyone holding your public key. If RLS is off or a policy says USING (true), that's a data leak.

The safe fix

For each new table, in the same migration that creates it:

-- signed-in users (most app tables)
grant select, insert, update, delete on public.your_table to authenticated;
-- only if logged-out visitors genuinely need to read it
-- grant select on public.your_table to anon;
grant select, insert, update, delete on public.your_table to service_role;

alter table public.your_table enable row level security;
-- then add policies that limit each user to their own (or their team's) rows

Then tell your AI builder to include grants, RLS and policies whenever it creates a table, and check the result with our free leak check.

Want it done for you?

$290 Data lockdown · fixed price · 2 business days

Every table checked for missing or over-broad grants, Row-Level Security matched to who should see what, service key kept out of the browser, storage made private, and the whole thing tested as two customers and an anonymous visitor. If we can't fix it, you don't pay.

Questions

Why do I get "permission denied for table" on a table my AI builder just created?

Since 30 October 2026, new tables in existing Supabase projects are no longer exposed to the Data API automatically. Each new table needs explicit GRANT statements for the anon, authenticated and service_role roles before supabase-js can reach it.

Are my existing tables affected?

No. Supabase says existing tables keep their current grants and stay reachable. Only tables created after the change need explicit grants.

Is it safe to grant everything to anon to make the error go away?

No. Granting to anon exposes the table to every visitor holding your public key, and without Row-Level Security that means anyone can read or change it. Grant only what each role needs and enable RLS with real policies.

Can you fix it for me?

Yes. Our Data lockdown is $290 at a fixed price: grants and Row-Level Security on every table, keys and storage checked, tested as two customers and a visitor.

Source: Supabase announcement and discussion