Erro new row violates row level security policy (Supabase): como resolver

“new row violates row level security policy” significa que o Supabase recusou gravar a linha. O RLS está ligado e nenhuma política de INSERT autoriza aquele registro. O caso comum é a tabela profiles: a política pede auth.uid() igual a user_id e o insert manda outro valor, ou a política de INSERT não existe. Não desligue o RLS.

O código Postgres desse erro é 42501. Desligar o RLS faz a mensagem sumir e deixa a tabela aberta para quem tiver a chave anon. Não faça isso para “destravar”.

Por que a IA cai nesse erro

O gerador cria a tabela e o insert no mesmo passo. A política, quando vem, costuma copiar um exemplo de SELECT e esquecer o INSERT. Aí o cadastro quebra no primeiro usuário. Pedir “arruma o RLS” de novo, sem dizer a tabela e a coluna, faz a IA reescrever a política e queimar crédito no mesmo loop.

Seu banco também pode estar exposto do outro lado: RLS desligado, e qualquer um com a chave anon lê a tabela. Os dois problemas moram no mesmo lugar. Um trava o insert. O outro entrega o dado.

Passo a passo

1. Leia a mensagem inteira. Ela cita a tabela. Anote o nome (profiles, users, objects no Storage). Não cole a chave do projeto em fórum.

2. Abra Authentication e confirme que há sessão. Sem usuário logado, auth.uid() é nulo e toda política de authenticated recusa. Se o insert roda antes do login terminar, espere a sessão.

3. Confira a coluna que a política compara. Se a política diz auth.uid() = user_id, o insert precisa enviar user_id igual ao id da sessão. Nome diferente (uid, owner, id) faz a linha violar a política mesmo com você logado.

4. Crie a política de INSERT sem desligar o RLS. No SQL Editor, para uma tabela em que cada pessoa só escreve a própria linha:

alter table public.profiles enable row level security;

create policy "insert da propria linha"
on public.profiles
for insert
to authenticated
with check (auth.uid() = user_id);

Ajuste o nome da tabela e da coluna. SELECT e UPDATE pedem política própria, com using, não só with check. Guia oficial: Row Level Security.

5. Teste com o usuário logado, não com a service_role. A service_role ignora o RLS. Se o teste “passa” só com ela, o app no navegador continua quebrado. E essa chave não pode ir para o client.

Prompt para colar

O insert na tabela profiles falha com "new row violates row level security policy" (42501). Não desligue o RLS e não use a service_role no browser. A coluna do dono é user_id. Crie políticas de SELECT, INSERT e UPDATE para authenticated em que auth.uid() = user_id. O INSERT usa with check. Mostre o SQL antes de aplicar e não mude outras tabelas.

Troque profiles e user_id pelos nomes do seu projeto. No Storage, a política fica no bucket, não numa tabela sua.

Perguntas frequentes

O que significa new row violates row level security policy?

O Postgres barrou o INSERT. Existe RLS e a linha nova não passou no with check de nenhuma política. Ou não há política de INSERT para o papel que está escrevendo (em geral authenticated).

supabase 42501, e agora?

É o mesmo erro. Abra a tabela citada, veja se o RLS está on e se existe política de INSERT com a coluna certa. Não rode disable row level security para o cadastro voltar.

Preciso desligar o RLS para o app funcionar?

Não. RLS desligado é o cenário em que o banco fica legível com a chave anon. Corrija a política. Se a tabela guarda dado de outra pessoa, a política não pode ser using (true).

Deu erro e eu preciso de um dev?

Na maioria desses casos, não. O SQL acima e o prompt resolvem o cadastro da própria linha. Chame alguém se a regra é mais fina (só o dono da organização, papel admin, arquivo no bucket de outro usuário) e você não sabe descrever quem pode ver o quê.