Home / RLS / Oct 30 grants change

Supabase RLS · Platform change

Supabase's Oct 30 grants change: what breaks, and the fix that leaks

01 What changes on October 30

Until now, every table created in public got full privileges (select / insert / update / delete and more) granted to anon, authenticated and service_role automatically, through default privileges. On October 30, 2026 Supabase turns that off for all existing projects (new projects have had it off since a gradual rollout that started May 30). From then on:

Direct Postgres connections (psql, an ORM, a server with a connection string) aren't affected. Source: Supabase's official announcement.

02 What "broken" looks like

The first new table after the cutover returns this from the API instead of rows:

response (example from Supabase's announcement)

{
  "code": "42501",
  "message": "permission denied for table invoices",
  "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.invoices TO anon;"
}

Postgres rejects the query before RLS even runs. That's the new default working as intended, not a bug in your policies.

03 The fix that leaks

The fastest way to make that error go away is the bulk grant from the rollback section of the announcement:

don't paste this as a fix

grant select, insert, update, delete on all tables in schema public
  to anon, authenticated, service_role;

It works, and it also grants every table in public, including the ones you never meant to expose. Any of those with RLS off becomes readable and writable by anyone holding your anon key, which ships in your frontend. The new default was your chance to stop exposing tables by accident; the bulk grant gives that back. Ask an AI coding tool to "fix the permission error" and this line is a likely answer.

Grant per table instead, and only what each role needs.

04 The migration pattern that works

Treat grant, RLS and policies as one unit, in the same migration, so a table never exists half-configured:

migration.sql

create table public.invoices (
  id         bigint generated always as identity primary key,
  user_id    uuid not null references auth.users(id),
  amount     numeric not null
);

alter table public.invoices enable row level security;

create policy "owner reads" on public.invoices for select to authenticated
  using (user_id = (select auth.uid()));

-- only the role and the operations the app actually uses
grant select on public.invoices to authenticated;

No grant to anon here, because signed-out visitors don't read invoices. If a table uses serial / bigserial instead of an identity column and the API inserts into it, the sequence needs its own grant: grant usage, select on sequence public.invoices_id_seq to authenticated;

05 Check what the API roles can reach today

Run this in the SQL editor. It lists every table and view in public, whether anon or authenticated can read it, and whether RLS is on:

check.sql

select c.relname,
       has_any_column_privilege('anon', c.oid, 'select')          as anon_can_read,
       has_any_column_privilege('authenticated', c.oid, 'select') as auth_can_read,
       c.relrowsecurity                                              as rls_on
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind in ('r', 'p', 'v', 'm')
order by 1;

A table with anon_can_read = true and rls_on = false can be read by anyone with your anon key. Two details make this stricter than the usual query built on information_schema.table_privileges:

06 Keep it from coming back

The new default only protects you while every migration stays honest. Two free checks help there:

FAQ