"Infinite recursion detected in policy" without disabling RLS

You turned Row Level Security on, wrote a rule so that admins can see every profile and everyone else sees only their own, and now not a single screen in your app loads. Every read comes back with the same line:

infinite recursion detected in policy for relation "profiles"

Most of the answers you will find say the same thing, and it is the wrong thing: turn Row Level Security off on that table until you have worked it out. The error does stop. What stops it is that the table is now readable by anyone who visits your site.

What "infinite recursion detected in policy for relation" means

A rule on a table had to read that same table before it could answer.

Picture a doorman who checks every visitor against a guest list, and the guest list is kept inside the room he is guarding. To read the list he has to go in. To go in he has to check the list. There is no first step, so he stands in the corridor and nobody gets anywhere.

That is what your database ran into. It was asked for some rows from profiles, went to the rule on profiles to find out which ones you were allowed to see, and the rule told it to look in profiles. Postgres spots that it is going round, gives up, and raises the error with the code 42P17 attached. Supabase hands it to your app unchanged, which is why it reads like machinery.

The query fails for everyone the rule applies to, so this usually arrives as a whole app going blank at once rather than as one broken screen.

The circle, drawn

The rule that does it is the one almost everybody writes first, because it says exactly what you mean:

-- Reject: this reads profiles in order to decide who may read profiles.
create policy "admins read every profile" on profiles for select
to authenticated
using (
  exists (
    select 1 from profiles
    where id = (select auth.uid()) and role = 'admin'
  )
);

The exists (select 1 from profiles …) is the whole problem. Reading profiles means applying the rule on profiles, which runs exists (select 1 from profiles …) again.

Supabase's own Row Level Security guide names the two-table version of this: policies on two tables that each read the other never resolve, and the query fails for every role the policies apply to. One table reading itself is the same shape with the detour removed.

Why does this always happen on the profiles table?

Because profiles is where "who is this person" is kept.

Any rule that treats one kind of person differently from another has to find out which kind the caller is, and that fact lives in a column on some table. Whatever that table is called, the rule protecting it ends up reading it. In an app built with Lovable, Bolt, v0 or Replit it is usually profiles, because that is where the row about each signed-in person goes. A rule about teams, organisations or shared documents produces the same circle on whatever table holds the membership.

So the recursion comes out of writing the obvious rule about the one table that has to answer a question about itself.

The fix: a helper that reads the table from outside the rules

Move the question into a small function that runs as the database owner, so reading profiles to answer it does not go through the rule on profiles.

create schema if not exists private;

create function private.is_admin()
returns boolean
language sql
security definer      -- runs as the role that created it
set search_path = ''  -- so every name inside has to be written in full
stable
as $$
  select exists (
    select 1 from public.profiles
    where id = (select auth.uid()) and role = 'admin'
  );
$$;

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

-- The rule now asks the function instead of the table.
create policy "admins read every profile" on profiles for select
to authenticated
using ( (select private.is_admin()) );

The doorman now has the guest list on a desk in the corridor. He reads it without opening the door, and the door stays locked for everyone who is not on it.

Four lines in there are doing specific work, and three of them are the difference between a fix and a new hole:

• security definer is what breaks the circle. Supabase's guide defines it as a function that runs using the same role that created the function, and on Supabase that role is postgres, which can read past the rules.
• set search_path = '' belongs on every one of these. Supabase's guidance is to set it on every security definer function and write the table names out in full, because without a pinned search_path a caller can point an unqualified name at an object of their own and run it with the function owner's privileges. That is why the function writes public.profiles in full.
• The private schema matters for the same reason. Supabase's guide warns that a security definer function sitting in an exposed schema can be called over the Data API with the creator's privileges, and tells you never to create one in a schema listed under Exposed schemas in your API settings.
• (select private.is_admin()), wrapped in a select of its own. That lets Postgres work the answer out once for the whole statement instead of once per row, which Supabase documents as the reason to wrap auth.uid() the same way.

The revoke and grant lines keep the function callable by signed-in users and nobody else.

That policy covers reading. If saving starts failing once your screens fill up again, you have met a different message with a different cause.

The fix that is not a fix

Switching Row Level Security off on profiles also clears the error, in one click, and it hands every row in that table to anyone holding the key your app ships to the browser.

That key is meant to be public. It is in your site's code, and anybody can read it out in a few seconds. The thing that was stopping it from returning your whole user table was the rules you just switched off.

Your app looks the same afterwards either way, which is the part that makes this stick. Nothing on your screens says which of the two you chose, and the error is gone in both.

What does say so is your database, asked from outside. We have scanned 31,056 live apps built with Lovable, Bolt, v0, Replit and the rest, and could see a Supabase project behind 8,435 of them. This is what the Row Level Security check found:

The middle row is the honest one. On 4,755 of those apps the check got no answer and we say so rather than calling them fine. And some of the 2,096 are meant to be readable, because a public table is a real thing to want; from outside, a menu and a members list look identical.

We cannot tell you how many of those tables were opened by somebody clearing this exact error. We can tell you that an open table is the ordinary end state of the advice at the top of the search results.

If you would rather not reason about it, our free scan reads your live site and tells you which of your tables answer a stranger. It takes about 20 seconds and needs no account: scan your app.

One more thing happens when you switch it off. Supabase's own advisor starts reporting the table, which is the warning RLS disabled in public, and that warning will still be there in a month.

How to tell whether the circle is really gone

The error stopping is not the test, because two different things make it stop.

There is also a way for the helper function to look right and keep recursing, and Supabase documents it: a security definer function only skips the rules when its owner is allowed to. On Supabase the owner is postgres, which has that privilege, so the pattern above works. A function owned by a role without it, or one reading a table set to force row level security, goes back through the rule and stays in the circle.

Two checks, and do both:

Write the cases down and run them. Supabase's procedure is a .sql file under supabase/tests/ asserting allow and deny for each operation, for a signed-in user and for an anonymous one, run with supabase test db. An admin must see every profile, a member must see their own, a stranger must see nothing. Until that passes, what you know is that the error stopped.

Then ask from outside, with no login. That is the question a visitor's browser asks, and it is the only one that reflects what your app actually hands out. Whether a stranger can read your database walks through it, and Row Level Security can be on and the table still public covers the case where the rules exist and let everyone through anyway.

When the recursion is telling you the schema is wrong

Sometimes there is no circular question to remove, because the two tables really do depend on each other.

Supabase's guide uses sharing as the example: a rule on lists checks list_members to see who the list was shared with, and a rule on list_members checks lists to see who owns it. Each table's rule reads the other, and neither can go first. The same helper breaks it, with one function returning the list ids the caller belongs to, and both rules asking that function instead of asking each other.

The signal worth noticing is when you need three or four of these to make a schema work. At that point the membership is being rebuilt inside the rules every time, and a single table that states plainly who may see what is usually less to maintain than the rules you are untangling.

Keeping the table closed after you fix it

A rule you fixed today describes today's database. The next policy, the next table, and the next time somebody clears an error at midnight all happen after you last looked, and none of them changes anything you can see on your screens.

Reeve Monitor asks your app the same questions again, on a schedule:

• all nine checks every hour, on up to three apps
• a message when a result changes, so a table that opened last night does not wait for you to notice
• whether the app is up, every 60 seconds
• a monthly report of what it saw

If your app keeps its data in your own Supabase project, Reeve Care also keeps a copy of that database. A rule that lets a stranger read is one problem. A rule that lets a stranger write is the other one, and no check in this article brings deleted rows back.

• an encrypted copy of your Supabase database every night, kept where your project cannot reach it
• each copy verified before it counts, by counting the rows in every table
• a one-click restore when you need one
• your uploaded files as well, once you connect a Storage credential
• everything Monitor does

What to do right now

If you want the rest of the list for a newly launched app, the 10-minute security checklist covers this and the other things worth closing before anybody finds them.