---
title: "Multi-tenancy com Supabase RLS: como isolamos dados de 6 produtos"
description: "Como a NTLabs usa Row Level Security do Supabase para isolar dados de 6 produtos no mesmo banco — e os erros comuns que evitamos."
author: "Anderson Henrique"
date: "2025-12-10T11:00:00Z"
updated: "2026-04-08T14:36:02.919029Z"
category: "bit-by-bit"
tags: ["supabase","rls","multi-tenancy","seguranca"]
canonical: "https://www.ntlabs.dev/blog/bit-multi-tenancy-supabase-rls"
locale: "pt"
---

Quando você tem 6 produtos rodando no mesmo banco de dados, a pergunta mais importante é: **como garantir que o dado do produto A nunca vaze para o produto B?**

A resposta: Row Level Security (RLS) do Supabase.

## O que é RLS?

RLS é uma feature do PostgreSQL que aplica filtros automáticos em toda query. Em vez de confiar que seu código sempre filtra por `tenant_id`, o banco faz isso por você.

```sql
CREATE POLICY "tenant_isolation" ON appointments
  USING (tenant_id = current_setting('app.current_tenant')::uuid);
```

Mesmo que um bug no código esqueça o filtro, o PostgreSQL bloqueia o acesso.

## Como implementamos

1. Todo request seta `app.current_tenant` via middleware FastAPI
2. RLS policies em todas as tabelas multi-tenant
3. Testes automatizados verificam isolamento entre tenants
4. Admin queries usam `service_role` (bypassa RLS) com auditoria

## Erros comuns

- **Esquecer RLS em tabelas novas**: criamos um advisor que alerta tabelas sem policy
- **Usar service_role no frontend**: NUNCA. Só anon key no client
- **Policies muito permissivas**: `USING (true)` derrota o propósito

**RLS não é feature — é infraestrutura de segurança.** Se você tem multi-tenancy sem RLS, você tem um vazamento de dados esperando acontecer.