BuildNot yet confirmed elsewhere1 publisher2 min readPublished
Supabase turns off automatic Data API exposure for new tables on every existing project on 30 October
Supabase will stop exposing new public-schema tables to its Data API automatically on all existing projects on 30 October 2026. Tables created after that date stay invisible to supabase-js until a role is granted access.
The Engineer · Build desk
Timeline: on 28 April 2026 the new setting became available for new projects, selectable at project creation; on 30 May 2026 it becomes the default for new projects, rolled out over a few weeks; on 30 October 2026 it is applied to all existing projects.
| Date | Event | Claim |
|---|---|---|
| April 28, 2026 | Available for new projects, selectable at project creation | 2 |
| May 30, 2026 | Default for new projects, rolled out over a few weeks | 3 |
| October 30, 2026 | Applied to all existing projects | 4 |
What happened
- The new setting became available on 28 April 2026 and can be chosen when a project is created.
- It becomes the default for new projects on 30 May 2026, rolled out over a few weeks.
- Existing tables are untouched; the changelog says they "keep their current grants and stay reachable."
- Apps that reach Postgres only over a direct connection, such as an ORM or psql, are unaffected, according to the changelog.
- The Security Advisor will flag affected tables before the date, and owners and admins will be emailed.
Why it matters
- constraint A migration that creates a table and omits grants worked because the old default filled the gap. After 30 October, each such migration needs its own grant statements.
- exposure A grant to anon or authenticated on a SQL Editor table opens it to every role with a matching grant unless RLS is switched on, because only Dashboard-created tables get RLS by default.
- decision Teams choose between writing grants table by table and revoking the default privileges so every new table starts closed. The docs give the revoke statements for tables, functions and sequences.
Supabase describes this as a change of default. The docs say Supabase is "changing the platform default to revoke these automatic grants so that exposure becomes opt-in." [9] As things stand, the anon, authenticated and service_role roles all receive select, insert, update and delete on every new table in public without anyone asking [8]. On the new default, a new table needs an explicit Postgres grant before the Data API can see it [18].
The failure is quiet on the database side. The table exists and looks normal, and the app gets an error where it used to get rows [19]. PostgREST returns a 42501 error for a missing grant [7].
The dev.to post offers an audit query against information_schema.role_table_grants and says plainly that it is the post's own query, not Supabase's [10]. The query reports on tables that already exist, and those are untouched, so we'd expect it to look clean the day before the cutover. It cannot tell you about the next table.
The cheaper test is a fresh project. The new setting has been selectable at project creation since 28 April [2], which is 185 days before the 30 October cutover [20]. Run the full migration set against a project created with it on. Any table that needs a grant and lacks one will show up as an error from the Data API [7].
We think grants belong in the same migration file as the create table statement. One file then holds the table, its grants and its RLS policy setup, and a reviewer sees all three in one diff. The docs advise the narrowest grant that will do the job: anonymous clients get read-only access, signed-in users get full access with RLS still enforced, and the service role gets full access only where server code goes through the Data API to reach the table [12]. The post adds its own rule, no write grant to anon unless anonymous writes are the point of the table [17].
Functions need separate care. The docs note that RLS does not apply to functions, so EXECUTE should go only to the roles that need it [15].
What to watch
- The Security Advisor flags and owner or admin emails that Supabase says will arrive before 30 October, the first list of tables affected on a given project.
- Any revision to the three dates in the Supabase changelog, since the 30 October cutover for existing projects is the one with no opt-out described in the post.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence55
- Adoption
- Insufficient
- Hype gap
- Insufficient
- Incentives
- Insufficient
- Confidence60
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The Supabase changelog states the new rule as: "New tables in the public schema will no longer be exposed to the Data API automatically."
- [2]
On 28 April 2026 the new setting became available for new projects, selectable at project creation.
- [3]
On 30 May 2026 the new setting becomes the default for new projects, rolled out over a few weeks.
- [4]
On 30 October 2026 the new setting is applied to all existing projects.
- [5]
Existing tables are not touched; the changelog says they "keep their current grants and stay reachable."
- [6]
If an app only uses a direct Postgres connection, such as an ORM, psql or a server with a connection string, the changelog says it is unaffected; the change concerns the Data API, which supabase-js and other client libraries call over HTTP.
- [7]
A missing grant returns a 42501 error from PostgREST.
- [8]
On existing projects today, new tables in the public schema get select, insert, update and delete for anon, authenticated and service_role by default.
- [9]
The docs say Supabase is "changing the platform default to revoke these automatic grants so that exposure becomes opt-in."
- [10]
The post supplies an audit query against information_schema.role_table_grants for the anon, authenticated and service_role grantees in the public schema, and says it is the post's own query, not Supabase's.
- [11]
The changelog says the Security Advisor will flag affected tables before the date, and that owners and admins will be emailed.
- [12]
The docs recommend the smallest grant that works: read-only for anonymous clients, full access for signed-in users with RLS still applied, and full access for the service role only where server code reaches the table through the Data API.
- [13]
Tables created through the Supabase Dashboard have RLS on by default; tables created in the SQL Editor or with another tool do not.
- [14]
The docs warn that "Tables and views exposed through the Data API without RLS can be accessed by any role with matching grants."
- [15]
RLS does not apply to functions, so EXECUTE should be granted only to the roles that need it.
- [16]
As an alternative to per-table grants, the docs give alter default privileges statements for role postgres in schema public that revoke the default privileges on tables, functions and sequences from anon, authenticated and service_role, so every new table starts closed.
- [17]
The post's own rule is no write grant to anon unless anonymous writes are the point of the table.
- [18]
A new table now needs an explicit Postgres grant before the Data API can see it.
- [19]
On a project with the new default, the app gets an error where it used to get rows, while the table sits in the database looking fine.
- [20]
185 days separate 28 April 2026, when the setting became selectable at project creation, and 30 October 2026, when it applies to all existing projects.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toSupabase Data API exposure changes on 30 October: grant tables explicitly
1 article · October 12, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Supabase Data API exposureFollow
- Postgres privileges and grantsFollow
- Row-Level SecurityFollow
- Secure-by-Default ConfigurationFollow