SaaS multi-tenant: isolando os dados de cada cliente

Num SaaS, vários clientes (tenants) usam o mesmo sistema. A regra mais importante é absoluta: os dados de uma empresa nunca podem aparecer para outra. Parece óbvio — e é uma das falhas mais graves e mais comuns em produtos SaaS.

Três modelos de isolamento

1. 1.Banco compartilhado, coluna de tenant: todas as tabelas têm empresa_id. Mais simples e barato; exige disciplina absoluta nos filtros.
2. 2.Esquema por tenant: cada cliente com suas tabelas no mesmo banco. Isolamento maior, migrações mais complexas.
3. 3.Banco por tenant: isolamento máximo, custo e operação maiores. Para clientes com exigências regulatórias fortes.

A maioria dos SaaS começa no modelo 1 (Criar um SaaS do zero: as decisões que pesam no primeiro ano).

Como não errar no modelo compartilhado

• O tenant vem da sessão autenticada, nunca de um parâmetro que o usuário pode alterar.
• Filtro aplicado automaticamente numa camada central, não em cada consulta manualmente.
• Políticas no banco (Row Level Security) como segunda barreira (Supabase: quando acelera o projeto e quando começa a limitar).
• Testes automatizados que tentam acessar dados de outro tenant (Testes automatizados de API: o mínimo que evita desastres).
• Índices começando pela coluna de tenant (Índices no banco de dados: a otimização mais barata que você ainda não fez).

Além dos dados

Arquivos, cache, filas e logs também precisam respeitar o tenant (Upload de arquivos no backend: tamanho, tipo e armazenamento, Cache com Redis: respostas rápidas sem servir dados velhos).

Permissões dentro do tenant

Usuários de uma mesma empresa com papéis diferentes (Permissões por papel (RBAC): quem pode ver e fazer o quê).

A We Codex constrói plataformas SaaS seguras. Veja sistemas web ou fale com a gente.