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):
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. 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.