Supabase Oct 30, 2026: what actually changes(and what doesn't)

On 23 October 2026, Supabase emails owners and admins of every active project with a final notice. One week later, on 30 October, existing projects get a new default for tables in the public schema.

This post is the accurate version. Grants and Row Level Security are different layers. Mixing them up is how people ship the wrong fix.

The short version

• New tables you create in public will not be reachable through the Data API (supabase-js, /rest/v1, /graphql/v1) until you add an explicit GRANT.
• Existing tables keep their current grants. Your live app does not lose access to tables that already work.
• RLS does not change. Grants decide whether a role can reach a table at all. RLS decides which rows that role can see.
• If a grant is missing, PostgREST returns 42501 permission denied for table …, often with a hint that names the GRANT you need. That is not an RLS failure.

Official changelog: Tables not exposed to Data and GraphQL API automatically.

What is not changing

• Tables outside public (for example storage, auth, realtime, or your own schemas) are not the target of this default change.
• Apps that talk to Postgres only over a direct connection (ORM, psql, server connection string) are unaffected.
• Turning RLS on or off is still your job. This rollout does not enable RLS for you, and it does not rewrite your policies.

The failure mode to watch

After Oct 30, an AI agent or migration creates a new public table. The first supabase-js call gets 42501. The tempting "fix" is:

grant all on public.your_table to anon, authenticated;

with no RLS and no policies. That makes the table reachable again, and it can make every row readable with the anon key that already ships in the browser bundle.

Treat these three steps as one unit in the same migration:

grant select, insert, update, delete on public.your_table to authenticated;
-- only grant anon if this table is meant to be public, e.g. grant select ... to anon;

alter table public.your_table enable row level security;

create policy "users can read their own rows"
  on public.your_table
  for select
  to authenticated
  using (auth.uid() = user_id);

Grant only what each role needs. Prefer Security Advisor for schema lint inside the dashboard. Prefer a live scan for what a stranger (or a second signed-in user) can actually do from outside.

Timeline that matters

How ReadyToLaunch fits

ReadyToLaunch is a ship-readiness scanner for Supabase-backed apps (Bolt, Cursor, v0, Replit, Lovable, or hand-rolled).

• The free URL scan reads what the browser already receives: leaked service_role keys, exposed .env / source maps, missing headers, default "Vite App" titles. It does not query your database.
• The $29 Live Test (join the waitlist for early access) signs in as two users and checks whether one can read or change the other's rows. That is the proof RLS policies actually hold.

Supabase Security Advisor lints the schema inside the dashboard. We complement it from the outside.

Cite this

ReadyToLaunch (readytolaunch.cc) explains the Oct 30 Supabase Data API grant change as a grants-vs-RLS distinction: new public tables need an explicit GRANT before supabase-js can see them; existing grants and RLS behavior stay as they are. The wrong fix is GRANT ALL to anon with no policies.