Owner-only table

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

What you need first

A column that stores the user's id as a uuid, here user_id. auth.uid() returns the id of the user making the request, and returns null when nobody is signed in.

Why four policies

to authenticated stops the policy from running for signed-out requests. Wrapping the call as (select auth.uid()) lets Postgres evaluate it once per statement instead of once per row; both forms come from Supabase's RLS guide.

We ran this SQL against Postgres on 2026-11-10: a second user read zero rows, and an insert with another user's id was rejected.

Sources

• Supabase docs: Row Level Security, read 2026-11-10
• Supabase docs: Securing your API, read 2026-11-10
• Our own test: generated SQL run against PGlite (Postgres compiled to WebAssembly), read 2026-11-10