SupabaseDatabaseAuth

Supabase: new row violates row-level security policy

new row violates row-level security policy for table "todos"

In short: Row Level Security is on for that table, but no policy allows this user to insert (or update) this row.

Why it happens

Supabase tables exposed through the API should have RLS enabled. With RLS on and no matching policy, every write is refused. Common reasons: there is only a SELECT policy; the insert doesn't set user_id, so auth.uid() = user_id fails; the user isn't actually signed in (requests run as anon); or an upsert also needs an UPDATE policy.

How to fix it

  1. In the Supabase dashboard, open Authentication → Policies (or Database → Policies) for the table and check which operations have policies.
  2. Add an INSERT policy with a WITH CHECK clause for signed-in users, matching the owner column.
  3. Make sure the insert sets the owner column, or give the column a default of auth.uid().
  4. Confirm the client request carries the user's session (signed in before the insert, same Supabase client instance).
  5. For upsert, add a matching UPDATE policy too.

Example

alter table public.todos enable row level security;

create policy "Users insert own todos"
on public.todos for insert to authenticated
with check ( (select auth.uid()) = user_id );

create policy "Users read own todos"
on public.todos for select to authenticated
using ( (select auth.uid()) = user_id );
Don't: Don't disable RLS or switch to the secret (service_role) key in the browser to make the error go away. That makes the table readable and writable by anyone with your public key.

Copy-paste fix prompt

Paste into Cursor, Claude Code, Codex, Lovable, Bolt, Replit or v0
I'm getting this error in my app:

new row violates row-level security policy for table "todos"

[Paste the full error, stack trace, and the file it points to here]

Likely cause: Row Level Security is on for that table, but no policy allows this user to insert (or update) this row.

Task: Read the table schema and existing RLS policies for the table named in the error. Write the minimal SQL policies (insert/update/select as needed) so a signed-in user can only touch their own rows. Don't disable RLS and don't use the secret key in client code.

Rules:
- First explain the root cause in 2 sentences and list the files you'll change.
- Make the smallest change that fixes it. Don't refactor unrelated code.
- Don't disable security or checks (RLS, auth, signature verification, type checking, CORS allow-all) to make the error disappear.
- Never print or hard-code secret keys.
- Finish by telling me exactly how to verify the fix.

Common with: Lovable, Bolt, Cursor, v0. Last reviewed 2026-11-13.

Related fixes

← All fixes · Still stuck? Use the diagnose-first prompt