FixLoop

Supabase stops auto-granting new tables on Oct 30

Guide · October 14, 2026

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 (April 28, 2026). Same model in the Securing your API docs.

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 (a permission error, often surfaced as 401 or 403).

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:

1. Grants decide whether a role can touch the table at all (SELECT, INSERT, UPDATE, DELETE).
2. 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, and delete for anon, authenticated, and service_role. RLS was the only gate. New projects already dropped that default (rollout from May 30, 2026). On October 30 it applies to every existing project too.

Existing tables keep their grants. Direct Postgres connections (psql, an ORM, a connection string) are not affected. Neither are storage, auth, realtime, or custom schemas. 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. A marketing posts table might get select to anon. A profiles or invoices table should not.

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';

Then add the smallest grant that matches the role in the error hint, with RLS still on.

Tell Lovable to include grants

Lovable (and a lot of other AI builders) learned the old default: create table, enable RLS, add policies, done. After Oct 30 that migration produces a table nobody can reach through the client.

Paste this into the project instructions, Knowledge, or the chat before it writes the next migration:

If Lovable already shipped a table that returns 42501, ask it for a follow-up SQL migration that only adds the grants. Then run that in the Supabase SQL editor (or let the migration apply) and retry the request.

Quick checklist

• Confirm the error is 42501 / permission denied for table, not an empty array from RLS.
• Read the PostgREST hint. Note the role (anon vs authenticated) and the privilege.
• Enable RLS on the table if it is not already on.
• Grant select, insert, update, delete to authenticated (or a tighter subset if the app only reads).
• Grant the same to service_role if Edge Functions or server code use the service role key.
• Grant select to anon only if that table is public.
• Put those GRANTs in the Lovable/Supabase migration so preview branches and db reset do not break later.
• Do not GRANT ALL on the whole schema.

Questions