Supabase's 30 October 2026 change: why new tables break, and the fix

Updated 23 October 2026 · 6 min read

Short answer: From 30 October 2026, every existing Supabase project stops automatically giving your app access to new tables in the public schema. If your AI builder creates a table after that date without an explicit GRANT, your app gets error 42501 "permission denied". Existing tables keep working. The fix is one prompt, and it should come with Row Level Security.

What exactly is changing?

Until now, any table created in Supabase's public schema was automatically readable and writable by the anon, authenticated and service_role roles through the Data API, the layer supabase-js talks to. Supabase is making that opt-in. It became the default for new projects on 30 May 2026, and on 30 October 2026 it applies to all existing projects. (Supabase changelog)

Tables that already exist: unaffected. They keep their current grants.
New tables after the change: invisible to your app until you grant access.
Row Level Security: unchanged. Grants decide whether a role can touch a table at all; RLS decides which rows it sees. You still need both.
Direct Postgres connections (an ORM or server with a connection string): not affected.

Why vibe-coded apps are most likely to hit it

Lovable, Bolt and Cursor add features by writing a migration that creates a new table, then calling it from the browser with supabase-js. If that migration doesn't include a GRANT, the new feature quietly fails after 30 October with a 42501 error (your app may show it as a 401 or 403, or just an empty list). The AI may then "fix" it the dangerous way, by turning off RLS or adding a policy that lets everyone in.

How to tell if you're affected

Open your browser's developer tools on the broken page and look at the Network tab for a request to /rest/v1/ returning an error with code 42501.
Or open Supabase → Advisors → Security Advisor. Supabase says it flags affected tables ahead of the change.

The fix: paste this into your AI builder

My Supabase project no longer auto-exposes new tables to the Data API (the 30 October 2026 change). For every table my app reads or writes from the browser, write a migration that: 1) grants only the privileges each role needs, for example GRANT SELECT ON public.TABLE TO anon only if logged-out visitors must read it, and GRANT SELECT, INSERT, UPDATE, DELETE ON public.TABLE TO authenticated for signed-in features; 2) enables Row Level Security on the table; 3) adds policies so users can only access rows where user_id = auth.uid(). Do NOT disable RLS and do NOT add policies using (true) to fix errors. From now on, include these GRANT and RLS statements in every migration that creates a table. List each table with its grants and policies when done.

Don't fix it the wrong way

If your AI suggests ALTER TABLE ... DISABLE ROW LEVEL SECURITY, granting everything to anon, or a policy with using (true) on a table holding user data, stop. That makes the error go away by making the table public. Read Supabase RLS explained for the safe pattern.

Check your app in about 60 seconds

The free Vibe Check reads only public pages and gives you a fix prompt for each issue.

Run free Vibe Check

FAQ

Will my existing Supabase tables stop working on 30 October 2026?

No. Supabase says existing tables keep their current grants. Only tables created after the change on your project need an explicit GRANT.

What does Supabase error 42501 mean?

Permission denied: the role your app uses (anon or authenticated) has no privilege on that table. The error hint shows the GRANT statement needed.

Does granting access make my table public?

Granting lets the role reach the table; Row Level Security still decides which rows it can see. Always enable RLS with owner-only policies on user data.