Supabase's October 30, 2026 Data API change: what breaks in Lovable, Bolt and Cursor apps

What exactly changes

Until now every table in the public schema was automatically granted select, insert, update, delete for three Postgres roles: anon (requests with the publishable/anon key), authenticated (signed-in users) and service_role (server-side key). That is why a table created by an AI tool was instantly reachable over the REST and GraphQL APIs — and why a table without Row Level Security was instantly readable by anyone holding the public key.

After the change, a new table is not reachable at all through the Data API until you grant access explicitly. This is a privilege-level default, and it is independent of RLS: grants decide whether a role can touch the table, RLS policies decide which rows it sees.

What breaks

• New tables created after October 30 by migrations, the SQL editor or an AI coding agent will return a permission error (Postgres code 42501, insufficient privilege) when your frontend queries them with the publishable key.
• Apps that create tables on the fly (setup scripts, multi-tenant table-per-customer patterns) need the grants added to the same script.
• Nothing breaks for existing tables. If your app worked on October 29 and you do not add tables, it keeps working.

The failure mode is safe — “permission denied” instead of “publicly readable” — but it looks like a bug to anyone who does not know about the change, and the quickest “fix” an AI assistant will suggest is a broad grant all. Do not accept that without RLS.

The correct pattern for a new table

Supabase documents three coordinated steps: grant the minimum privileges per role, enable RLS, and write policies.

-- 1. Grants: only what each role needs
grant select on public.notes to anon;            -- omit if anonymous users must not read
grant select, insert, update, delete on public.notes to authenticated;

-- 2. Row Level Security
alter table public.notes enable row level security;

-- 3. Policies: who sees which rows
create policy "owners read their notes" on public.notes
  for select to authenticated
  using ((select auth.uid()) = user_id);

create policy "owners write their notes" on public.notes
  for insert to authenticated
  with check ((select auth.uid()) = user_id);

Opt in today instead of waiting

You can switch an existing project to the new default now and test before the deadline:

alter default privileges for role postgres in schema public
  revoke select, insert, update, delete on tables from anon, authenticated, service_role;

Then create a scratch table and confirm your app gets a permission error until you add grants.

How to audit what is exposed right now

The change protects future tables, not the ones you already have. To find existing tables that are reachable and unprotected, list tables in public with RLS disabled:

select schemaname, tablename, rowsecurity
from pg_tables
where schemaname = 'public' and rowsecurity = false;

Every row in that result is readable and writable by anyone with your publishable key, because the old default granted access. Enable RLS and add policies, or revoke the grants, for each one. Supabase’s Security Advisor in the dashboard flags the same condition.

Why this matters for AI-built apps

The September 2026 UpGuard research that found 16,326 publicly readable Supabase databases traced the problem to tables created outside the dashboard without RLS — exactly what AI coding tools do when they generate SQL. The October 30 change closes that path for new tables. It does nothing for the tables that are already open.