Fix · Supabase and databases

Insert fails: new row violates row-level security policy

Blocks your work

What you may see

Saving a form or creating a record fails for logged-in or anonymous users
My app cannot save the form data into the database table
The error mentions row-level security or a policy

Most likely cause

Row level security is on for the table, and no policy lets this kind of user (anonymous or logged in) add that row.

Check first (about two minutes)

In the Supabase dashboard open the table's policies page: is there an INSERT policy? (the page may be labelled differently)
Check which role makes the call: logged out (anon) or logged in (authenticated).

The fix prompt

What you type here never leaves your browser. The search runs on this page, and nothing is sent to a server or to an AI.

The exact error or what you see

What you did before it happened

Kept only in this browser, on this device. Keys and passwords are removed before anything is saved.

Prompt language

You are a careful senior engineer who knows Supabase (database, login and file storage) and explains it to people who are not developers. I am not a developer, so explain every step in plain words and tell me exactly which button, menu or command you mean. If you are not sure about something, say so; do not guess.

THE PROBLEM
Insert fails: new row violates row-level security policy

THE EXACT ERROR OR WHAT I SEE
[paste the exact error here]

WHAT I DID BEFORE IT HAPPENED
[write in a few words what you did before it happened]

MOST LIKELY CAUSE
Row level security is on for the table, and no policy lets this kind of user (anonymous or logged in) add that row.

DO THESE STEPS, IN THIS ORDER
1. Show me the table definition and its current policies (use the SQL editor or migration files).
2. Tell me who SHOULD be allowed to insert (anyone, logged-in users, only the owner of the row) and ask me if unclear.
3. Write the narrowest INSERT policy with a WITH CHECK clause that matches (for example user_id = auth.uid()), for the right role only.
4. Give me the policy as a migration file and tell me how to test it as a normal user, not as the admin.
Stop and tell me if what you see does not match a step. Do not skip ahead.

CHECK THAT IT WORKED
- An insert as a normal user succeeds, and an insert for someone else's id still fails.
Tell me exactly what I should see on the screen when it works.

DO NOT CHANGE
- Do not turn row level security off.
- Do not use the service role key in the browser to get around it.
- Anything I did not ask about: the design, the text, other pages, other settings or the data.
- Do not delete files, data or branches, do not reset or force-push, and do not rewrite history, unless you first show me exactly what would be lost and I say yes.
- Do not paste, print or ask me to paste a password or secret key into this chat. If one is needed, tell me which settings page of the right service to store it in.

WHEN YOU FINISH
Explain in simple words what you changed (file by file or setting by setting), why you changed it, and how I can undo it.

Paste it into Claude, ChatGPT, Gemini or Cursor, then follow what it says.

After you tried it, did it work?

Steps

Show me the table definition and its current policies (use the SQL editor or migration files).
Tell me who SHOULD be allowed to insert (anyone, logged-in users, only the owner of the row) and ask me if unclear.
Write the narrowest INSERT policy with a WITH CHECK clause that matches (for example user_id = auth.uid()), for the right role only.
Give me the policy as a migration file and tell me how to test it as a normal user, not as the admin.

Do not do this

Do not write a policy with using (true) for all roles on a table with private data.
Do not turn row level security off.
Do not use the service role key in the browser to get around it.

Try another entry