Lovable app says "permission denied for table"
The new table has no grants. Paste it below and copy a fix prompt made for Lovable.
Write the fix for your tables
Waiting for a paste.
Who can reach each table
Your tables show up here, one row each, with a choice of who can reach them.
Parsed in your browser. Your SQL is never uploaded, and no site or database is scanned.
Why this happens in Lovable projects
When Lovable adds a table to your Supabase database, the table lands in the public schema. Supabase used to grant every new public table to the API roles on its own. It no longer does, so the first request to the new table fails with 42501 until the grants exist.
- Before: every new table in
publicwas granted toanon,authenticatedandservice_roleautomatically. - After the change: a new table has no grants until you write them. The Data API answers 42501,
permission denied for table. - Tables that already existed keep their grants. Row level security works as before.
How to apply the fix from Lovable
Lovable's Supabase documentation (read 2026-11-10) says it writes the SQL, shows it to you, and asks for your approval in the project chat before running it. So the prompt route works: paste the fix prompt, read the SQL Lovable shows, and approve it. That page does not mention grants or error 42501.
- Paste the table into the tool above and choose the access you want.
- Open the Fix prompt tab. The prompt tells the builder to add the SQL unchanged, and to include grants with every table it creates from now on.
- Or skip the builder: copy the GRANT + RLS tab and run it in the Supabase SQL Editor.
What the SQL looks like
For a table where each signed-in user sees only their own rows:
-- public.your_table: owner only
alter table public.your_table enable row level security;
revoke all on table public.your_table from anon, authenticated;
grant select, insert, update, delete on table public.your_table to authenticated;
grant select, insert, update, delete on table public.your_table to service_role;
drop policy if exists your_table_select_own on public.your_table;
create policy your_table_select_own on public.your_table
for select to authenticated
using ( (select auth.uid()) = user_id );
drop policy if exists your_table_insert_own on public.your_table;
create policy your_table_insert_own on public.your_table
for insert to authenticated
with check ( (select auth.uid()) = user_id );
drop policy if exists your_table_update_own on public.your_table;
create policy your_table_update_own on public.your_table
for update to authenticated
using ( (select auth.uid()) = user_id )
with check ( (select auth.uid()) = user_id );
drop policy if exists your_table_delete_own on public.your_table;
create policy your_table_delete_own on public.your_table
for delete to authenticated
using ( (select auth.uid()) = user_id );
Dates are from the Supabase changelog post published 2026-04-28, read 2026-11-10. We have not seen an official post confirming that the 2026-10-30 step finished for every project, so check your own project with this query.
Questions
Will Lovable fix this by itself if I paste the error?
It may. The error carries a hint that names one missing grant, and Supabase says tools can correct themselves from it. The hint covers one role and one privilege at a time, so you can go through several rounds. The SQL here sets every role, turns on row level security and adds the policies in one step.
Is it safe to grant access to anon?
Only for data that is meant to be public. A grant to anon with a policy of "using ( true )" lets every visitor read every row. Choose Owner only or Private for anything else.
Sources
- Lovable docs: Supabase integration, read 2026-11-10
- Supabase changelog: Breaking Change: Tables not exposed to Data and GraphQL API automatically (published 2026-04-28), read 2026-11-10
- Supabase docs: Securing your API, read 2026-11-10
Related
- Go back to automatic exposureSupabase documents the SQL. Read what it re-opens before you run it.
- Local tables missing grants after db resetA reset replays your migrations. Without grants in them, tables come back closed.
- Every cause of 42501 on Supabase42501 means "insufficient privilege". Match your message to a row.
- Bolt app says "permission denied for table"The new table has no grants. Paste it below and copy a fix prompt made for Bolt.