What Supabase Actually Changed (and When)
On April 28, 2026, Supabase began rolling out one of the most meaningful security defaults it has ever shipped. The short version: new tables you create in the public schema are no longer automatically reachable through the Data API. Since May 30, 2026, that behavior is the default for every new project.
Previously, when you created a Supabase project, `select`, `insert`, `update`, and `delete` were automatically granted on every public-schema table to the `anon`, `authenticated`, and `service_role` roles. Every table became reachable via the Data API the moment it landed — no extra SQL required. That changes now.
The full enforcement timeline: May 30, 2026, new projects default to no auto-exposure. October 30, 2026, the setting is applied to all existing projects. Between now and then, Supabase's Security Advisor will flag affected tables, and the team says they will email active projects before enforcement hits. That gives teams roughly four months to audit and update migrations — not a lot of runway if you have a large schema.
One important note: if your app talks to Postgres via a direct connection string — through an ORM, psql, or a server-side connection pooler — this change does not touch you. The change only affects the auto-generated REST and GraphQL layer that `supabase-js` and the other client libraries call.
- April 28, 2026: Opt-in to new behavior available at project creation
- May 30, 2026: No-auto-exposure becomes default for all new projects
- October 30, 2026: Enforced on all existing projects
- RLS policies are unaffected — grants and RLS are two separate layers
- Direct Postgres connections (psql, ORM, connection string) are not affected