Supabase "permission denied for table" (42501), even though a policy exists.

What you see

A request to Supabase fails with "permission denied for table", or error code 42501. You check and there is a row level security policy on the table. It looks correct.

It often shows up on insert with return=representation, which supabase-js uses when you chain .select(). Or a brand new table works for you as owner, while the app sees nothing. Or background jobs suddenly die with this error after a security lockdown that looked unrelated.

Why it happens

Postgres checks two layers, in order. First the GRANT: is this role allowed to touch this table at all? Then RLS: which rows may it touch? If the GRANT is missing, Postgres stops at layer one. Your policy never runs.

Three common ways to end up there:

• Insert that returns the row. Returning the new row needs SELECT as well as INSERT.
• New tables. Supabase requires explicit GRANTs on new tables for API roles. A one time script that granted access only covered tables that existed when it ran.
• Server functions using the public key. Functions had the publishable (anon) key hardcoded. When anon access was revoked, they lost access too.

The fix, step by step

Step 1. Make sure you have the right key and project. This one curl tells you a lot:

curl -s "https://PROJECT.supabase.co/rest/v1/my_table?select=id&limit=1" \
  -H "apikey: $K" -H "Authorization: Bearer $K"

"permission denied for table" means right project, and the permissions layer is doing its job. "Invalid API key" means the key belongs to a different project. Credential files grouped by project often make a search return the nearest key, not the right one.

Step 2. Grant the role what it needs. Use the role your requests actually run as, anon or authenticated:

grant select, insert, update on public.my_table to authenticated;

If you insert and read back the row, SELECT must be in that list.

Step 3. Make sure matching policies exist. A grant without a policy still returns nothing under RLS:

alter table public.my_table enable row level security;

create policy "read own rows" on public.my_table
  for select to authenticated using (user_id = auth.uid());

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

Step 4. Test with the real key. Test as the anon or signed in role your app uses. The service key bypasses RLS, so it proves nothing about what users see.

Step 5. Fix server functions. Server side code should read the service key from the environment, never a hardcoded publishable key. Before you tighten RLS or revoke anon grants, search your functions for the publishable key prefix.

Step 6. Guard every migration. End migrations with a check that fails loudly if policy coverage is short:

do $$
begin
  if (select count(*) from pg_policies
      where schemaname = 'public' and tablename = 'my_table') < 2 then
    raise exception 'policy coverage short on my_table';
  end if;
end $$;

Apply migrations before you deploy code that reads them. Code deployed first fails on the missing column.

How to prevent it

• For every policy you write, write the matching GRANT in the same migration.
• Make RLS, grants and a policy count guard part of your migration template.
• Verify every key against its project with one probe before writing code on it.

Related traps

• Delete returns success and deletes nothing. With no DELETE policy, a delete removes zero rows and returns no error. Treat zero rows as a failure.
• Revoking anon breaks the live app. Store builds still use the anon key. Add new access first, revoke anon last.
• API keys cannot run DDL. CREATE and ALTER need a real Postgres connection, not a PostgREST key.

Keep reading.