Multi-tenant (em SaaS)
Multi-tenant é a arquitetura onde vários clientes dividem a mesma infraestrutura, com dados separados só por regra lógica — não por servidor próprio.
Multi-tenant é o modelo de arquitetura onde uma única instância de aplicação e banco de dados atende vários clientes ao mesmo tempo, separando os dados de cada um por regra de software — não por servidor dedicado.
Pro dono de escritório contábil ou clínica que assina um SaaS qualquer, é o motivo pelo qual o dado da sua empresa mora na mesma tabela do concorrente do lado — e a única coisa entre os dois é uma linha de código que, se falhar, ninguém do lado de fora percebe.
Como funciona por baixo
Existem três formas de isolar tenant: banco separado por cliente (mais caro), schema separado (meio-termo), ou tabela única com coluna cliente_id filtrando cada linha (mais barato, mais frágil). A maioria dos SaaS “enterprise-ready” usa a terceira, porque escala com menos servidor.
O ponto crítico é onde a regra de isolamento vive. No código da aplicação — um WHERE cliente_id = X que um dev pode esquecer numa query nova — o isolamento depende de ninguém errar. No banco, como faz o RLS (Row Level Security), o próprio Postgres barra a query errada antes dela rodar.
Por que importa pro escritório contábil ou clínica
Software vendido como “multi-tenant” soa técnico e neutro — mas na prática é decisão de custo do fornecedor, não garantia de segurança pra você. Multi-tenant barato significa economizar servidor te colocando na mesma base que centenas de clientes, às vezes teu concorrente direto.
Número antes de promessa: antes de assinar SaaS que guarda dado fiscal, de paciente ou de lead, pergunte direto — “isolamento é só no código ou tem RLS ativo no banco?” Fornecedor que não sabe responder não testou isolamento, só confiou que o código nunca vai ter bug.
Erro comum: confundir “multi-tenant” com “seguro”
O erro comum é ler “arquitetura multi-tenant” no site do fornecedor e assumir isolamento robusto. Multi-tenant só descreve como os clientes dividem a infra — não diz COMO o isolamento é garantido. Pode ser multi-tenant com isolamento fraco (só no código) ou forte (RLS, auditoria de acesso). O nome não entrega a resposta; a arquitetura por trás, sim.
Como aplicar hoje
Pra quem monta sistema pra atender vários clientes na mesma base — CRM próprio, produto que vende pra outras empresas:
- Decida isolamento por linha (RLS) desde o design, não como reforma depois do susto.
- Teste: usuário do cliente A tentando ver dado do cliente B tem que falhar, sempre.
- Dado sensível em volume alto (fiscal, saúde, jurídico) pede schema ou banco separado — mais caro, mais fácil de auditar.
A iAvancada monta essa arquitetura com isolamento real testado, não coluna esquecida. O Runner da iAgentes já roda cada cliente em schema isolado por padrão.
Termos relacionados
- RLS (Row Level Security) — o mecanismo que garante isolamento real dentro do banco
- DPA (Data Processing Agreement) — o contrato que deveria descrever como o fornecedor isola seu dado
- Infra AI-ready — arquitetura pronta pra IA que já nasce com isolamento desenhado