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

Posted on Oct 28 • Originally published at vibetierlist.com

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.

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.

{ "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;" } Enter fullscreen mode Exit fullscreen mode The hint names the role and the exact GRANT that's missing.

select grantee, privilege_type from information_schema. role_table_grants where table_name = 'your_table'; Enter fullscreen mode Exit fullscreen mode The fix: GRANT, and keep RLS on 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 ); Enter fullscreen mode Exit fullscreen mode Three things to avoid:

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. Related: the 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. It's separate from our rankings: your app is never ranked, and payment never changes a tool's score. Supabase didn't pay us.