Supabase’s 30 October change: why new tables say “permission denied”

You ask Lovable for a new feature. It creates a table, writes the page, and the preview looks right. Then the page loads empty, or the browser console says permission denied for table. Nothing else changed. From 30 October 2026, this will happen to every Supabase project that gets a new table without one extra step, and AI builders create tables all the time.

This guide is for founders running a live app on Supabase, whether through Lovable Cloud, your own Supabase project connected to Lovable or Bolt, or a Replit app that uses Supabase. You will learn what changes, what does not, how to check your app in two minutes, and the exact fix, including one line you can add to your AI builder so it stops happening.

What is changing in Supabase on 30 October 2026?

From 30 October 2026, new tables in the public schema are no longer opened up to your app automatically. Until now, every new table got access for the anon, authenticated and service_role roles the moment it was created. After the change, someone has to grant that access on purpose, or the app cannot read or write the table.

Supabase names the people this will hit. Its changelog says it affects anyone whose “AI coding tools, CLI scripts, or Management API calls create tables and expect them to be reachable over the Data API on creation.” That is a description of how Lovable, Bolt and Replit build features.

Will my live app break on 30 October?

Not on its own. Supabase says existing tables keep their current access and stay reachable. What breaks is the next table you or your AI builder creates after the date. The first feature built after 30 October is the one that loads empty, while everything older keeps working.

That makes it confusing to debug. The usual signs:

• A new page or feature shows no data, but older pages work fine
• Saving a form fails with no visible message, or a toast that says something went wrong
• The browser console or network tab shows 42501 and permission denied for table your_table
• The table and its rows are visible in the Supabase dashboard, so it looks like the data is there
• Your row level security policies look correct, and turning them on or off changes nothing

That last point catches people. A security policy can only narrow access a role already has. It never adds access. So a table with perfect policies and no grant is still locked to everyone. It is the same kind of gap behind apps that work in preview but break when live: one environment has a setting the other is missing.

How do I check if my app is affected?

Run one query in the SQL editor. In Lovable Cloud, open More, then Cloud, then the SQL editor. In your own Supabase project, use SQL Editor in the dashboard. The query lists every table in public that a logged-in user cannot read.

-- Tables in public that logged-in users cannot read through the Data API
select c.relname as table_name
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public'
  and c.relkind in ('r', 'p', 'v', 'm')
  and not has_table_privilege('authenticated', c.oid, 'select')
order by 1;

No rows back means every table is reachable today. Any table listed is one your app cannot read as a logged-in user. That is fine if it is meant to be private, like an internal log, and a bug if your app uses it.

How do I fix “permission denied for table” in Supabase?

Grant access to the roles that need it, keep row level security on, and add a policy. Supabase’s own example does all three in one go. Replace your_table with the table from the error, and user_id with the column that stores who owns each row.

-- Only if logged-out visitors should read this table. Skip it for private data.
grant select on public.your_table to anon;

-- Logged-in users, and your server code / edge functions
grant select, insert, update, delete on public.your_table to authenticated;
grant select, insert, update, delete on public.your_table to service_role;

-- Keep the table locked to the right rows
alter table public.your_table enable row level security;
create policy "users can read their own rows"
  on public.your_table for select to authenticated
  using (auth.uid() = user_id);

Three extra cases that still fail after the grant

• IDs that count up (serial or bigserial). Inserts also need access to the counter behind the ID. Run grant usage, select on all sequences in schema public to authenticated, service_role;. Tables with uuid IDs do not need this.
• Server code using the service role key. The service role skips security policies, but it does not skip grants. Edge functions, including Stripe webhooks that unlock paid accounts, get the same 42501 on a new table until service_role is granted.
• Views. Supabase treats views like tables here, so they need a grant too. Create them with (security_invoker = on) so they respect the security rules of the tables underneath.

If the error says Could not find the table in the schema cache (code PGRST205) instead, the API has not noticed the new table yet. Run notify pgrst, 'reload schema'; in the SQL editor and try again.

How do I stop Lovable or Bolt from creating locked tables?

Tell the AI the rule once, in the place it reads before every change. In Lovable that is your project’s Knowledge. In Bolt, use the project prompt or system prompt settings. Then every new table arrives with grants, security rules and a policy in the same migration.

Supabase rule for every new table in the public schema:
In the same migration that creates the table, also
1. grant select, insert, update, delete to authenticated and service_role
2. grant select to anon ONLY if logged-out visitors must read it
3. if the table has a serial or bigserial id, grant usage, select on its sequence
4. enable row level security and add policies scoped to auth.uid()
Never disable row level security to fix a permission error.

Check the AI’s work once after each new table: the migration it shows you should contain the word grant. AI builders follow these rules most of the time, not all of the time, so the two-minute check above is still worth running after big features.

What is different in Lovable, Bolt and Replit?

The fix is the same SQL everywhere. Where you run it, and how likely you are to hit it, is not.

Lovable says its built-in backend uses Supabase’s open-source foundation, so Lovable Cloud apps are in scope. None of these builders has said publicly that it adds grants for you. Until one does, assume yours does not and add the rule above.

Should I do anything before 30 October?

Yes, three small things, about 15 minutes in total. None of them changes how your live app behaves today, so they are safe to do now.

1. 01

   Run the check query and save the result

   You now have a list of what is reachable today. If something breaks later, compare against it.

2. 02

   Add the rule to your Lovable Knowledge or Bolt prompt

   This turns every future table into a working table, before and after the date.

3. 03

   Test one new feature after 30 October on the live app

   Not just the preview. Log in as a normal user, create a record, and reload. If it saves and shows, you are covered.

What to do now

From 30 October 2026, new Supabase tables are locked until someone grants access, and AI builders do not always do that. Existing tables keep working. Run the check query, fix any locked table with grants plus row level security, and add the one-paragraph rule to your builder so the next feature does not load empty. While you are in there, the free scan shows what your app exposes from the outside.

If you would rather hand it over, I do this as a fixed $390 fix: I find every locked or over-exposed table, fix the grants and security rules on your live app, and set up your builder for future tables. You pay once it works. Not sure it is this? Describe what is broken and I reply with a fixed quote within one US business day.