Guide
Bolt form not saving: "new row violates row-level security policy"
Updated
"new row violates row-level security policy" means row-level security is on for the table and no rule allows this visitor to add the row. Bolt turns row-level security on for the tables it creates. The fix is a rule that lets visitors submit to that table and nothing more, which Bolt's Security page can write for you.
Why it happens
Once row-level security is on, Supabase says no data is accessible through the API with the public key until you create policies. Each kind of action (read, add, change, delete) needs its own rule, and a rule for signed-in people does not cover signed-out visitors.
The causes, and how to fix each
1. The table has no rule that lets visitors add a row
A contact form or review form is used by visitors who are not signed in. One of the three access levels Bolt lists is "Visitors can submit information": they can add data but not read or change other submissions.
How to fix it
- In your Bolt project, click the database icon at the top center of the screen, then Security.
- Ask Bolt to limit the form's table to "Visitors can submit information".
- If Bolt found issues, click Ask Bolt to fix, then open Security again to check.
Source: Bolt: Database security
2. There is a rule for adding, but its check fails
An insert rule's with check condition must accept the new row. A rule written for signed-in people (for example, the row's user must equal the signed-in user) refuses a signed-out visitor.
How to fix it
- Make sure the insert rule is for the role that actually submits the form: signed-out visitors (anon) or signed-in people (authenticated).
- Check that the with check condition is true for the row the form sends.
Source: Supabase: Row Level Security
3. The form asks for the saved row back, and there is no read rule
By default an insert does not return the new row; chaining .select() asks for it. Reading the row back needs a read rule too, which a submit-only table should not have.
How to fix it
- If the form only needs to submit, remove the .select() after the insert.
- Only add a read rule if visitors really should see what was submitted.
Source: Supabase JavaScript reference: insert() · Supabase JavaScript reference (v1): insert() and policies
4. A table was added later without its rules
Bolt turns row-level security on for the tables it creates and says to check that it is enabled for tables you add yourself.
How to fix it
- Open Security in Bolt and look for the new table.
- Choose its access level (view only, submit, or private) and ask Bolt to update the policies.
Source: Bolt: Database security
5. The opposite problem: a rule that lets everyone do everything
On sites without sign-in, Bolt may write rules that let any visitor view, add, change and delete data. Bolt flags these as "RLS Policy Always True", and Bolt says its scan uses the same database checks as Supabase's Security Advisor.
How to fix it
- If Security shows "RLS Policy Always True" on a table that stores submissions, ask Bolt to limit it to one of the access levels.
- Data that must stay private needs sign-in added to the app.
Source: Bolt: Database security · Supabase: Performance and security advisors
Why you can't see it yourself
You're signed in, your customers aren't. You test as the owner or while signed in, under different rules from a signed-out visitor. The visitor's submission is the one that is refused.
Frequently asked questions
What does "new row violates row-level security policy" mean?
Row-level security is on for the table and no insert rule accepted this row for this visitor. Add an insert rule for the role that submits, with a condition the row meets.
Why can't signed-out visitors submit my form after row-level security was turned on?
With row-level security on and no rules, nothing gets through with the public key. Visitors need an insert rule for the anon role.
Do I need a read rule to add a row?
Only if the app asks for the new row back. By default an insert does not return it; chaining .select() does, and that needs a read rule.
Is a rule that always allows everything safe?
Bolt says it is acceptable only if you are comfortable with every visitor being able to change or delete that data. Bolt flags it on its Security page.
Can Bolt fix this for me?
Bolt's Security page lists the problems and has an Ask Bolt to fix button, and you can ask it to set a table to view only, submit or private.
Sources (official documentation)
- Bolt: Database security
- Supabase: Row Level Security
- Supabase JavaScript reference: insert()
- Supabase JavaScript reference (v1): insert() and policies
- Supabase: Performance and security advisors
Related guides
- Data won't save: "new row violates row-level security policy"
- Row-level security error saving a profile right after sign-up
- Supabase "permission denied for table" (42501)
- Edits or upserts blocked by row-level security
- Users can see other users' data in my Lovable app
- Is a secret key or admin page visible on my live app?
VibeFix is independent. Bolt and Supabase are trademarks of their owners.
Fixed it? Prove a real stranger gets in
A fix that works from your own account proves nothing about a new customer. Your AI reads your code. VibeFix signs up like a stranger.
Free check. Paste your live app's link: an AI agent signs up to your live app once as a brand-new person ("VibeFix Test") with a real inbox of its own, on a phone and on a computer, and shows how many problems a new user still hits, what each one is, and one screenshot. No account needed. It never changes your app and never emails your users.
Want it fixed?
Our AI agent finds the cause, fixes it in your code and re-checks your live app. $79 for one bug, paid up front. If we can't complete your re-check, you get your money back.
It starts with a free check that confirms the problem on your live app, no account needed.