Supabase's October 30 change: why new tables may stop showing up in your app

From Oct 30, 2026, new Supabase tables stay hidden from your app until you allow access. What changes, who it hits, and prompts to fix it.

If your Lovable, Bolt, or Cursor app keeps its data in Supabase, there's a change coming on October 30, 2026 that's worth five minutes of your time. Nothing you've already built goes away. But the next time you (or your builder tool) add a new table, that table may not work in your app until you take one extra step.

Here's what's happening, in plain English.

First, two words you'll need

Table: one "spreadsheet" inside your database, like users, orders, or bookings. Every time you ask your builder tool for a new kind of data, it usually creates a new table.
Data API: the door your app uses to read and save data in Supabase. If your app uses Supabase's own code library (called supabase-js), it goes through this door. Most apps built with Lovable or Bolt talk to Supabase from the browser this way.

What's changing

Until now, every new table in the main part of your database (Supabase calls it the public schema) could be reached through the Data API the moment it was created.

After the change, a new table starts out closed. It exists, but your app can't reach it until someone explicitly gives access. Supabase calls that a grant: a one-line permission that says, for example, "signed-in users may read and save rows in this table."

In Supabase's words: "new tables you create in public schema require an explicit opt-in (via a Postgres grant) before the Data API can see them."

Supabase is doing this for safety. Under the old rule, a table could be open to the world before anyone had locked it. As they put it, it was "easy to accidentally expose new tables before you've secured them," especially now that AI coding tools create tables without a human reviewing each one.

When

Supabase lists these dates:

April 28, 2026: new projects could choose the new behavior when they were created.
May 30, 2026: it started becoming the default for all new projects, rolled out gradually over a few weeks.
October 30, 2026: the new behavior is applied to all existing projects.

So if you created your Supabase project in the last few months, you may already have it. If your project is older, it arrives on October 30.

Supabase also says it emails the owners and admins of every active project. A five-week notice went out on September 23, and a final notice is planned for October 23. Check your inbox (and spam) for mail from Supabase.

Who it affects

You need to pay attention if your app reads or saves data through Supabase's Data API, which includes anything using supabase-js, and you'll add new tables after the change reaches your project.

The good news, straight from Supabase:

Tables you already have are not affected. They "keep their current grants and stay reachable." Your app should keep working as it is today.
Your login system, file storage, and live updates aren't touched. The change is only about the public part of the database. Supabase's auth, storage, and realtime areas keep their current settings.
Row Level Security works the same as before. (Row Level Security, or RLS, is the lock that decides which rows each person can see, like "users see only their own orders." Here's our guide to it.)
If your app only talks to the database through a direct connection from a server, rather than the Data API, Supabase says you're not affected at all.

Supabase points out the catch: a project with no problems today "still breaks the first time someone adds a new one" after October 30.

What it looks like when it bites

Say you ask Lovable for a new "reviews" feature in November. It creates a reviews table, builds the page, and everything looks done. But your app has no permission to use the new table, so the part of your app that depends on it can't load or save that data.

Behind the scenes, Supabase sends back a clear error rather than failing silently. It looks like this:

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

If you see "permission denied for table" anywhere (an error message on screen, your builder tool's error panel, or your browser's developer console), this change is the likely cause.

Who is "anon" and "authenticated"?

Supabase gives access to three kinds of visitors, called roles:

anon: people who aren't signed in.
authenticated: people who are signed in to your app.
service_role: your own server code. It skips the locks, so it never belongs in the browser.

A grant says which of these can do what with a table. Usually signed-in users need more access than signed-out visitors, and many tables shouldn't be open to signed-out visitors at all.

What to do

Supabase says to treat these three steps as one unit every time a new table is created:

Grant the access each role needs.
Turn on Row Level Security.
Add policies (the rules for who sees which rows).

The grant opens the door. RLS and policies decide what each person can see once they're inside. If the grant is missing, Supabase rejects the request before RLS even comes into play. If you only do the grant and skip the rest, you may open the table wider than you meant to.

You don't have to write any of this yourself. Give your builder tool the instructions below.

Prompt 1: make it a standing rule

Paste this into the place where your tool keeps instructions for every chat (in Lovable that's the project's Knowledge; in Cursor it's a Rule), or at the start of any chat where you add features:

Supabase no longer gives new tables in the public schema access automatically. From now on, every time you create a new table in the public schema, in the same migration:
1. Add explicit GRANT statements for only the access each role needs (anon, authenticated, service_role). Do not grant anything to anon unless I say signed-out visitors should use this table.
2. Turn on Row Level Security for the table.
3. Add policies so users can only read and change their own rows, unless I say otherwise.
Tell me which grants and policies you added, in plain English.

Prompt 2: fix a feature that's already broken

If something you added recently won't load or save, paste this:

Part of my app isn't loading or saving data, and I think it's Supabase's change where new tables need explicit grants. Check the browser console and Supabase responses for "permission denied for table" errors. For each affected table, add a migration with only the GRANT statements the app actually needs (separately for anon and authenticated), and make sure Row Level Security is on with policies so users can only see their own rows. Don't grant access to every table at once, and don't use the service role key in the browser. Then tell me what you changed.

Supabase also notes that coding tools can often fix themselves from the error's hint, and that it offers an official Supabase "agent skill" for AI coding tools that includes the grant step. If you use Cursor, it's worth asking it to set that up.

How to check

Read Supabase's emails. The final notice is scheduled for October 23.
Open the Security Advisor. In your Supabase project, click Advisors, then Security Advisor. Supabase says that until October 30 it flags the tables affected by this change and shows the fix.
Look at the Table Editor. Supabase added a badge there that shows whether each table can be reached through the Data API.
Test every new feature like a stranger. After adding anything that saves new kinds of data, try it while signed in, and again in a private window while signed out. Make sure it loads and saves when it should, and stays hidden when it shouldn't.

The short version

On October 30, 2026, Supabase applies the change to all existing projects. Newer projects may already have it.
Tables you already have keep working.
New tables in public stay closed to your app until they get a grant.
Every new table needs three things: a grant, Row Level Security, and policies.
The giveaway error is "permission denied for table".

Source: Supabase's announcement of the change.

Want to know what else your app is showing strangers before launch? Throttle Bird has a free scan, with paid reports for deeper fixes.