Supabase stops auto-exposing new tables from 30 October

Supabase is switching off automatic table exposure for every existing project on 30 October. Until now, creating a table in the public schema granted select, insert, update and delete access to the anon, authenticated and service_role roles by default, making it reachable straight away through the Data API, PostgREST and supabase-js. That became the default for new projects on 30 May; the October date extends it to projects already running.

From that date, a new table needs an explicit grant before the Data API can see it:

grant select on public.your_table to anon;
alter table public.your_table enable row level security;

Existing tables keep their current grants and are not touched by the change.

Why it matters: if your migrations create tables without a grant statement, new ones will start returning 42501: permission denied after 30 October. Supabase’s own advice is to pair the grant with a row-level security policy in the same migration, rather than just reinstating the old blanket access, since that was the gap this change closes.

The caveat: this only affects tables created from 30 October onward. Nothing already in production changes.