Will Supabase's October 30 change break your app?

Short answer: Your existing tables will keep working. But starting October 30, 2026, any new table you (or your AI builder) create in the public schema won't be visible to your app until it's given permission with a Postgres GRANT. If your app adds a table after that date and you skip this step, that feature will fail with a "permission denied" error. It's an easy fix once you know about it.

Last checked: Oct 15, 2026 · Source: Supabase changelog: Breaking Change: Tables not exposed to Data and GraphQL API automatically

What's changing, in plain English

Until now, with Supabase's default settings, every new table in the public schema was automatically reachable through the Data API — the auto-generated REST and GraphQL layer that supabase-js uses. Supabase is switching that off by default:

• May 30, 2026: new Supabase projects started using the new behavior (rolled out gradually).
• October 30, 2026: it applies to all existing projects too.

After that, a new table exists in your database, but your app can't see it until you explicitly grant access.

What is NOT changing

• Tables you already have keep their current permissions and stay reachable.
• Row Level Security (RLS) works exactly the same. You still need RLS policies.
• Direct database connections (psql, an ORM like Prisma or Drizzle, or a server with a connection string) aren't affected.
• This is not a data leak or a security hole. It makes new tables more private by default. The risk is a broken feature, not exposed data.

Who should pay attention

You're most likely to notice if:

• You build with Lovable, Bolt, Cursor, v0 or another AI tool that creates tables for you.
• Your app talks to Supabase from the browser or mobile app using supabase-js.
• You plan to add features (and therefore tables) after October 30.

What the error looks like

If a grant is missing, the request fails with a clear error instead of silently returning nothing:

{
  "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;"
}

In your app this usually looks like a page that won't load data, a form that won't save, or an empty list.

The fix

Decide who should be able to use the table, then grant only that. For a table signed-in users read and write:

grant select, insert, update, delete on public.your_table to authenticated;
alter table public.your_table enable row level security;
-- then add RLS policies for which rows each user can see/change

If logged-out visitors need to read it (for example, a public list of products):

grant select on public.your_table to anon;

Your server-side code that uses the service_role key may need a grant too:

grant select, insert, update, delete on public.your_table to service_role;

Tip: grant the smallest set of permissions you need, and always pair a grant with RLS policies. The grant decides whether a role can touch the table; RLS decides which rows.

Using an AI builder? Paste this prompt

"From now on, whenever you create a new table in the Supabase public schema, also add the GRANT statements the app needs (only the roles and actions actually used), enable row level security, and add RLS policies. Show me the SQL before running it."

A 5-minute checklist before October 30

1. List the tables your app created recently and any you plan to add.
2. Add the GRANT lines to your migrations or setup SQL so new tables get them automatically.
3. Make sure every table has RLS enabled with policies.
4. After Oct 30, if a feature breaks, look for error 42501 in your browser console or logs.
5. Run a free Greenlight scan to check the basics (HTTPS, security headers, exposed keys). It's not a full security audit.

Run a free check →

FAQ

Greenlight is independent and not affiliated with or endorsed by Lovable, Bolt, Cursor or Supabase. This page is educational and not a security guarantee.