Supabase Oct 30: why new tables get 42501 (and how to fix grants + RLS)

#supabase #security #webdev #lovable

If you just created a table in Lovable, turned on RLS, wrote policies, and the app still returns permission denied for table, this is the one.

Starting October 30, 2026, existing Supabase projects stop auto-granting privileges on new tables in the public schema. The table is there. The policies are there. The Data API still cannot see it.

Source: Supabase changelog · Securing your API

What it looks like

The request fails with Postgres error 42501. PostgREST (the Data API behind supabase-js) sends something like:

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

Typical setup: a Lovable-created table, RLS enabled, policies that should allow the row, and it still fails. Old tables keep working. Only the new one fails.

The hint names the missing grant. It is not a recommendation to copy blindly. Read it, then grant only what that role should have.

Grants vs RLS

Postgres runs two checks, in order:

Grants decide whether a role can touch the table at all (SELECT, INSERT, UPDATE, DELETE).
Row Level Security decides which rows that role can see or change.

If the grant is missing, RLS never runs. That is why "I have policies" does not fix 42501.

Until now, a new table in public automatically received select/insert/update/delete for anon, authenticated, and service_role. RLS was the only gate. New projects already dropped that default. On October 30 it applies to every existing project too.

Existing tables keep their grants. Direct Postgres connections are not affected. This is a Data API change: REST, GraphQL, and the client libraries.

The fix

Put grants in the same migration as the table, RLS, and policies. Least privilege, not GRANT ALL.

alter table public.your_table enable row level security;

-- signed-in users: the operations your app actually uses
grant select, insert, update, delete on table public.your_table to authenticated;

-- server code / Edge Functions using the service_role key
grant select, insert, update, delete on table public.your_table to service_role;

-- only if signed-out visitors should read this table
-- grant select on table public.your_table to anon;

Leave anon with nothing unless the table is meant to be public. Skip GRANT ALL ON ALL TABLES IN SCHEMA public - that also opens tables where RLS was never turned on.

If you already see 42501, check who has what:

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

Tell Lovable to include grants

Paste this into project instructions / Knowledge before the next migration:

When you create or change a Supabase table, put all of this in the same migration: CREATE TABLE, ENABLE ROW LEVEL SECURITY, CREATE POLICY, GRANT to authenticated and service_role, and GRANT SELECT to anon only if signed-out users should read it. Do not use GRANT ALL. Do not skip grants because RLS is on.

Full checklist + FAQ

The longer version with the Lovable paste block, checklist, and FAQ lives here (canonical):

https://fixloop.dev/guides/supabase-oct-30-grants-change

I run FixLoop - we fix broken Lovable/Supabase apps for a fixed price. No fix, no pay.

DEV Community