Supabase's Oct 30 grants change: what breaks in AI-built apps and the fix

On October 30, 2026, Supabase applies a breaking change to every existing project: new tables in the public schema stop being exposed to the Data API automatically. If your app was built with Lovable, Bolt, Cursor or another AI tool, there's a good chance it creates tables and expects them to just work from the browser. After the 30th, the next table it creates won't.

This post explains what changes, what the error looks like, and the three-step fix. Everything here comes from Supabase's own changelog entry, “Tables not exposed to Data and GraphQL API automatically”, published April 28, 2026.

What changes

Until now, every table in public automatically got select, insert, update and delete grants for the anon, authenticated and service_role roles. That's why a table created by an AI tool was instantly reachable from supabase-js.

After the change, a new table needs an explicit GRANT before the Data API can reach it. Supabase's timeline:

It only touches default privileges in the public schema. Supabase says storage, auth, realtime and custom schemas keep their current grants. Row Level Security behavior is unchanged.

Are you affected?

Yes, if both of these are true:

• You use the Data API on public tables: supabase-js or another client library, PostgREST, GraphQL, or direct HTTP calls to /rest/v1/ or /graphql/v1.
• Something creates new tables after Oct 30 and expects them to be reachable automatically: your migrations, CLI scripts, Management API calls, or an AI builder.

Direct Postgres connections (psql, an ORM, or a server using a connection string) are not affected.

What the error looks like

When a grant is missing, PostgREST returns error 42501:

{
  "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;"
}

In a Lovable or Bolt app this usually shows up as an empty list, a spinner that never ends, or a generic “something went wrong” toast. Check your browser's network tab for a 401 or 403 on a /rest/v1/ request.

The fix: three steps, as one unit

Supabase says to treat these as a unit. The trap is doing only step 1: granting access without RLS exposes the table to anyone holding your public key.

-- 1. Grant the privileges each role needs
grant select on public.your_table to anon;
grant select, insert, update, delete on public.your_table to authenticated;
grant select, insert, update, delete on public.your_table to service_role;

-- 2. Turn on Row Level Security
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);

Only grant anon what logged-out visitors should actually see. For most user data that's nothing, so drop the first line.

Make your AI builder do it every time

The lasting fix is to stop creating tables without these steps. Add a rule to your builder's project instructions (Lovable Knowledge, Cursor rules, and so on):

Every new table in public must ship in the same migration with: explicit grants for authenticated and service_role (and anon only if it's public data), RLS enabled, and at least one policy scoped to auth.uid().

Before the 30th: find the tables at risk

Supabase says its Security Advisor flags affected tables and shows remediation SQL until the change lands. Open your project's Advisors page and work through anything flagged. Also look for tables with RLS off. Those are a bigger problem today than any grant.

Want it checked for you?

The Launch Risk Diagnostic checks grants, RLS and policies on every table, plus exposed keys, auth and backups. You get a ranked report and a fixed quote in 2 business days, and the $250 is credited to the fix.