Fixes › Database / Supabase RLS

Supabase "permission denied for table" (42501) on a new table

LovableBoltCursorv0Replit

The error

{"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 no longer gives new tables in the public schema automatic Data API grants. Projects created since 30 May 2026 already work this way, and Supabase applies it to all existing projects on 30 October 2026. Tables you already have keep their grants, but any table your AI builder creates afterwards is invisible to supabase-js until a migration runs GRANT for anon, authenticated and/or service_role. The error comes before RLS policies are even checked, so adding policies alone won't fix it, and it also hits edge functions using the service role key.

How to fix it

1. Confirm it's a grant problem: in the SQL Editor run select grantee, privilege_type from information_schema.role_table_grants where table_name = 'your_table'; and check anon/authenticated/service_role are missing.
2. Grant only what each role needs, e.g. grant select, insert, update, delete on public.your_table to authenticated; and grant all on public.your_table to service_role;
3. Grant to anon only if logged-out visitors genuinely need to read that table.
4. Make sure RLS is enabled on the table and has policies, because a grant without RLS exposes every row.
5. If the table uses a serial/bigserial id, also grant usage on its sequence to every role that inserts.
6. Put the grants in the same migration that creates the table so future tables don't break the same way.

Fix prompt (paste into Lovable, Bolt, Cursor, Replit or v0)

Supabase returns 42501 'permission denied for table <TABLE>' since the change where new public tables no longer get automatic Data API grants. Write one idempotent SQL migration that: enables RLS on <TABLE>; grants only the privileges the app actually uses to authenticated (and to anon only if logged-out users must read it); grants all to service_role if edge functions or server code use it; grants sequence usage if the id is serial; and adds owner-scoped RLS policies using auth.uid(). Then update our table-creation migrations/template so every new table includes these grants. Don't disable RLS and don't grant anon write access.

FAQ

My old tables still work. Why only this one?

Only tables created after the change lose automatic grants; existing tables keep theirs.

I'm using the service role key and it still fails.

service_role needs a grant too. Without one, PostgREST denies it before RLS runs.

Is this the same as 'new row violates row-level security policy'?

No. That's also 42501 but means a policy blocked the row; a missing grant includes a GRANT hint.

Does this affect direct Postgres connections?

No, only the Data API (supabase-js, REST, GraphQL). ORMs over a connection string are unaffected.

Related fixes

• Supabase query returns an empty array (no error)
• new row violates row-level security policy for table
• Supabase Edge Function fails with CORS or 'Failed to send a request'
• Supabase Storage upload fails: new row violates row-level security policy (403)