Security · fixes ·

Supabase Data API changes on 30 Oct: what breaks in prod

As of 24 October 2026. Supabase's changelog gives 30 October 2026 for this change. In late August a Supabase CLI maintainer wrote (supabase/cli PR #6337) that the earlier default change "never landed" and hosted projects were still auto-granting, and the CLI dropped its own 30 Oct messaging. So the date may move: check what your own project does.

This guide pairs with Ship-Ready AI Rules, and if you want the next step, read Supabase “Permission Denied for Table”: the Data API Grants Change Scheduled for 30 Oct.

Supabase's changelog says: "On October 30, 2026 the setting will be applied it to all existing projects." After that, new tables you create in the public schema "require an explicit opt-in (via a Postgres grant) before the Data API can see them" (Supabase changelog 45329). The catch: your local stack may still expose new tables automatically, so a feature can work on your laptop and fail once deployed.

Quick fix: add the grant in the migration that creates the table

Supabase's advice is to treat grant, RLS, and policies as one unit in the same migration:

grant select on public.your_table to anon;
grant select, insert, update, delete on public.your_table to authenticated;
grant select, insert, update, delete on public.your_table to service_role;
alter table public.your_table enable row level security;
create policy "users can read their own rows"
  on public.your_table for select to authenticated
  using (auth.uid() = user_id);

Only grant what each role needs. Already seeing 42501? The full walkthrough is in Supabase permission denied for table: Data API grants fix.

What breaks, and what doesn’t

New tables in public, read through the Data API

If your app uses supabase-js, REST, or GraphQL, a new table with no grant returns:

{ "code": "42501", "message": "permission denied for table your_table" }

Existing tables

Per the changelog, "Existing tables are not affected", and they keep their current grants.

Direct connections

"If your app reads and writes Postgres over a direct connection (via psql, ORM or an app server with a connection string), this change will not affect you."

Other schemas

The changelog FAQ says tables in storage, auth, realtime, and custom schemas keep their current grants.

Why it works locally but fails in production

An open issue, supabase/cli #7286 (opened 22 Oct 2026), reports that the CLI installed by npm supabase@2.121.0 auto-exposes new public tables again when [api].auto_expose_new_tables is unset. The reporter writes that code without an explicit grant "works locally and fails with permission denied once deployed." A proposed fix, PR #7313, was closed without being merged on 23 Oct 2026, so check the CLI version you run.

Until that's settled, set the key yourself in supabase/config.toml so local matches hosted:

[api]
auto_expose_new_tables = false

Then reset your local database and run your tests. Anything missing a grant should now fail locally too.

Who creates tables without grants

Supabase notes that agents, CLI scripts, and AI platforms now create tables, often with no human reviewing the diff. Watch CI migrations, tables made in the dashboard, and tables your AI coding agent writes. The changelog suggests updating your agent's prompt or using the Supabase agent skill, which includes the grants step.

Pre-30-Oct deploy checklist

  1. Open Security Advisor and the Data API exposure badge in the Table Editor to see flagged tables.
  2. Set auto_expose_new_tables = false locally (above).
  3. Add explicit grants to every migration that creates a public table.
  4. Optionally opt in early with the revoke statements in the changelog, on a staging project first, so you find gaps before 30 October.
  5. Keep the changelog's rollback SQL to hand in case an early opt-in breaks something.

Also worth a read: RLS policies that pass review but leak data and Supabase service role key exposed.

FAQ

Does the planned 30 Oct change affect existing tables? No, per the changelog. They keep their grants.

Does it affect Drizzle or Prisma? Not if they connect over a direct Postgres connection, per the changelog.

Why does my new table work locally but return 42501 in production? Your local CLI may still auto-expose new tables (cli #7286). Set auto_expose_new_tables = false.

Should I GRANT ALL to anon? No. Grant only what each role needs, and keep RLS on.

Can I adopt it early? Yes. The changelog lists revoke statements and a rollback.

Keep your agent on the safe path

Disclosure: this is our own paid product.

If an AI agent writes your Next.js and Supabase code, Ship-Ready AI Rules ($19 (plus VAT where applicable)) adds guardrail hooks designed to stop your agent reading .env, running supabase db push, or importing the Stripe SDK into a client component, plus 18 skills and 6 subagents for Next.js, Supabase, and Stripe. It doesn't fix 42501 errors. It hasn't been run against a live Supabase project yet. Get Ship-Ready AI Rules.

Sources

Checked 24 Oct 2026: supabase.com/changelog/45329; github.com/supabase/cli/issues/7286 and its linked PR #7313.

Supabase is a trademark of Supabase Inc. Next.js is a trademark of Vercel, Inc. Stripe is a trademark of Stripe, Inc. Postgres is a trademark of the PostgreSQL Community Association of Canada. GitHub is a trademark of GitHub, Inc. Names are used only to identify products and compatibility. Stack & Ship is not affiliated with or endorsed by any of them.

Related posts