Supabase October 30 Data API change: what changes and how to check your app

Until now, every new table in a Supabase project's public schema automatically got read and write privileges (select, insert, update, delete) for the anon, authenticated and service_role roles. That means a table was reachable from your app's frontend the moment it was created — even before anyone had protected it with RLS.

Supabase is turning that off. According to the official changelog (https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically), the rollout is:

• April 28, 2026: optional setting at project creation ("Automatically expose new tables" unchecked).
• May 30, 2026: the new behavior became the default for new projects (rolled out gradually).
• October 30, 2026: the new behavior is applied to all existing projects.

After the change, a new table exists but your app can't see it until you run a GRANT for the roles that need it. RLS works exactly as before — grants are a separate layer: grants decide whether a role can touch a table at all, RLS decides which rows it can see.

You need to pay attention if any of these is true:

• Your app reads or writes data with supabase-js or another Supabase client library, or calls /rest/v1/ or /graphql/v1 — this is how most apps built with Lovable, Bolt, v0 or similar tools talk to Supabase.
• Your migrations or setup scripts create tables in public without GRANT statements.
• Your AI coding tool, a CLI script or the Management API creates tables and expects them to work in the app right away.

You are not affected if:

• You only use tables that already exist today — they keep their current grants and stay reachable.
• Your app only talks to the database over a direct Postgres connection (an ORM or server using a connection string, psql).
• The tables are in the storage, auth, realtime or a custom schema — Supabase says those keep their current grants and defaults.

Adding rows or columns to an existing table does not remove its grants. Supabase says it emails owners and admins of active projects about this (including a final notice one week before), and the Security Advisor flags affected tables with the SQL to fix them.

If a grant is missing, the request fails with a clear error instead of silently returning nothing. In your browser console or your builder's logs it looks like this:

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

Typical symptom for a non-developer: you ask your AI builder for a new feature (say, a "bookings" table), it creates the table, and the new screen shows an error or stays empty while everything else still works.

1. Open the Supabase dashboard and run the Security Advisor (Database → Advisors). Fix what it flags; it shows the SQL to run.
2. In the Table Editor, look at the Data API exposure badge on each table to see which tables your app can reach.
3. For every table that is reachable, confirm RLS is enabled and that no policy allows everyone to read personal data (emails, phone numbers, orders, messages).
4. If you want to test before October 30, Supabase lets you opt in early on an existing project with the revoke statements in its changelog. Try it on a test or staging project first.

You can also paste your live URL into the free LeakyVibe scan above: from the outside and read-only, it checks whether Supabase tables are readable with your public anon key, plus leaked keys and missing headers.

Supabase recommends treating three steps as one unit every time a table is created: grant only what each role needs, enable RLS, and add policies. Their example:

-- 1. Grant the privileges the role needs
grant select on public.your_table to anon;
grant select, insert, update, delete on public.your_table to authenticated;
grant select, insert, update, delete on public.your_table to service_role;

-- 2. Enable RLS
alter table public.your_table enable row level security;

-- 3. Add the policies you need
create policy "users can read their own rows"
  on public.your_table
  for select
  to authenticated
  using (auth.uid() = user_id);

Only grant anon (logged-out visitors) access if the data is truly meant to be public. Don't "fix" the error by granting everything to everyone and skipping RLS — that brings back exactly the exposure this change is meant to prevent.

A prompt you can paste into Lovable, Bolt or Cursor:

Supabase no longer exposes new tables in the public schema to the Data API automatically. For every table you create or have created recently, write one migration that: (1) grants only the needed privileges — select for anon only if the data is meant to be public, select/insert/update/delete for authenticated, and all for service_role; (2) enables Row Level Security; (3) adds policies so users can only read and change their own rows (auth.uid() = user_id). Do not grant anon write access unless I ask for it. Never use the service_role key in frontend code. Show me the SQL and list every table you changed.

If something broke after opting in early, the changelog also documents a rollback. Prefer adding the right grants to the specific tables instead.

Supabase's stated reason is that AI tools, agents and scripts now create tables without a human reviewing each change, which makes it easy to expose a new table before it's secured. With explicit grants, nothing new is public by accident. But it doesn't protect tables you already have: those stay reachable, so they still need RLS and sensible policies.

• Security Advisor run and its findings fixed.
• Every reachable table has RLS on and no "allow everyone" policy on personal data.
• Your AI builder's instructions say: GRANT + enable RLS + policies for every new table.
• New features tested after October 30 (watch for 42501 errors).
• No service_role or other secret key in frontend code.

Official sources: Supabase changelog "Breaking Change: Tables not exposed to Data and GraphQL API automatically" (https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically) and the Supabase docs "Securing your API" (https://supabase.com/docs/guides/api/securing-your-api). LeakyVibe is a quick outside check, not a full security audit.