If Supabase returns 42P17 or infinite recursion detected in policy for relation, the useful question is not whether Supabase is broken.
The useful question is: which Row Level Security policy causes PostgreSQL to evaluate another policy that eventually leads back to the first one?
The short answer
Supabase’s current RLS documentation explicitly warns about recursive policies. Two protected tables whose policies read each other may never resolve, and a policy that reads its own protected table can create the same class of problem.
PostgreSQL detects the loop and stops the query with 42P17 rather than evaluating policies forever.
The safe fix is usually to break the policy dependency cycle, not disable RLS.
Think of the failure as a chain:
request → table → RLS policy → permission lookup → another protected table or policy → back to the original policy
Find the loop before changing application code.
Why it can look like an authentication bug
A user can sign in successfully and still see an empty dashboard or failed request because the first protected query hits a recursive policy.
That is why this is easy to misdiagnose in an AI-built app. A prompt such as “fix login” may rewrite route guards even though authentication already succeeded.
Inspect the failing request and database error first. If the error names a relation, begin with the policies protecting that relation and every protected table those policies read.
The two common recursion shapes
A policy reads its own table
Imagine a memberships table recording which user belongs to which workspace. A policy on memberships queries memberships again to discover the current user’s workspaces.
Reading that inner query requires the same policy to be evaluated again. The policy has called itself.
Two policies read each other
Suppose a policy on projects checks project_members, while a policy on project_members checks projects to confirm ownership.
The chain becomes:
projects → project_members → projects
Neither rule necessarily looks self-referencing when viewed alone. The problem becomes obvious when you draw the dependency.
1. Reproduce the failing operation as the real role
Test the exact operation the application performs: SELECT, INSERT, UPDATE or DELETE.
Use the same authenticated or anonymous role that experiences the failure. A privileged database role can behave differently and hide the authorization path you need to inspect.
The goal is to separate application failure from policy failure.
2. Map the policy dependency chain
List every policy on the relation named in the error.
For each policy, write down every table, view or helper it reads. If policy A reads table B, inspect B’s policies too. Continue until the chain ends or returns to something you already visited.
A small sketch such as:
memberships → teams → memberships
is often more useful than another broad debugging prompt.
3. Prefer the simplest non-recursive rule
Not every authorization decision needs another database lookup.
If access can be decided from the current row and the authenticated user’s ID, keep the policy simple. Ownership checks often only need the row’s owner ID and the current user ID.
The fewer protected relations a policy needs to inspect, the easier the authorization model is to reason about and test.
4. Make membership and authority explicit
Multi-tenant products often need owners, managers and members with different access.
Trying to derive all of that by repeatedly querying the protected resource table can create circular rules. A dedicated membership or access model can make the authority relationship clearer, but its own policies still need a non-recursive design.
The principle is: a policy should not need to ask itself whether it has permission to answer the permission question.
5. Use privileged helpers carefully when they are genuinely needed
Supabase’s troubleshooting guidance describes a privileged helper function as one possible way to break recursive evaluation when a permission lookup genuinely needs to read protected data.
That changes the security boundary, so keep the helper narrow. It should answer a specific permission question, expose no more information than necessary, have controlled privileges, and be tested as normal application users.
The purpose is to break recursive policy evaluation, not to remove authorization.
Do not fix this by turning RLS off
Disabling RLS can make the failing query start returning data immediately. That does not prove the app is fixed. It proves the security layer that rejected the query is gone.
Likewise, do not move a privileged server credential into browser code just to make requests pass.
If you are unsure which Supabase keys belong in client code, read Is Your Supabase Anon Key Safe to Expose?.
6. Test denied users after the recursion is gone
Removing 42P17 is only half the job. A policy can stop recursing and still allow the wrong person to access data.
Test at least:
- an owner who should have access
- a legitimate member with narrower access
- another authenticated user who should be denied
- an anonymous request when authentication is required
For tenant-scoped products, also test a user from tenant B against tenant A’s records.
This is why my AI-built app production checklist treats permissions as a production requirement rather than final polish.
If the error appears during a Storage upload
A Storage policy can depend on one of your application tables. If that table’s policy chain is recursive, a file operation can surface the database recursion indirectly.
If your actual problem is a normal 403 or new row violates row-level security policy, use the separate Lovable/Supabase Storage 403 guide. That article owns upload permissions; this one owns 42P17 policy recursion.
Before you deploy the fix
Confirm that the original operation no longer returns 42P17, RLS remains enabled where required, intended users can perform the operation, unrelated users cannot cross the access boundary, anonymous access behaves as intended, and the interface handles denied requests clearly.
If you are using Lovable, Codex or another AI coding tool, turn those expectations into explicit tests. “Make RLS work” is too vague. Specify the roles, resources, allowed actions and denied cases.
The larger lesson
RLS recursion is rarely only a syntax problem. It can be a warning that the authorization model has become difficult to explain.
When several protected tables are needed merely to decide whether one protected table may be read, draw the access model before adding more generated code.
That is the same principle I use when taking an AI-built MVP toward production: make ownership, roles and security boundaries explicit first.
If a product works in demos but permissions or tenancy are becoming difficult to reason about, see my MVP development service or contact me. The useful work is usually identifying the boundary that needs redesign, not rebuilding everything.
