Supabase's 30 Oct change: the next table your AI builder creates needs a GRANT. Here's the 2-minute check.

Supabase will stop automatically granting Data API access to new tables in the public schema on 30 October 2026, requiring an explicit Postgres GRANT before a table is reachable via supabase-js, REST or GraphQL. Existing tables keep their current grants, and row level security, storage, auth, realtime and custom schemas are unaffected. Supabase attributes the change to AI agents, CLI scripts and AI builders creating tables without human review, which made it easy to expose a table before it was secured; apps built on Lovable or Bolt that use their own Supabase projects should assume the change applies.

If your app was built with Lovable, Bolt or another AI builder on top of Supabase, one thing changes on 30 October 2026 : new tables stop being reachable from your app until they get an explicit Postgres GRANT . Your existing tables keep working. The one that breaks is the next table, for example when you ask your AI builder for a new feature on 31 Oct. Everything below is from Supabase's own changelog and docs, read on 28 Oct 2026. We haven't run the change on a test project. Until now, Supabase granted select , insert , update and delete on every new table in the public schema to the anon , authenticated and service role roles, so a table was reachable through the Data API the REST/GraphQL layer that supabase-js calls the moment it existed. Supabase's timeline changelog https://supabase.com/changelog/45329 : What doesn't change, per Supabase: existing tables "keep their current grants and stay reachable", row level security works the same, storage / auth / realtime /custom schemas are untouched, and apps that only use a direct Postgres connection aren't affected. Supabase's stated reason is worth reading if you build with AI: agents, CLI scripts and AI platforms now create tables without a human reviewing the diff, and the old default made it easy to expose a table before it was secured. Supabase says you need to act if your app talks to public tables through the Data API supabase-js , any client library, /rest/v1/ , /graphql/v1 , or if your migrations or AI coding tool create tables without GRANT statements. That's most Supabase apps built with AI: the browser calls …supabase.co/rest/v1/ directly and the AI writes the migrations. In our own test on 16 Oct 2026, Lovable's app ran on Lovable Cloud Supabase-compatible and Bolt's on Bolt Database Supabase . Not verified: whether those managed backends get the change on the same date, or whether Lovable or Bolt now add grants for you. If you connected your own Supabase project, assume it applies. …supabase.co/rest/v1/<table . A missing grant looks like this: { "code": "42501", "message": "permission denied for table your table", "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.your table TO anon;" } The hint names the role and the exact GRANT that's missing. 42501 , but the message "new row violates row-level security policy" is a row level security policy doing its job, not this change. We saw exactly that in Lovable's and Bolt's apps when a second user tried to write a row as the first user. select grantee, privilege type from information schema.role table grants where table name = 'your table'; Supabase says to treat these as one unit, in the same migration: "If the grant is missing, Postgres rejects the query before RLS comes into play." -- 1. Grant only what each role needs grant select on public.your table to anon; -- only if logged-out visitors should 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. Keep row level security on alter table public.your table enable row level security; -- 3. Add the policies you need create policy "users can read their own rows" on public.your table for select to authenticated using auth.uid = user id ; Three things to avoid: anon by reflex. An example we wrote, not a tested recipe: From now on, every time you create a new table in the Supabase public schema, put explicit GRANT statements in the same migration as the table, its row level security and its policies. Grant select, insert, update and delete to authenticated and service role only where the app needs them. Grant select to anon only for tables that logged-out visitors are meant to read. Never turn row level security off and never grant to all tables in the schema at once. Now check the table your table , which returns error 42501 "permission denied for table": add the missing grants, keep RLS on, and list the grants and policies you added. Then reload with the Network tab open and confirm the 42501 is gone. Supabase also suggests updating your AI tool's system prompt, or using its agent skill, so grants are added by default. Full guide, with evidence labels: Supabase's 30 Oct change: new tables need a GRANT https://vibetierlist.com/guides/supabase-oct-30-data-api-change/ . Related: the two-account test https://vibetierlist.com/guides/two-account-test/ can user A see user B's data? . Disclosure: we run VibeTierList, which tests AI app builders. Want someone to run checks like these on your live app? Launch Check, $29 https://vibetierlist.com/launch-check/ . It's separate from our rankings: your app is never ranked, and payment never changes a tool's score. Supabase didn't pay us.