Multi-tenant na prática: como isolar os dados de cada cliente num SaaS

Se você vai construir um SaaS, multi-tenant é uma das primeiras decisões de arquitetura, e uma das mais importantes. Ela define como o seu produto serve muitos clientes ao mesmo tempo sem que um veja o dado do outro. É barato decidir certo no começo, e caro corrigir depois. Veja o que isso significa na prática.

O que é multi-tenant, sem mística

Em vez de subir uma cópia do sistema para cada cliente, uma aplicação multi-tenant serve todos a partir da mesma base, separando os dados por cliente (tenant). É o padrão de quase todo SaaS porque reduz custo, facilita atualizações e escala melhor.

O alternativo é single-tenant: cada cliente com a sua própria instância. Funciona em casos específicos (cliente enterprise pagando muito caro, requisito regulatório forte), mas é insustentável quando o objetivo é crescer com centenas ou milhares de contas.

Shared database, separated schemas ou isolated

Três abordagens, em ordem de complexidade e isolamento:

• Shared database, shared schema. Todos os clientes na mesma tabela, separados por uma coluna corp_id (ou tenant_id). É o padrão moderno, e é o que usamos. Simples, barato, escala bem com segurança a nível de linha.
• Shared database, schema por tenant. Cada cliente em seu schema, mas no mesmo banco. Isolamento maior, complexidade de migração também.
• Database isolado por tenant. Cada cliente com seu próprio banco. Isolamento máximo, custo e operação também.

Para SaaS normal, shared schema com RLS é a escolha certa em 90% dos casos. As outras opções só fazem sentido em compliance pesado ou clientes enterprise específicos.

RLS na prática (Row Level Security)

RLS é o pilar que faz shared schema ser seguro de verdade. A regra de acesso vive no próprio banco: mesmo que uma consulta peça todos os registros, o banco devolve só o que o usuário daquele cliente tem direito.

Exemplo de uma política bem feita: "uma linha em deals só é visível se a coluna corp_id bater com o tenant do usuário autenticado". Pronto. Mesmo se o desenvolvedor esquecer de filtrar no código, o banco não devolve.

Sem RLS, isolamento depende inteiramente de o código nunca errar. Com RLS, errar fica caro. Para SaaS sério, RLS não é opcional, é a rede de segurança que torna o resto do produto sustentável.

Performance multi-tenant

O medo clássico: "todos os clientes na mesma tabela, isso não fica lento?". Resposta: não, se os índices forem certos. A coluna corp_id precisa estar em quase todo índice composto, e as queries precisam sempre passar por ela. Bem feito, escala para dezenas de milhões de linhas sem suar.

O problema clássico aparece quando um cliente é gigante (1000x maior que a média) e os outros sofrem com lock ou plano de consulta ruim. Aí entram técnicas como particionamento, ou, em casos extremos, mover o cliente grande para infra dedicada.

Custos cruzam de um jeito interessante

No começo, multi-tenant é dramaticamente mais barato: uma infra serve todos. Conforme o produto cresce, os custos diluem ainda mais por cliente. Mas tem um ponto interessante: clientes muito grandes podem subsidiar os pequenos, ou o oposto, dependendo do plano. Isso muda discussão de pricing.

Gotchas frequentes

• Esquecer corp_id num join. Acontece com gente sênior. RLS evita.
• Backup e restore por tenant. Backupar o banco todo é fácil. Restaurar só um cliente é trabalho que precisa estar planejado.
• Soft delete misturado entre tenants. Cuidado com queries que ignoram o filtro de deleted_at e somam todos os tenants.
• Limites por plano dentro do tenant. Cobrar por usuário, por uso, por feature. Onde vivem esses limites? Em código? Em config? Em tabela?

Decida cedo

Transformar um sistema single-tenant em multi-tenant depois é caro e arriscado: precisa adicionar corp_id em todo lugar, refatorar permissões, repensar autenticação. Quando a arquitetura nasce multi-tenant, o custo é baixo e o isolamento é sólido desde o primeiro cliente.

É o tipo de decisão que separa um produto que escala de um que trava no décimo cliente. Quer entender os termos? Veja a definição no glossário, ou conte o seu projeto.