Supabase changes on 30 October: why your new table suddenly throws a permission error

You ask Lovable for a new feature, a table gets added, and the screen stays empty. Or you see permission denied for table in the console. Your old tables work fine, only the new one does not. That is not a bug in your app. Supabase changes how new tables are reachable on 30 October 2026, and if your AI tool creates a table without the grants to go with it, this is exactly the error you get.

What Supabase is changing

Until now, every table in the public schema automatically got select, insert, update and delete for the roles anon, authenticated and service_role. Whatever you created was immediately reachable through the Data API: supabase-js, REST and GraphQL.

That stops. Since 28 April 2026 new projects could opt out, since 30 May it is the default for new projects, and on 30 October 2026 it applies to all existing projects. From then on, a new table in public is not reachable through the Data API until you grant access yourself.

What does not change: your existing tables keep their grants. A direct Postgres connection works as it always did, and storage, auth, realtime and custom schemas are out of scope. It only concerns tables you newly create in public after the switch.

Supabase's stated reason is that AI tools create tables without anyone reviewing them, and a table that is open by default is then a risk nobody has seen. For you it mostly means that a new feature does not work while the rest of your app carries on as normal.

Why it suddenly breaks for you

The pattern is nearly always the same. After 30 October you ask your AI tool for something new: a list of appointments, notes on a customer, a settings page. The tool creates a table, writes the code that reads and writes to it, and in the preview you see an empty list or an error. Saving does nothing. Ask the tool to fix it and it may well go looking in your frontend code, while the problem sits in the database.

How to recognise it: error 42501

Open your app, press F12 and look in the Network tab at the request to your Supabase project. With this error, the response 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;"
}

In place of your_table you will see the name of your new table. Your browser console shows permission denied for table as well. The Supabase Table Editor also shows a badge per table indicating whether it is exposed through the Data API, so you can see at a glance which table it is.

Two things make it confusing. The hint Supabase sends along suggests granting access to anon, which is exactly what you should not do blindly. And many screens do not show the error but simply leave the list empty, so it looks as if there is no data.

The fix, and the mistake not to make

Supabase itself gives this SQL as the fix, to run in the SQL Editor of your project. Replace your_table with the name of your table and user_id with the column that holds the owner of the row:

grant select, insert, update, delete on public.your_table to authenticated;
grant select, insert, update, delete on public.your_table to service_role;

-- Only if anonymous (not signed-in) visitors may read this table:
-- grant select on public.your_table to anon;

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);

The first two lines are the grants: which role can reach the table at all. The line for anon is switched off on purpose: only remove the dashes if anonymous visitors really may read this table. The last two switch on Row Level Security and add a rule that decides which rows someone gets to see. Those are two separate layers, and you need both.

Grants without RLS mean your table is open again. You have then manually undone what Supabase just closed.

So do not paste that first line for every table. Only give anon access to tables that anonymous visitors are genuinely allowed to see, such as public products or blog posts, and then only select. A table with customer data, invoices or messages needs nothing for anon. Enable RLS on every table, with a policy that matches who may see what. A policy with using (true) is not protection, it is leaving the door open with extra steps.

The example above only covers reading. If users may also add, change or delete rows, each of those actions needs its own policy. Afterwards, the Supabase Security Advisor lists the tables worth another look.

Getting your AI tool to do it properly

If you work in Lovable, Bolt or a similar tool, you can have this sorted in one go. Paste this into the chat, with your table name filled in:

The table [name] returns permission denied for table (42501), because Supabase no longer exposes new tables through the Data API automatically. Write a migration that grants each role only what it needs: anon only if anonymous visitors may see this data, authenticated and service_role what the app actually uses. Enable Row Level Security and write a policy per action that decides which rows a user may read and change. Never use using (true). Show me the SQL before you run it.

That last part matters most. Read the SQL before you approve it and look for two things: is there a to anon on a table that should be private, and is there a policy that lets everyone do everything. If you see either, ask why.

Where it stops being a quick fix

The grants are mechanical. The policy is the hard part, because someone has to decide who may see which rows, and that is exactly where AI tools go wrong: a policy that works in the preview because you test as yourself, but that shows user A the data of user B. How to check for that is in why can my users see each other's data. The rest of the list before you go live is in is your AI-built app safe for real customers.

If you have several tables and no longer know which rules actually apply, that is the moment to hand it over. Stuck with AI coding explains how I take it on, and a vibecode assessment lists every table, grant and policy along with what needs to happen.

If you first just want to know where you stand, start with the free vibecode scan. I spend ten minutes looking at your project and you get an honest verdict back.