Supabase RLS not working or returning an empty array: causes and safe fixes

When Supabase returns [] for a table you know has rows, Row Level Security is usually working as designed: no policy matched the request, so Postgres showed nothing. The fix is to find out why no policy matched (no SELECT policy, no signed-in user, or the policy checks the wrong column) and correct that, not to switch RLS off or add using (true).

Supabase’s own troubleshooting note lists the same three causes. Below is how to tell which one you have, and a fix for each that keeps the table closed to strangers.

First, see what your app actually sees

The SQL editor bypasses RLS, which is why queries “work there”. Run the same query as your app’s role inside a transaction (nothing is saved):

begin;
set local role authenticated;
select set_config('request.jwt.claims',
  '{"sub":"PASTE-A-REAL-USER-UUID","role":"authenticated"}', true);

select auth.uid();                 -- should print that uuid
select * from public.todos limit 5; -- what that user can see

rollback;

Then list the policies on the table:

select policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public' and tablename = 'todos';

Cause 1: there’s no SELECT policy

With RLS on, any action without a matching policy is refused. Postgres calls this default deny: no rows are visible. A table with only an INSERT policy accepts new rows and then returns nothing when you read it.

Fix: add a SELECT policy scoped to the owner.

create policy "todos: read own"
  on public.todos for select to authenticated
  using ((select auth.uid()) = user_id);

Cause 2: the request has no signed-in user

If the query runs before the Supabase client has restored the session, or from a server without the user’s token, it goes out as anon. auth.uid() is then null, an owner check can never be true, and you get [].

How to tell: Supabase suggests calling a tiny function that returns the JWT next to the failing query:

create or replace function public.debug_whoami()
returns jsonb language sql stable as $$ select auth.jwt() $$;
-- In your app: const { data } = await supabase.rpc('debug_whoami')
-- role "anon" (or no sub) means no user session was sent.
-- Drop it when you're done:
-- drop function public.debug_whoami();

Fix: wait for the session before querying (for example, run the query after supabase.auth.getSession() resolves or inside an onAuthStateChange handler), and on a server, create the Supabase client with the user’s access token rather than without one.

Cause 3: the policy compares the wrong thing

Common slips in AI-generated policies:

• Checking id instead of user_id (or the other way round). On profiles the user’s id is usually id; on most other tables it’s user_id, owner_id or author_id.
• The owner column is text while auth.uid() is a uuid. Make the column uuid, or compare (select auth.uid())::text.
• Rows were inserted without an owner (user_id is null), so they can never match. Give the column a default: alter table public.todos alter column user_id set default auth.uid();
• The policy is to anon but the user is signed in (or vice versa). anon and authenticated are separate roles.

Cause 4: your update or delete “succeeds” but nothing changes

An UPDATE has to find the row first, and finding is a read. Supabase’s docs say an UPDATE needs a matching SELECT policy, and Postgres applies SELECT policies whenever an update reads the table (its where clause does). With no SELECT policy, the update matches 0 rows and returns no error.

Fix: make sure there’s a SELECT policy for the same user, and give the UPDATE policy both using and with check:

create policy "todos: update own"
  on public.todos for update to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

The same applies to .insert(...).select(): returning the new row requires it to pass a SELECT policy. If it doesn’t, the insert typically fails with a new row violates row-level security policy error, the same message you get when the INSERT policy’s with check fails, so check both.

Cause 5: you’re reading through a view or a join

• Views run as their owner by default and bypass RLS. On Postgres 15 and later, create them with with (security_invoker = true) so they respect the policies of the tables underneath. Then the view returns only what the user could read from those tables, which can be empty if one of them lacks a policy.
• Embedded joins (select('*, profiles(*)')) apply RLS to each table separately. If profiles has no readable rows for this user, the nested part comes back null or empty.

Cause 6: it really is a filter

Before blaming RLS, remove your .eq() / .match() filters one at a time. A filter that matches nothing also returns [].

Fixes that make things worse

Copy-paste policies for profiles, posts, orders, messages and file uploads are in our Supabase RLS policy examples.

Prompt for your AI builder

My Supabase query on <table> returns an empty array. Do NOT disable RLS and do NOT
add "using (true)". Instead:
1. Show me the current policies on <table> (pg_policies).
2. Check the request is made with a signed-in user's session.
3. Make sure there is a SELECT policy comparing the owner column with
   (select auth.uid()), and that UPDATE policies have USING and WITH CHECK.
4. Check the owner column is uuid and is filled in on insert.
Show me the SQL before running it.

FAQ

Check it for free

Once your app works again, make sure the fix didn’t open anything. Our free scan tests what an anonymous visitor can read from your Supabase tables and storage (after you verify you own the app), and the RLS audit SQL lists every table with RLS off or a using (true) policy. Run a free scan.