Supabase Oct 30, 2026 change

New tables stop showing data? We fix it.

From Oct 30, 2026, Supabase plans to stop opening new tables to your app automatically. Once that reaches your project, a new table needs one extra permission, or your app gets a “permission denied” (42501) error. Already seeing it, or about to add tables? We check your database, then fix it.

What’s changing

  • From Oct 30, 2026, as the change reaches your project, new tables in the public schema will need an explicit grant before your app can reach them through the Data API.
  • Without that grant, your app’s requests to the new table will return error 42501, “permission denied”.
  • Tables you already have keep their access. Row Level Security (RLS) doesn’t change, and direct Postgres connections aren’t affected.

Source: Supabase changelog: Tables not exposed to Data and GraphQL API automatically

Signs you’re hit

  • You (or your AI builder) added a new table after the change reached your project.
  • The page that uses that table is blank, or shows no data.
  • Your browser console or an error message says “permission denied for table” or 42501.

Not adding tables yet? Nothing changes for your existing tables. It’s worth knowing before your next new one.

What we do

  1. $49 Database Check. You run our read-only script in your SQL editor and send us the results with your security warnings list. No passwords, no keys, no login to your account. We change nothing.
  2. Your report. A person checks every table and storage bucket: who can see or change your data (Row Level Security and grants), in plain English. You get a red, yellow and green report with the order to fix things in.
  3. $149 Security Fix. If you want us to fix it, you invite us like a teammate. We fix what’s on our critical checklist (RLS, public storage, exposed keys) and keep RLS on with real policies. Adding missing grants for new tables isn’t on that checklist, so we agree it with you in writing before we start, and it isn’t covered by the 48-hour guarantee. A human engineer approves every change.
  4. You remove us. When we’re done, we send a checklist so you can remove our access.

Upgrade within 14 days and the $49 comes off your fix. Credit details.

Prices

Database Check

$49

Database Check $49: read-only, report within 24h of working access.

Security Fix · Fix & Deploy

$149 · $249

Security Fix $149 · Fix & Deploy $249: Within 48 hours of working access or a full refund.

The 48-hour guarantee covers only the critical checklist in our Refund Policy.

Each order covers one app and one Supabase project. It’s not a penetration test, a security guarantee or a compliance certification. Full terms are in our Refund Policy.

Not ready to pay? The free instant check reads only your public homepage, up to 10 of its script files, its security headers and any storage links. It doesn’t query your database, log in, or check grants or RLS, so it can’t spot this issue.

Questions

Do my old tables break?

No. Tables you already have keep their grants. The change is about new tables in the public schema.

Is this a Supabase bug?

No. It’s a planned change Supabase announced in its changelog. New tables need an explicit grant, so access is a choice you make per table.

Do you need my password?

No. For the $49 check, you run our read-only script and send us the results: no passwords, no keys, no login to your account. For a fix, you invite us like a teammate, not with your password, and keys stay out of chat.

Can I fix it myself?

Yes. Our free guide has the steps and the SQL: Seeing a permission denied (42501) error after Oct 30? Here’s the safe fix. A typical grant for signed-in users looks like this (replace your_table):

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

Keep RLS on with real policies, and avoid grant all ... to anon.