SaaS multi-tenant: como isolar os dados de cada cliente

Todo SaaS atende vários clientes com o mesmo software. A pergunta é quanto eles compartilham: o mesmo servidor, o mesmo banco, as mesmas tabelas? Cada resposta tem um custo diferente em segurança, operação e evolução, e mudar de ideia depois é uma das migrações mais trabalhosas que existem.

O pior incidente possível num SaaS é um cliente ver os dados de outro. Ele destrói a confiança, gera obrigação de comunicação sob a LGPD e, dependendo do mercado, encerra contratos. Este texto compara os modelos de isolamento, mostra como garantir no código e no banco que isso não aconteça, e trata dos problemas que só aparecem com dezenas ou centenas de clientes.

Multi-tenant é decisão de negócio antes de ser de banco

"Tenant" é o inquilino: cada cliente do SaaS, normalmente uma empresa, com seus usuários e seus dados. A arquitetura de isolamento deveria seguir de algumas perguntas de negócio:

• Quantos clientes você espera, e de que tamanho? Milhares de pequenas empresas pedem um modelo diferente de algumas dezenas de grandes contas.
• O que os contratos vão exigir? Clientes grandes, regulados ou do setor público podem exigir dados em banco separado, localização específica ou chave de criptografia própria.
• Quanto cada cliente pode ser personalizado? Configuração é saudável; código diferente por cliente é outra coisa.
• Como é o onboarding? Autoatendimento, com o cliente criando a conta sozinho, exige que um novo tenant nasça em segundos, sem ninguém da operação.
• Qual o perfil de uso? Clientes com volumes muito diferentes compartilhando recursos criam o problema do vizinho barulhento.

As respostas raramente apontam para um modelo único. É comum um SaaS com a maioria dos clientes compartilhados e alguns clientes grandes isolados, e a arquitetura deve permitir isso desde o início.

Banco compartilhado, esquema por cliente ou banco dedicado

Os três modelos clássicos, do mais compartilhado ao mais isolado:

Banco compartilhado com uma coluna identificando o tenant em cada tabela é o modelo mais comum para SaaS com muitos clientes. É o mais eficiente, e também o que mais depende de disciplina, porque uma consulta sem filtro expõe tudo.

Esquema por cliente separa as tabelas de cada cliente dentro do mesmo banco. Isola melhor, mas com muitos clientes as migrações e o número de objetos no banco viram problema operacional.

Banco dedicado isola por completo e facilita atender exigências contratuais, restaurar um cliente específico ou movê-lo de região. Custa mais e exige automação forte de provisionamento e migração.

O modelo híbrido é frequente: tenants compartilhados por padrão e dedicados para quem precisa, com o código preparado para descobrir, a cada requisição, onde estão os dados daquele cliente.

Garantindo o isolamento no código e no banco

No modelo compartilhado, confiar que todo desenvolvedor vai lembrar de filtrar pelo tenant em toda consulta é garantir que, um dia, alguém vai esquecer. O isolamento precisa de camadas independentes.

1. O tenant vem da autenticação, nunca da requisição. O identificador do cliente é extraído do token do usuário autenticado. Um parâmetro na URL ou no corpo da requisição dizendo de qual cliente é o dado é exatamente o tipo de falha que permite acessar dados alheios trocando um número. Esse e outros erros clássicos estão em segurança de APIs: erros comuns.

2. Filtro automático na camada de acesso a dados. O código de acesso ao banco aplica o filtro de tenant em toda consulta, sem que o desenvolvedor precise escrever. Consultas que precisam atravessar tenants (relatórios internos, rotinas administrativas) usam um caminho explícito, separado e auditado.

3. Proteção no próprio banco. Bancos como o PostgreSQL oferecem segurança em nível de linha (row-level security): políticas que fazem o banco devolver apenas as linhas do tenant definido na sessão, mesmo que a consulta não tenha filtro. É a rede de proteção para o dia em que a camada de aplicação falhar. Alguns cuidados para ela funcionar de verdade:

• a aplicação conecta com um usuário que não é dono das tabelas nem administrador, porque esses podem ignorar as políticas;
• o tenant é definido por transação, e não por conexão, para que o pool de conexões não reaproveite uma sessão com o tenant de outro cliente;
• as políticas são testadas automaticamente, com testes que tentam ler dados de outro tenant e precisam falhar.

4. Isolamento além do banco. Arquivos em armazenamento de objetos, índices de busca, cache, filas e logs também carregam dados de clientes. Cada um precisa de uma estratégia: prefixos por tenant, chaves de cache que incluem o tenant, mensagens de fila que carregam o tenant e são validadas no consumo.

5. Trilha de auditoria de acessos e alterações, com o tenant em cada registro, como descrevemos em controle de acesso e trilha de auditoria.

Configuração e personalização sem fork por cliente

O primeiro cliente grande pede uma regra diferente. A tentação é criar uma cópia do código para ele. No quinto cliente, você tem cinco produtos para manter, e cada correção precisa ser aplicada cinco vezes.

A alternativa é personalização por configuração, em camadas:

• Parâmetros: limites, prazos, textos, campos obrigatórios, fluxos ativos.
• Funcionalidades por plano ou cliente, ligadas por chaves de configuração.
• Campos personalizados: o cliente adiciona campos próprios a entidades como cliente, pedido ou ativo.
• Fluxos configuráveis: etapas de aprovação, regras de notificação.
• Pontos de extensão: webhooks e APIs para que o cliente integre suas próprias regras fora do seu código.
• Identidade visual: logo, cores e domínio próprio.

A regra de decisão: se a personalização pedida faz sentido para outros clientes, ela vira configuração do produto; se só faz sentido para um, ela vira integração ou fica de fora. Código específico de cliente dentro do produto é a exceção documentada, não o padrão.

Migrações de esquema com muitos clientes

Alterar a estrutura do banco com um cliente é simples. Com centenas, cada migração é uma operação:

• Migrações compatíveis com a versão anterior: adicionar antes de remover, com o código novo convivendo com o esquema antigo durante a transição. Isso permite atualizar sem parar o sistema.
• Migrações de dados grandes em lotes, em segundo plano, sem travar tabelas.
• Nos modelos por esquema ou banco dedicado, uma orquestração que aplica a migração a cada tenant, registra o resultado e permite retomar os que falharam.
• Ondas de liberação: aplicar primeiro a um grupo de clientes internos ou piloto, depois ao restante.

Vizinho barulhento: limites e filas por cliente

Num ambiente compartilhado, um cliente que importa um arquivo gigante ou dispara milhares de requisições pode deixar o sistema lento para todos.

• Limites de requisição por tenant na API.
• Filas de processamento com justiça entre clientes: o trabalho pesado de um cliente não bloqueia o dos outros.
• Cotas de armazenamento, usuários ou volume, ligadas ao plano contratado.
• Métricas por tenant: uso de CPU, consultas lentas, volume de dados. Sem isso, você não sabe quem está causando o problema.
• Caminho para isolar: quando um cliente cresce muito, movê-lo para recursos dedicados sem mudar o código.

Nada disso exige microsserviços. Um monolito modular bem estruturado atende muito bem a um SaaS em crescimento, como argumentamos em monolito ou microsserviços.

Planos, cobrança e onboarding automatizado

O SaaS só escala se o ciclo comercial for automatizado:

• Onboarding self-service: cadastro, criação do tenant, configuração inicial e primeiro usuário sem intervenção humana.
• Planos e limites aplicados pelo sistema, com upgrade e downgrade.
• Cobrança recorrente integrada, com régua de inadimplência e suspensão gradual. Os meios e fluxos estão em cobrança recorrente com Pix Automático.
• Cancelamento e exportação de dados: o cliente que sai recebe seus dados, e os dados são excluídos conforme contrato e LGPD.

Erros comuns

• Tenant vindo de parâmetro da requisição.
• Isolamento só na aplicação, sem proteção no banco.
• Esquecer arquivos, cache, filas e logs.
• Fork de código por cliente.
• Migrações que exigem parar o sistema.
• Nenhuma métrica por tenant.

Checklist de arquitetura

• Modelo de isolamento escolhido com base nos contratos e no perfil de clientes.
• Tenant derivado da autenticação.
• Filtro automático e segurança em nível de linha, com testes de isolamento.
• Estratégia de isolamento para arquivos, cache, filas e busca.
• Personalização por configuração, com regra clara para exceções.
• Migrações compatíveis e orquestradas.
• Limites, filas e métricas por tenant.
• Onboarding, cobrança e saída automatizados.

Isolamento pensado desde a primeira linha

A Pervian Tech projeta e constrói plataformas SaaS sob medida no nosso trabalho de arquitetura de software: modelo de isolamento, proteção no banco, personalização por configuração, migrações seguras e automação do ciclo comercial.

Começamos por um diagnóstico inicial gratuito do seu modelo de negócio, dos clientes que você quer atender e, se já existe um produto, da arquitetura atual. Dali saem as decisões de arquitetura, as fases e o investimento, que é sob consulta. Se você está criando ou reestruturando um SaaS, conte sobre o produto.