Supabase RLS not working? Causes and fixes

Symptom: empty list, no error

1. RLS is on, but there's no select policy

With RLS on and no policy for reading, every select returns nothing. This happens a lot right after an AI tool or the dashboard enables RLS without adding rules.

create policy "Owners read their rows" on public.notes
  for select to authenticated using ((select auth.uid()) = user_id);

Symptom: "new row violates row-level security policy"

2. Insert fails because the new row doesn't pass the check

An insert policy's with check must be true for the new row. If your app doesn't set user_id, it's empty and the check fails. Let the database fill it in:

alter table public.notes alter column user_id set default auth.uid();

create policy "Owners add their rows" on public.notes
  for insert to authenticated with check ((select auth.uid()) = user_id);

Still failing on .insert(...).select()? Returning the new row also needs a select policy that lets the user see it (cause 1).

Symptom: update or delete "works" but nothing changes

3. The user can't see the row they're changing

An update or delete can only touch rows the user is allowed to see. With no select policy, or no update policy whose using rule matches the row, it changes zero rows and still reports success. Add the select policy from cause 1, then:

create policy "Owners edit their rows" on public.notes
  for update to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

Symptom: works when logged in, empty on the server

4. The request isn't carrying the user's login

auth.uid() comes from the user's login token. In server code, edge functions or API routes, a Supabase client created with only the public key runs as a stranger, so auth.uid() is null and owner-only rules match nothing. Pass the user's token through (for example the request's Authorization header) when you create the client there. Don't swap in the service_role key to make it work: that skips RLS for everyone.

Symptom: "infinite recursion detected in policy"

5. A policy reads its own table

A common one: a policy on profiles checks whether the user is an admin by selecting from profiles, which runs the policy again. Move the check into a function that runs with full rights, kept in a schema your API doesn't expose:

create schema if not exists private;

create or replace function private.is_admin()
returns boolean
language sql stable security definer set search_path = ''
as $$
  select exists (
    select 1 from public.profiles
    where id = (select auth.uid()) and role = 'admin'
  );
$$;

grant usage on schema private to authenticated;
grant execute on function private.is_admin() to authenticated;

create policy "Admins read all profiles" on public.profiles
  for select to authenticated using ((select private.is_admin()));