Supabase Oct 30, 2026 change: tables no longer auto-exposed to the Data API

Updated 2026-10-14 · Defensive guide for your own app

Short answer

On October 30, 2026 Supabase applies a new default to all existing projects: new tables you create in the public schema are not reachable through the Data API (supabase-js, REST, GraphQL) until you add an explicit Postgres GRANT. Existing tables keep their current grants. RLS behaviour does not change. If something breaks, you'll see error 42501 permission denied for table .... The safe fix is a narrow grant plus RLS and policies, not a blanket grant to anon.

Timeline (from Supabase's changelog)

Apr 28, 2026: opt-in toggle at project creation.
May 30, 2026: default for new projects (gradual rollout).
Oct 30, 2026: applied to all existing projects.

It only affects apps that use the Data API. If you only connect over a direct Postgres connection, Supabase says you are not affected.

The safe fix for a new table

Treat these three steps as a unit, as Supabase recommends:

-- 1. Grant only what each role needs
grant select on public.your_table to anon;            -- only if signed-out users really need to read it
grant select, insert, update, delete on public.your_table to authenticated;
grant select, insert, update, delete on public.your_table to service_role;

-- 2. Enable RLS
alter table public.your_table enable row level security;

-- 3. Add policies
create policy "users can read their own rows"
  on public.your_table for select to authenticated
  using ( (select auth.uid()) = user_id );

If the table is private to signed-in users, skip the anon grant entirely.

What not to do

The tempting one-liner is:

-- Avoid as a blanket fix
grant select, insert, update, delete on all tables in schema public to anon, authenticated;

Supabase publishes this only as a rollback. Run against a project with any table that lacks RLS or has using (true) policies, it hands write access to everyone. If you must roll back, revoke private tables individually right after.

How to check

Open Security Advisor; Supabase says it flags affected tables until Oct 30 and shows remediation SQL.
Check the Data API exposure badge in the Table Editor.

Audit what anon can do:

select table_name, privilege_type
from information_schema.role_table_grants
where grantee = 'anon' and table_schema = 'public'
order by table_name;

Update your AI tool's prompt or migrations so every create table ships with its grants, RLS and policies.

Check your own project in seconds

Upload a .zip of your own Lovable, Bolt, Cursor, Supabase or Firebase project. ProdCanary reviews the code statically and shows your top 3 risks with plain-English fixes. Your upload is deleted right after the scan.

Run a free scan

FAQ

Will my existing tables stop working on Oct 30?

No. Supabase says existing tables keep their current grants and stay reachable. The change affects tables created after it reaches your project.

What does the 42501 error mean?

A role is missing a privilege on the table. PostgREST's hint shows which GRANT is needed. Grant the narrowest privilege that fixes it, then confirm RLS and policies exist.

Does this replace RLS?

No. Grants decide whether a role can touch a table at all; RLS decides which rows. You need both.

Can I opt in early?

Yes. Supabase documents ALTER DEFAULT PRIVILEGES statements that revoke default grants for future tables in public on an existing project.

Sources

This guide is for securing apps you own or are authorised to work on. Facts above are from the official docs linked; check them for changes.