← Blog · Published Oct 18, 2026 · Updated Oct 31, 2026 · by the Vibefixr team

Supabase’s October 30 change is live: a 5-minute checklist for new tables

Supabase is changing a default that almost every AI-built app relies on without knowing it. If you build with Lovable, Bolt, Cursor or Replit on top of Supabase, the five questions below tell you in about five minutes, without touching code, whether you need to do anything. The change took effect on October 30, 2026.

Reviewing your setup anyway? Check your app now with the free Supabase key checker to see whether you still ship legacy keys, which Supabase is retiring by the end of 2026.

When it hits, it looks like this in the browser’s network tab:

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

What changed on October 30

Until now, every table created in the public schema automatically got select, insert, update and delete granted to the anon, authenticated and service_role roles. That’s why a new table showed up in your app the moment it existed. According to Supabase’s official changelog, those automatic grants are gone:

Now, a new table in public exists but isn’t reachable through the Data API (REST, GraphQL, supabase-js and the other client libraries) until someone grants access on purpose. Supabase’s reasoning is worth reading: agents and AI platforms now create tables without a human reviewing each change, and automatic grants made it easy to expose a table before anyone secured it.

Updated Oct 31, 2026: the change is live. Supabase’s schedule enforced the new behavior on all existing projects on October 30. We re-checked the official changelog today and the rules are the same as before: only new tables in public need an explicit GRANT, and existing tables keep their grants and keep working. New since our last check: Supabase’s 42501 troubleshooting guide notes that apps often show this error as a 401 or 403, so a new feature failing with “unauthorized” or “forbidden” can be the same missing grant.

Earlier update, Oct 23, 2026: Supabase sends its final notice email to owners and admins of active projects today, one week before the change. We re-checked the official changelog this morning and nothing has changed: from October 30, only new tables in public need an explicit GRANT, and existing tables keep their grants and keep working.

Who doesn’t need to do anything

The 5-minute checklist (no code)

1. Does your app talk to Supabase from the browser?

Lovable, Bolt and most AI-built apps use supabase-js in the frontend, which goes through the Data API. If yours does, read on. If everything goes through your own server over a direct database connection, you’re in the “nothing changes” group above.

2. Will you add features in the coming weeks?

The risk sits in new tables. A new feature like “saved searches”, “teams” or “subscriptions” usually means a new table. If you keep building, assume you’ll meet this.

3. Has Supabase emailed you, or does the Security Advisor show warnings?

Supabase says it emails owners and admins of every active project: a five-week notice went out on September 23 and a final notice went out on October 23. The Table Editor shows a Data API exposure badge per table, and the Security Advisor in your Supabase dashboard lists tables worth reviewing. Just look. A warning there doesn’t mean anything is broken.

4. Does your AI tool write the database changes for you?

If Lovable, Bolt, Cursor or Replit creates tables for you, the migrations it has been writing probably have no grant in them, because until now they never needed one. Now the migration still succeeds and the UI still gets built, but the new feature can’t read its own table.

5. Do you know which tables signed-out visitors can read?

If you can’t answer this, that’s the bigger risk. With the old defaults, every table was reachable by the public anon role, and only RLS stood between visitors and your data. See is your Lovable app leaking data? for how to tell.

Scoring: “yes” to 1, 2 and 4 means your next feature will most likely hit 42501. A “no idea” on 5 is worth fixing whatever the date.

Not sure which of these is your problem? The free health check looks at your live app in seconds, or request a free scan and we’ll tell you what we find.

What it looks like when it hits

• The newest feature shows nothing, a spinner, or an error toast. Older features work fine.
• Your app may report it as a 401 or 403 instead of 42501. Supabase’s troubleshooting guide says clients often surface it that way.
• In DevTools → Network, requests to /rest/v1/your_new_table fail with 42501 permission denied for table ….
• The hint field names the role that’s missing a privilege.

If the new feature shows an empty list with no error, that’s probably not this change. It’s usually RLS: see Supabase returns an empty array.

Grants vs. RLS in one minute

Postgres checks two locks before your app touches a row:

1. Grant: may this role use this table at all? If not, you get 42501 before RLS is even consulted.
2. RLS policy: which rows may this role see or change? If none match, a read returns an empty array.

Supabase recommends treating three steps as one unit whenever a table is created: grant only the privileges each role needs, enable RLS, and add policies. A grant is one line, for example:

grant select on public.your_table to authenticated;

To see which roles already have access to a table, run this in the SQL Editor (from Supabase’s 42501 guide):

select grantee, privilege_type
from information_schema.role_table_grants
where table_name = 'your_table';

The hard part isn’t the syntax. It’s deciding, table by table, which role gets which privilege. If signed-out visitors should never see a table, anon shouldn’t get a grant on it at all.

Why “just give it access” is dangerous

When the error appears, the quickest suggestion from an AI assistant (or a forum) is usually to grant everything to everyone, or to switch to the service_role key. Both make the error disappear, and both can make private data public. A blanket grant to anon on a table with weak RLS is the classic leak. The secret key skips RLS entirely, which is why it must never be in a frontend (see leaked service_role key).

The changelog also shows the SQL to restore the old defaults on a project, plus a bulk grant for tables created since. It’s a blunt tool: it exposes every new table in public to anon again, so only use it if you know your RLS policies are solid. Checking which tables need which grant is part of the $49 Audit.

Get checked before your next feature ships

If you’d rather not spend an evening reading migrations, we’ll check every table, grant and RLS policy and tell you in plain English what will break and what’s exposed. If something has already broken, the Fix covers it end to end.

FAQ

Related guides

• Is your Lovable app leaking user data? How to tell if your Supabase RLS is broken
• Supabase returns an empty array but the table has data? It’s usually RLS
• Leaked your Supabase service_role key in a vibe-coded app? What to do now
• Stripe says “paid”, your app says “free”: why the feature didn’t unlock

Launching soon? Run through our launch checklist for AI-built apps: 14 checks, each linked to the full guide.

Sources: Supabase changelog: tables not exposed automatically · Supabase CLI: auto_expose_new_tables default change · Supabase Knowledge Base: Database API 42501 errors

Information here is checked against official docs at the time of writing. Platforms change, so verify against the linked sources.