Prisma tables return "permission denied for table"

Worked example

Supabase's Prisma guide has you create a database user named prisma and run migrations as that user. Supabase's automatic grants were default privileges set for role postgres. The PostgreSQL manual says what that means: at object creation time, new object permissions are only affected by the default privileges of the current role.

We ran rows one and two in our test: with the old defaults in place, a table created by postgres was readable by anon, and a table created a moment later by a prisma role answered permission denied for table for anon and for service_role.

Prisma itself is not affected. It connects straight to Postgres as its own user. The error appears only when the same tables are read through the Data API, for example with supabase-js in the browser.

See who made each table

select
  c.relname as table_name,
  c.relowner::regrole as created_by,
  has_table_privilege('anon', c.oid, 'select') as anon_can_select,
  has_table_privilege('authenticated', c.oid, 'select') as authenticated_can_select,
  has_table_privilege('service_role', c.oid, 'select') as service_role_can_select
from pg_class c
where c.relnamespace = 'public'::regnamespace
  and c.relkind in ('r', 'p')
order by 1;

The fix: grants in a migration

Add the grants as SQL in a Prisma migration, so every environment gets them. For a table where each user owns their 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 );

The line that enables row level security matters as much as the grants: a granted table with RLS off is readable by anyone holding the publishable key. Paste your create table SQL from the migration into the tool below to get this for every table at once.

Supabase's Prisma guide also notes: if you use Prisma only, you can turn the Data API off in the API settings. Then none of this applies.

Sources

• Supabase docs: Prisma, read 2026-11-10
• PostgreSQL manual: ALTER DEFAULT PRIVILEGES, 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
• Our own test: the behaviour the reference pages describe, run against PGlite, read 2026-11-10