Home › Rules › Supabase 42501 fix

Supabase error 42501 "permission denied for table": the Oct 30 fix

From Supabase's own changelog and docs, checked Oct 26, 2026. Sources below.

• Fix
• Supabase
• Postgres
• RLS
• Lovable
• Bolt

Short answer: on October 30, 2026, Supabase stops giving new tables automatic access through its Data API on all existing projects. A table you (or Lovable, Bolt or another AI tool) create in the public schema after that won't be reachable from your app until you add a Postgres GRANT. Until then, requests fail with error 42501, "permission denied for table". Tables you already have keep working. The fix is three short SQL steps: grant, keep RLS on, add policies.

What the error looks like

Your app's request (through supabase-js or the REST API) comes back with this instead of data. The hint names the role and the exact GRANT that's missing:

{
  "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 fix: copy, edit the table name, run

Open your project's SQL Editor in the Supabase dashboard, paste this, replace your_table (and user_id if your owner column has another name), and run it. Supabase's changelog says to treat these three steps as a unit:

-- Fix for "42501 permission denied for table" on a NEW Supabase table.
-- Replace your_table with your table's name. Run it in the Supabase SQL Editor.

-- 1. Let the Data API roles reach the table (grants)
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 logged-out visitors should READ this table (e.g. public blog posts):
-- grant select on public.your_table to anon;

-- 2. Keep Row Level Security ON (grants do NOT replace it)
alter table public.your_table enable row level security;

-- 3. Say which rows each user may see or change (example: rows they own)
create policy "users can read their own rows"
  on public.your_table
  for select
  to authenticated
  using (auth.uid() = user_id);
-- Add matching policies for insert, update and delete if users write to this table.

Don't turn RLS off to make the error go away. Grants and RLS are separate layers: the grant decides whether a role can reach the table at all, and RLS decides which rows it can see. Supabase's docs warn that a table exposed through the Data API without RLS can be read by anyone with a matching grant.

What exactly changes, and when

Before the change, Supabase granted select, insert, update and delete on every new public table to the anon, authenticated and service_role roles automatically. Supabase's reason for the change: AI tools, scripts and agents now create tables with no human checking them, and the old default could expose a table before anyone secured it.

Who is affected

• Affected: apps that read or write public tables through the Data API: supabase-js and the other client libraries, REST (/rest/v1/) or GraphQL. That's how most Lovable and Bolt apps talk to Supabase.
• Affected: anything that creates new tables without explicit grants: migrations, scripts, the Management API, or an AI coding tool.
• Not affected: tables that already exist. They keep their current grants.
• Not affected: apps that only use a direct Postgres connection (psql, an ORM or a server with a connection string).
• Not affected: the storage, auth and realtime schemas, and your custom schemas.

So nothing breaks on Oct 30 by itself. It breaks the first time someone adds a new table without a grant, often weeks later, when an AI tool adds a feature.

Fix it from Lovable or Bolt

If Lovable, Bolt or another AI builder manages your Supabase database, paste this into its chat. It asks for the grants and stops the AI from taking the "just disable RLS" shortcut:

My app is getting Supabase error 42501 "permission denied for table [table name]".
Since Supabase's Oct 30, 2026 change, new tables in the public schema need explicit GRANT statements before the app can reach them.

Please fix it with a new migration that, for each table the app uses that is missing grants:
1. Grants select, insert, update, delete to authenticated and service_role (and select to anon ONLY if logged-out visitors must read it; ask me first).
2. Keeps Row Level Security enabled. Do NOT disable RLS and do NOT make tables public as a shortcut.
3. Keeps or adds RLS policies so users only see and change their own rows.

Before you change anything, list the tables you'll touch and the exact SQL. After it runs, test one read and one write as a logged-in user and tell me the result.

Read the SQL it proposes before you approve it. You should see grant lines, enable row level security, and policies. If you see disable row level security or grant ... to anon on a private table, say no.

Check and finish the job

See which roles can reach a table (from Supabase's 42501 troubleshooting guide):

-- Which roles can reach this table right now?
select grantee, privilege_type
from information_schema.role_table_grants
where table_name = 'your_table';

Two follow-ups you may hit after the table fix:

-- Only if you then see "permission denied for sequence" when inserting
-- (tables with a serial id column). Replace the name with your sequence's name.
grant usage, select on sequence public.your_table_id_seq to authenticated;

-- Only if an RPC call (supabase.rpc) fails with "permission denied for function"
grant execute on function public.your_function() to authenticated;

In the dashboard, the Security Advisor flags affected tables and shows the fix SQL, and the Table Editor shows a Data API exposure badge per table.

Stop it from happening again

Add this to your project's rules file (AGENTS.md or CLAUDE.md, or Lovable Project Knowledge) so every new table comes with its grants:

## Supabase tables (since the Oct 30, 2026 grants change)
- Every migration that creates a table in the public schema must, in the same migration:
  1. grant only the privileges each role needs (authenticated, service_role; anon only if logged-out users must read it),
  2. enable row level security,
  3. add the RLS policies.
- Never fix a 42501 "permission denied" error by disabling RLS or granting everything to anon.

Quick answers

• Can I switch it on before Oct 30? Yes. Supabase's changelog has the SQL to opt an existing project in early. New tables then need grants right away; existing tables keep working.
• Should I just grant everything on all tables? Only if every table has RLS on with the right policies. A bulk grant re-exposes tables you meant to keep private.
• Why does the hint mention anon? The request was made by a logged-out user (or before login finished). Grant anon only on tables visitors should see without logging in.

Related

• Supabase app rules (AGENTS.md + Cursor rules)
• Lovable + Supabase rules (Project Knowledge template)
• Bolt + Supabase rules
• Vibe coding security checklist (12 checks before you launch)
• Lovable prompts that work

Sources

• Supabase changelog: Breaking Change: Tables not exposed to Data and GraphQL API automatically
• Supabase docs: Securing your API
• Supabase docs: Database API 42501 errors

Checked Oct 26, 2026. Supabase may adjust the rollout; if something here no longer matches, tell us at [email protected].