Supabase's 30 October change: new tables need explicit grants before apps can reach them

On 30 October 2026, Supabase will enforce a permissions change on all existing projects: tables created in the public schema will no longer be reachable through the Data API until someone grants access explicitly. The Data API is the REST and GraphQL layer that supabase-js and other client libraries call, so a table that used to work the moment it existed will now stay invisible to the app until a GRANT statement runs. The timeline and the fixes are set out in a post on dev.to by VibeTierList, drawing on Supabase's changelog and documentation; the author notes the change has not been tested on a live project.

What changes

Until now, Supabase automatically gave the anon, authenticated and service_role roles select, insert, update and delete privileges on every new public-schema table, which made each one immediately available through /rest/v1/ and /graphql/v1/. Under the new behavior those privileges are simply absent until a migration adds them.

Per the timeline the post cites from Supabase's changelog, the rollout has been staged: opt-in at project creation from 28 April 2026, default for new projects from 30 May 2026, and enforcement across every existing project from 30 October 2026.

Supabase's stated motivation is AI-generated code: agents, CLI scripts and app-building platforms now create tables without a human reviewing the change, and the old default made it easy to expose a table before it had been secured.

Who is affected

According to the post, action is needed if an app reads or writes public tables through the Data API, or if its migrations or AI coding tool create tables without GRANT statements. That describes most Supabase apps assembled with AI builders such as Lovable or Bolt, where the browser calls the REST endpoint directly and the tool writes the schema.

Unaffected, per Supabase: existing tables keep their grants and stay reachable, row-level security behaves as before, storage, auth, realtime and custom schemas are untouched, and apps on a direct Postgres connection see no difference.

One open question the post flags is whether managed Supabase-compatible backends, such as Lovable Cloud and Bolt Database, apply the change on the same date or add grants themselves. Anyone pointing a builder at their own Supabase project should assume it applies.

How to recognize the failure

The tell-tale symptom is a feature built on a brand-new table that fails to load or save while older features keep working. Supabase's troubleshooting documentation, cited in the post, says clients often report this as a 401 or 403; inspecting the failing REST request in the browser's network panel reveals Postgres error 42501, permission denied for the table, with a hint naming the role and the privilege that is missing.

A look-alike needs ruling out: row-level security violations also return 42501, but their message mentions a row-level security policy. That is RLS doing its job, not this change. Supabase's Security Advisor flags affected tables along with suggested SQL, the Table Editor shows a Data API exposure badge, and current grants can be listed by querying information_schema.role_table_grants in the SQL editor.

The fix

Supabase's guidance is to keep the table, its grants, its row-level security setting and its policies together in a single migration: grant each role only what the app needs — typically select, insert, update and delete for authenticated and service_role, and select for anon only where logged-out visitors are meant to read the table — then enable row-level security and add the policies. Without the grant, Postgres rejects the query before RLS is ever consulted.

The post warns against three shortcuts: granting to anon by reflex rather than for deliberate public-read tables; treating grants as security, since grants decide whether a role can reach a table while RLS decides which rows it sees; and granting the entire schema at once, which would also expose any table where RLS was never enabled. For AI-builder workflows, Supabase suggests updating the tool's system prompt or using its agent skill so grants ship with every new table by default.

For context, VibeTierList operates a site that tests AI app builders and sells a related paid check, and says Supabase did not pay for the piece.

Why it matters

This is a breaking change disguised as a quiet day. Nothing fails on 30 October itself, because existing tables keep their grants; the breakage surfaces later, whenever an AI agent or migration creates the next table and nobody adds a GRANT. Old features working while the new one dies with a 403 is precisely the failure that is hardest to diagnose in generated codebases nobody reads closely. It is also a concrete case of AI code generation pushing platforms to retire unsafe defaults: Supabase is removing a convenience because machines, not people, now write the schema. Teams running Supabase-backed apps built by Lovable, Bolt or similar tools should update their prompts and migration templates before the date, and verify that row-level security is enabled while they are at it.