Supabase's 30 Oct change: new tables need a GRANT

If your app was built with Lovable, Bolt or another AI builder on top of Supabase, here's what changes on 30 October 2026, how to tell if it hit you, and the fix. Short version: your existing tables keep working; the next new table won't, until it gets a GRANT.

What changes on 30 October

Until now, Supabase granted select, insert, update and delete on every new table in public to the anon, authenticated and service_role roles, so a table was reachable from your app the moment it was created. Supabase is turning that off Verified:

What doesn't change, per Supabase: existing tables "keep their current grants and stay reachable"; row level security works the same; tables in storage, auth, realtime and custom schemas are untouched; and apps that only use a direct Postgres connection (psql, an ORM, a connection string on a server) are not affected Verified. Supabase's reason: AI tools, scripts and agents now create tables without a human reviewing the change, and default grants made it easy to expose a table before it was secured.

Who's affected

Supabase says you need to act if your app reads or writes public tables through the Data API (supabase-js, any client library, or requests to /rest/v1/ or /graphql/v1), or if your migrations or "AI coding tool" create tables without GRANT statements and expect them to be reachable Verified.

That describes most apps built with AI on Supabase: the browser talks to …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) Observed. Lovable also lets you connect a Supabase project you own, where it designs the schema and runs migrations Verified, Lovable docs.

What we haven't verified: whether the managed backends (Lovable Cloud, Bolt Database) get the change on the same date, and whether Lovable or Bolt now add grants automatically. If you connected your own Supabase project, assume it applies. Either way, the check below takes two minutes.

Base44's app in our test used Base44's own built-in database, not Supabase Observed, so this change only matters there if you connected Supabase yourself.

How to tell if it hit you

1. The symptom: a feature that uses a table created on or after 30 Oct doesn't load or doesn't save, while older features work. Supabase says clients often report the error as a 401 or 403 Verified, Supabase troubleshooting doc.
2. Where to look in the browser: open developer tools (F12), Network tab, reload, and click the failing request to …supabase.co/rest/v1/ plus a table name. 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 Verified.
3. Don't confuse it with a policy error. The same code 42501 with the message "new row violates row-level security policy" is a row level security problem, not this change. We saw that one in Lovable's and Bolt's apps when user B tried to write a row as user A, which was the app working correctly Observed, 16 Oct 2026 (two-account test).
4. Where to look in Supabase: Supabase says the Security Advisor flags affected tables and shows the fix SQL, and the Table Editor shows a Data API exposure badge Verified. To see a table's grants, run this in the SQL Editor (from Supabase's troubleshooting doc):

   select grantee, privilege_type
   from information_schema.role_table_grants
   where table_name = 'your_table';

   No rows for authenticated on a table your signed-in users need = missing grant.

The fix: GRANT, and keep RLS on

Supabase says to treat these three steps as one unit, in the same migration: grant, enable RLS, add policies. "If the grant is missing, Postgres rejects the query before RLS comes into play" Verified.

-- 1. Grant only what each role needs (from Supabase's changelog)
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);

• Least privilege. Leave anon out unless logged-out visitors are meant to read that table. A profiles or invoices table usually shouldn't be readable by anon Inferred.
• Grants don't replace RLS. Supabase's docs: grants control whether a role can reach a table, RLS controls which rows. A table exposed through the Data API without RLS can be accessed by any role with matching grants, and anon is your public key Verified, Securing your API.
• Don't "fix" it by granting everything. Granting all tables in the schema to anon at once also opens any table where RLS was never switched on Inferred.

Example prompt for Lovable, Bolt or your coding agent

An example we wrote, not a tested recipe. Replace the brackets, paste it in, then reload the page 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.

Sources

• Supabase changelog: Breaking Change: Tables not exposed to Data and GraphQL API automatically (dates, who's affected, fix SQL, 42501 example)
• Supabase docs: Securing your API (grants vs RLS, "Grant access explicitly")
• Supabase docs: Database API 42501 errors (401/403, checking a table's grants)

Keep going

• The two-account test: can user A see user B's data? Includes the public-key check for Supabase tables.
• The 12-step pre-launch checklist, built from the bugs our tests found.
• What each builder made in our test: Lovable review · Bolt review
• All guides · Disclosures

Evidence labels: Verified = read on the named official page on 28 Oct 2026 (links above). Observed = seen in our own v1 run on 16 Oct 2026. Inferred = our reading. What the labels mean. Supabase didn't pay us and there are no affiliate links on this page.

FAQ

How to cite