BuiltSafely

Home/Fixes

Supabase

42501 permission denied for table

The table has no GRANT for your role. Add the grant, keep RLS on, and add policies.

  • Reviewed Oct 2026
  • 4 official sources
Sources Last checked October 16, 2026 · Sources: official docs (linked below) · Educational, not an audit

The fix

Grant the role the privilege it's missing, in a migration, and keep RLS on. The error's hint tells you which role and privilege it needs:

-- Signed-in users manage their own notes; signed-out visitors get nothing
grant select, insert, update, delete on table public.notes to authenticated;
alter table public.notes enable row level security;
-- ...plus one policy per operation (see our RLS guide)

Only grant to anon for data that's meant to be public.

Tested October 16, 2026 against a throwaway local Supabase Postgres 17 container (no real project). Without a grant, a signed-out read failed with 42501: permission denied for table notes and the hint "Grant the required privileges to the current role with: GRANT SELECT ON public.notes TO anon;". A public table with grant select ... to anon, RLS on and a read-only policy returned its rows to anon.

Why it happens

Postgres checks grants before policies. Supabase's RLS guide says a missing grant "raises a 42501 error before any policy runs", so check grants before you change policies (Supabase: RLS). To see a table's grants (Supabase: 42501 errors):

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

Tested on the same container. It listed the roles and privileges for the table.

Why you may see it more from October 30, 2026: Supabase is applying a change to all existing projects. After it, new tables in public need an explicit grant before the Data API can reach them. Existing tables keep their grants (Supabase changelog). Our Oct 30 grants guide covers this in detail.

Not every 42501 is a missing grant. Supabase lists other causes, including restricted schemas, column-level restrictions and RLS blocking an insert or update (Supabase: 42501 errors). If the message says "new row violates row-level security policy", see our RLS error fix.

What not to do

Don't disable RLS, don't grant everything to anon without policies, and don't move the secret or service_role key into the frontend (Supabase: API keys).

Your turn

Did this error appear after a migration, a new table or an AI-generated change? Tell us. We're tracking which ones trip people up most.

This guide is educational and based on the vendor's public docs as of the review date. Platforms change: check the linked sources. Not a security audit. Disclaimer.

The BuiltSafely weekly

One email a week. What changed, and the one fix that matters.

Platform changes that affect the security of AI-built apps, checked against official docs. Free. Unsubscribe any time.