Multi-tenant é a arquitetura em que um mesmo sistema atende muitos clientes ao mesmo tempo, cada um enxergando só os próprios dados. É o modelo por trás de praticamente todo SaaS, e também o ponto onde um descuido silencioso vira o pior incidente possível: o cliente A abrindo a tela e vendo os dados do cliente B.
A pergunta que decide o projeto não é se o sistema será multi-tenant, e sim onde o isolamento entre clientes é garantido. Amarrar isso só na aplicação, com um filtro de cliente repetido em cada consulta, funciona até o dia em que alguém esquece o filtro em uma query nova. Por isso a discussão séria começa em como travar o isolamento dentro do próprio banco de dados.
Os três modelos de multi-tenant
Existem três formas clássicas de separar os dados de cada cliente, e a escolha muda custo, complexidade e velocidade de manutenção. Não há opção universalmente melhor: há a que faz sentido para o seu número de clientes e para o seu apetite por risco.
- Banco por cliente: cada cliente tem seu próprio banco. Isolamento máximo, mas manutenção e migração viram um problema sério quando você passa de algumas dezenas de clientes.
- Schema por cliente: um banco só, com um schema separado por cliente. Meio-termo, porém ainda cria centenas de cópias da mesma estrutura para versionar e migrar juntas.
- Tabela compartilhada com coluna de cliente: todos os dados na mesma tabela, separados por um identificador (tenant_id). Mais simples de escalar e o modelo que a maioria dos SaaS usa hoje, desde que o isolamento não dependa apenas do código da aplicação.
Por que RLS virou o padrão para isolar dados
No modelo de tabela compartilhada, o Row Level Security (RLS) do PostgreSQL move a regra de isolamento para dentro do banco. Em vez de confiar que todo desenvolvedor vai lembrar de filtrar por cliente, você declara uma política uma vez e o banco passa a recusar qualquer linha que não seja daquele cliente, mesmo que a query venha sem filtro. Plataformas como Supabase e Neon entregam Postgres com RLS pronto, o que tornou essa abordagem acessível até para times pequenos.
Como o Row Level Security funciona na prática
Você ativa o RLS na tabela e cria uma política que compara o cliente da linha com o cliente da sessão atual; no Supabase, normalmente via auth.uid() ou uma variável de sessão definida no login. A partir daí, um SELECT sem filtro devolve só o que é daquele cliente, e um UPDATE não alcança linha de outro. O isolamento deixa de ser uma promessa do código e passa a ser uma regra que o banco cumpre sozinho.
O detalhe que quebra RLS: pool de conexão
O erro mais comum aparece com pool de conexões. Se a variável que identifica o cliente fica presa na conexão e outra requisição reaproveita essa mesma conexão, um cliente pode herdar o contexto do anterior. A correção é definir o cliente por transação, não por conexão, e testar isso sob carga. É o tipo de armadilha que só aparece em produção e que uma boa arquitetura de desenvolvimento de sistemas prevê desde o começo.
Os erros que vazam dados entre clientes
- Confiar só no filtro da aplicação: basta uma query nova sem o WHERE de cliente para expor tudo. O RLS existe justamente para ser a última linha de defesa.
- Endpoint que recebe o id do cliente pelo front-end: se o cliente é informado pela requisição em vez de derivado do login, qualquer um troca o número e lê o dado do vizinho.
- Chave de serviço no lugar errado: credenciais que ignoram o RLS (service role) usadas no front ou em rota pública anulam todo o isolamento.
- Cache e relatório sem escopo: dado agregado que junta clientes num mesmo cache é um vazamento silencioso que nenhum teste de tela pega.
Como escolher o modelo certo para o seu SaaS
Para a maioria dos produtos que estão nascendo, tabela compartilhada com RLS entrega o melhor equilíbrio: escala bem, custa pouco e concentra a segurança num só lugar. Banco ou schema por cliente faz sentido quando há exigência regulatória de separação física, poucos clientes de altíssimo valor ou necessidade de restaurar o dado de um cliente sem tocar nos demais. O ponto de virada costuma ser o número de clientes e o custo de manter muitas cópias da estrutura em sincronia, algo que também pesa em qualquer integração via API que precise falar com esses dados.
Isolamento de dados não é uma funcionalidade que se adiciona depois; é uma decisão de arquitetura. Quando ele mora no banco, e não na disciplina de quem escreve query, o vazamento deixa de ser questão de esquecimento.
Perguntas frequentes
O que é uma arquitetura multi-tenant?+
É quando um único sistema atende vários clientes ao mesmo tempo, com cada um acessando apenas os próprios dados. É o modelo padrão de SaaS porque evita manter uma instalação separada por cliente e reduz muito o custo de operar e atualizar o produto.
RLS é suficiente para garantir o isolamento?+
RLS é a camada mais forte, porque o banco recusa dados de outro cliente mesmo sem filtro na query. Ainda assim, funciona melhor em conjunto com validação na aplicação e com o cuidado de nunca deixar o front-end definir qual cliente está sendo consultado.
Preciso de um banco de dados separado para cada cliente?+
Quase nunca. Banco por cliente só compensa com exigência de separação física, poucos clientes de altíssimo valor ou regras de compliance específicas. Para a maioria, tabela compartilhada com RLS isola tão bem quanto e escala muito melhor.
Multi-tenant deixa o sistema mais lento?+
Não, quando bem indexado. O identificador de cliente precisa entrar nos índices das tabelas grandes e as políticas de RLS devem ser simples. Bem feito, o overhead é desprezível diante do ganho de operar um só sistema para todos.
Dá para migrar um sistema single-tenant para multi-tenant depois?+
Dá, mas é mais caro do que já nascer multi-tenant. Envolve adicionar o identificador de cliente em todas as tabelas, reescrever consultas e cobrir tudo com RLS e testes. Por isso a decisão de arquitetura no início do projeto pesa tanto.
Se você está construindo um SaaS ou pensando em oferecer um sistema interno como produto para vários clientes, o desenho do isolamento de dados é a decisão que fica cara de corrigir depois. Um diagnóstico gratuito da VELTRIX avalia sua arquitetura e aponta o modelo multi-tenant certo para o seu estágio. Veja como estruturamos produtos SaaS de ponta a ponta e onde o isolamento entra nesse trabalho.
Quer aplicar isso no seu negócio?
Diagnóstico gratuito com nosso time. Sem compromisso.