Home / RLS / Fix: new row violates row-level security policy

Supabase RLS · Error fix

Fix: new row violates row-level security policy

01 Why you're seeing this

Postgres throws new row violates row-level security policy for table "…" when Row-Level Security is on and the row you're writing isn't allowed by any policy's WITH CHECK expression. RLS on with no matching policy means deny — the safe default doing its job, not a bug. It fires on INSERT and on UPDATE (when the updated row would move outside what you're allowed to write).

02 The fix

Give the table an INSERT policy that lets a signed-in user write their own rows, and make sure the row carries their id.

migration.sql

-- 1. RLS on (safe to run if it already is)
alter table notes enable row level security;

-- 2. a signed-in user may insert rows that belong to them
create policy "owner inserts own notes" on notes for insert
  with check (user_id = (select auth.uid()));

Let the database fill the id so the client can't get it wrong:

migration.sql

alter table notes
  alter column user_id set default (select auth.uid());

insert.ts

// with the default above, just don't send user_id
await supabase.from('notes').insert({ title });

// or set it explicitly from the signed-in user
const { data: { user } } = await supabase.auth.getUser();
await supabase.from('notes').insert({ title, user_id: user.id });

If cause 3 is yours, the fix is upstream: create the Supabase client with the user's session (their JWT), not the bare anon key — on the server, forward the request cookies so auth.uid() resolves.

03 The gotcha — USING vs WITH CHECK

• USING filters rows the user can see or affect — SELECT, UPDATE, DELETE.
• WITH CHECK validates rows the user is writing — INSERT and UPDATE.

An INSERT policy with only USING and no WITH CHECK doesn't permit the write — that throws this exact violation. For UPDATE you usually need both: USING to pick the row, WITH CHECK so the user can't edit it into someone else's.

04 Prove it — don't hope

A policy you didn't test is a policy you don't have. Sign in as tenant A, confirm you can write your own row, and confirm you can't write one for tenant B.

Run that against a real Postgres in CI on every migration, so a table that ships without a correct write policy turns the build red before production.

FAQ