Supabase Stops Auto-Exposing New Tables on Oct 30, 2026: What Breaks

On October 30, 2026 Supabase enforces a change on every project: new tables in the public schema are no longer exposed to the Data API automatically. Supabase listed it as a breaking change on May 1, 2026, made it the default for new projects on May 30, and set October 30 as the date it applies to projects created before that.

If your app was built with Lovable, Bolt, v0 or Cursor, this matters for a specific reason. Those tools create tables by running SQL migrations, and they assume the table is instantly readable through supabase.from('table'). After the cutoff, that assumption is wrong. The table exists in Postgres and is invisible to your frontend.

This post covers what the change does, what it does not do, why Supabase is making it, and the three checks to run on your project this week. It does not cover the GraphQL API beyond noting the same rule applies to it.

What the change actually does

The Supabase Data API is the REST layer (PostgREST) that supabase-js talks to. A table is only reachable through it if the table is exposed to the API and the calling role has been granted access. Until now, every new table in public was exposed by default.

The important row is the last one. This change does not turn on Row Level Security for you. It only stops a brand new table from being public before you have thought about it.

What breaks, and what it looks like

The failure does not look like a database error. It looks like a feature that quietly stopped working.

A typical sequence in a Lovable app after the cutoff:

1. You ask Lovable to add a "notes" feature. It writes a migration creating public.notes and a component that calls supabase.from('notes').select().
2. The migration runs. The table exists.
3. PostgREST does not know about the table, so the request returns a 404 with a message like Could not find the table 'public.notes' in the schema cache.
4. The generated component catches the error, renders an empty list, and Lovable's preview looks fine because there are no notes yet anyway.
5. You ship it. Nobody can save a note.

The fix is one setting per table (expose it to the Data API) plus the RLS policies you should have been writing anyway. The problem is knowing to look. AI tools will not, because their training data predates the change.

Why Supabase is doing this

Because of how AI-generated apps ship. Two scans from this year put numbers on it.

Symbiotic Security published a study on June 2, 2026 of web apps generated by vibe coding platforms (Lovable, v0, Bolt.new, Replit, Windsurf and others) using Supabase as the backend. Of 1,072 sites fully scanned, 1,046 (98%) had at least one vulnerability, 173 (16%) had a critical one, and the average site had 5.9 findings. One critical category, data deletion without authentication, was found on 172 sites.

SupaExplorer, in a scan discussed on Hacker News, crawled 20,052 launch URLs from five indie product directories and found 2,217 domains (11.04%) exposing Supabase credentials in a dangerous way: either the service_role key (which bypasses RLS) shipped in client code, or the public anon key pointed at tables with no RLS policies at all.

Both scans found the same root cause. Supabase's security model is "the anon key is public, RLS is the wall". A table that is exposed to the API with RLS off has no wall. Making exposure opt-in removes the default that made that mistake silent.

[Row Level Security (RLS)](https://supabase.com/docs/guides/database/postgres/row-level-security) is a Postgres feature that attaches a policy to a table so every query is filtered by who is asking. In Supabase it is the only thing standing between the public anon key and every row in an exposed table.

We have covered two specific RLS failures before: tenant leaks through Stripe webhook handlers and the offset pagination trap.

Three checks to run this week

You do not need to wait for October 30. The setting is already available on every project, and turning it on early means you find the broken migration in staging rather than in production.

1. List every table that is exposed today, and whether RLS is on

Run this in the SQL editor:

select
  c.relname as table_name,
  c.relrowsecurity as rls_enabled,
  (select count(*) from pg_policies p where p.tablename = c.relname and p.schemaname = 'public') as policy_count
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind = 'r'
order by rls_enabled, policy_count;

Any row with rls_enabled = false on a table your frontend reads is the finding. Any row with rls_enabled = true and policy_count = 0 is a table nobody can read, which is either intended or a bug.

2. Test what the anon role can see

Supabase added an RLS Tester to the dashboard as a feature preview on April 28, 2026. Enable it from your profile menu, pick the anon role, and run select * from <table> for each table from step 1. What comes back is what any visitor to your site can fetch with the key in your JavaScript bundle. If a policy reads using (true), the AI wrote it to make a feature work and you should treat that table as public.

3. Grep the frontend bundle for the wrong key

grep -rn "service_role\|sb_secret_" src/ .env* 2>/dev/null

Then open the deployed site, view source, and search for sb_secret_ and for the JWT that your service_role key starts with. The service key belongs in server code and in Vercel's environment variables only. If it is in the bundle, rotate it today from the dashboard, before fixing anything else.

After October 30

Once the setting is enforced, add one line to your migration checklist: after creating a table, expose it and write its policies in the same migration. In SQL that is a grant to the roles that need it plus alter table ... enable row level security plus the policies. If you use an AI tool to write migrations, put that requirement in its project rules file so it stops assuming the old default.

What we did not measure

We have not run our own scan of Supabase projects; the numbers above are Symbiotic Security's and SupaExplorer's, and their methods are described on the linked pages. We also have not tested whether the October 30 enforcement changes anything for tables in schemas other than public; the changelog entry only names public.

If you would rather have someone run the three checks and fix what they find, that is the first hour of our vibe-coded app audit.