Error fixes / Supabase
Supabase
Supabase: new row violates row-level security policy
Postgres refused an insert because row level security is on and no policy allows that row.
The error
new row violates row-level security policy for table "profiles"
What it means
Row level security is doing its job. The insert reached Postgres, the table has RLS enabled, and none of the policies evaluated to true for the new row. The usual reasons in an app built with Lovable, Bolt or an agent are: there is no INSERT policy, the policy checks auth.uid() but the request was made with the anon key and no session, or the row's user_id does not match the signed-in user.
Fix
- In the Supabase Table Editor, confirm RLS is enabled on the table named in the error. Leave it enabled.
- Open Authentication and confirm the browser request is sending a signed-in user. In the app, log the result of getSession() without printing the access token. A null session means the policy cannot see auth.uid().
- In the SQL editor, look at policies for that table. You need an INSERT policy whose WITH CHECK expression matches the row you send, often user_id = auth.uid().
- Make the client send the owner column. If the policy expects user_id and the insert omits it, the check fails.
- Do not 'fix' this by turning RLS off, and do not move the service role key into the browser. That hides the error by making the table public.
Prompt
Fix prompt
The app fails with: new row violates row-level security policy for table "profiles". The table name in the real error may differ. Do not disable row level security. Do not put the service role key in client code. Find the insert that fails and the matching Supabase SQL. Add or adjust an INSERT policy so the signed-in user can insert only a row whose owner column equals auth.uid(). Set that owner column in the insert from the session, not from an unchecked form field. If there is no session, fix the sign-in flow instead of opening the table. Tell me the policy SQL and how to retry the action while signed in. Do not print keys.
Questions
Should I turn row level security off to make the insert work?
No. The error means the table is closed to rows the policy does not allow. Turning RLS off lets the anon key read and write every row. Add a policy that matches the signed-in user.
Why does the same insert work in the SQL editor?
The SQL editor runs as a privileged role and bypasses RLS. The browser uses the anon key and the user's JWT, so policies apply. Test with the client, or with a request that sends the user JWT.
The policy uses auth.uid() but the value is null. What does that mean?
The request is not signed in, or the session was not attached to the Supabase client. Sign in first, and create the client with the user session rather than only the anon key and no auth.