Supabase Cuts Default Data API Access on All Projects Oct. 30

On Oct. 30, Supabase will stop granting the Data API access to new tables in the public schema on every existing project. Any migration that creates a table and expects supabase-js to reach it will then fail until it includes an explicit GRANT, according to a Supabase changelog entry dated April 28, 2026.

What changes

Until now, a table created in public automatically received select, insert, update and delete privileges for the anon, authenticated and service_role roles. That made it reachable through PostgREST, GraphQL and the client libraries the moment it existed. Supabase’s changelog says that made new tables easy to expose before they were secured.

The change is staged. New projects could opt in on April 28. It became the default for new projects on May 30, in a gradual rollout over a few weeks. Oct. 30 is the date for existing projects.

Existing tables keep their current grants and stay reachable. Row Level Security behaves as before: grants decide whether a role can touch a table at all, and policies decide which rows it sees. Apps that talk to Postgres over a direct connection, through psql, an ORM or an app server, are not affected.

What breaks

Supabase lists three cases that need action: apps using the Data API against public tables, migrations that create tables without GRANT statements, and AI coding tools or CLI scripts that create tables and assume they are reachable on creation.

A missing grant produces a Postgres 42501 permission error. PostgREST returns a hint naming the exact GRANT statement needed. Supabase said Security Advisor will flag affected tables. It also said it will email active projects before the date.

The fix is to put grants, enable row level security and policies in the same migration. Projects that want the behavior early can run two alter default privileges ... revoke statements in the SQL Editor. Supabase published them in the changelog. They change defaults for future tables and sequences only.

Why Supabase says it is doing this

The changelog’s stated reason is agents. Supabase said a person used to review each schema change and enable RLS table by table. Agents, CLI scripts and AI platforms now create tables with no one reading the diff. Explicit grants, it argued, are reviewable and diffable in migrations. They also give per-role control.

Supabase’s Securing your API guide describes the same default privileges. Firerun checked it Oct. 20. It says the platform is changing them so exposure becomes opt-in.

Our read

This is a sensible default with an awkward deadline. The risk is not the policy but the long tail: provisioning scripts, seed tools and templates written years ago that never needed a grant. Those fail loudly, a better outcome than silent exposure. Ten days is still short for teams that ship migrations from several repos. Grep migrations for create table in public and check that each has a matching grant.