aiRepoFix / How-to fixes

Supabase returns an empty array, or says "new row violates row-level security policy": how to fix it

Last checked against vendor documentation: October 17, 2026.

How to tell what you are seeing

Supabase's API keys guide describes this split: a missing grant returns a permission error, whereas a policy that matches no rows returns an empty result. Supabase's RLS guide says the same about a using rule that filters rows out: it raises nothing and matches zero rows. Check the grant first, then the policy.

Why it happens

The PostgreSQL docs say that when RLS is enabled on a table, all access must be allowed by a policy, and if no policy exists a default-deny policy applies, so no rows are visible or modifiable. Supabase says the same: once RLS is enabled, no data is accessible through the API with a publishable key until you create policies.

Also keep in mind:

• Filtering is silent for reads, updates and deletes. Rows that fail a policy's using rule are simply not returned, updated or deleted, and no error is raised. Your app can't tell "no rows" from "rows I'm not allowed to see". Only inserts, and updates that break a with check rule, raise an error. We confirmed this on a local PostgreSQL test database: with RLS on and no policies, a select returned nothing, an insert raised 42501, and an update and a delete each affected zero rows with no error.
• Your SQL Editor test may look fine. Supabase notes that its postgres role has bypassrls, and the PostgreSQL docs say such roles bypass RLS. The SQL Editor typically runs with elevated rights, so a query can show rows there and nothing in your app.
• Not signed in means no match. auth.uid() is null when no user is signed in, so auth.uid() = user_id never matches. A policy written to authenticated also doesn't apply to signed-out requests.
• Updates need a read policy too. Supabase warns that an UPDATE needs a matching SELECT policy to work as expected.

Find the missing policy

1. List the policies on the table in the SQL Editor:

   select policyname, cmd, roles, qual, with_check
   from pg_policies
   where tablename = 'your_table';

   Look for a policy whose cmd matches what you're doing (SELECT, INSERT, UPDATE, DELETE, or ALL) and whose roles includes the role your request uses (anon for signed-out users, authenticated for signed-in users).
2. Confirm the user is actually signed in when the request runs. If your app calls the database before the session has loaded, it will run as anon.
3. Test as that user inside a transaction (nothing is saved):

   begin;
   set local role authenticated;
   set local request.jwt.claim.sub = 'PASTE-A-USER-UUID-HERE';
   select * from public.your_table;
   rollback;

   An empty result here, while the same query returns rows as postgres, confirms the policy is the cause. Supabase's guide uses the same set local role and request.jwt.claim.sub approach for tests.
4. Compare the policy rule with your data. For example, if the rule is auth.uid() = user_id, check the user_id column is filled in on your rows and matches the signed-in user's id. Inserts that leave user_id empty fail the check.

Fix: one policy per operation

This example fits a table where each signed-in user manages their own rows. Adjust the table and column names. Supabase recommends writing a separate policy for each operation and always naming the role with to:

alter table public.your_table enable row level security;

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

create policy "insert own rows" on public.your_table
  for insert to authenticated
  with check ((select auth.uid()) = user_id);

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

create policy "delete own rows" on public.your_table
  for delete to authenticated
  using ((select auth.uid()) = user_id);

• The table also needs grants for authenticated for the operations you use (see our 42501 page).
• For data that really is public (say, a list of published posts), Supabase's guide shows a read-only policy to anon, authenticated using (true). Use that only for data that is meant to be public.
• Wrapping auth.uid() as (select auth.uid()) is Supabase's recommended form for performance. Adding an index on the column the policy filters on (like user_id) also helps as the table grows.

Common mistakes

• Disabling RLS. It makes the error disappear and makes every row reachable by anyone who has a grant on the table. Supabase warns that a table in an exposed schema without RLS is readable and writable by any role with a grant on it.
• Writing using (true) for anon on private data. That lets every visitor read every row.
• Using the secret / service_role key in the browser to get around it. Supabase says this key bypasses RLS and must never be in a browser or source control.
• Assuming no error means it worked. An update or delete blocked by RLS reports success with zero rows changed. Check what came back, or read the row again.
• A policy for the wrong operation. An insert policy does not let you read rows back, and a to authenticated policy does nothing for signed-out requests.
• Creating policies only in the dashboard. Put policies in your migration files so they exist in every environment.
• Views. Supabase notes views can bypass RLS because they're usually created by the postgres user. On Postgres 15+, create them with security_invoker = true if they should respect the table's policies.

Sources

This page is based on the vendor documentation below. Menu names and defaults change, so check the source if something on your screen looks different.

• Supabase docs: Row Level Security
• Supabase docs: API keys (grants vs. policies, secret keys)
• Supabase docs: Securing your API
• Supabase JavaScript reference: update (return changed rows with select)
• Supabase troubleshooting: Database API 42501 errors
• PostgreSQL documentation: Row Security Policies

Last checked: October 17, 2026. aiRepoFix is not affiliated with or endorsed by the companies named on this page.