Arquitetura multi-tenant para SaaS no Brasil: padrões, trade-offs e LGPD

A decisão que define o custo de operação do seu SaaS

Quando você começa a construir um SaaS B2B, a primeira decisão de arquitetura que vai perseguir o projeto por anos é o modelo de multi-tenancy. Acertar aqui economiza dinheiro e dor de cabeça. Errar significa reescrever o data layer inteiro quando tiver 50 clientes.

Existem três padrões principais. Cada um tem custos, riscos e benefícios concretos. Não existe "melhor". Existe o mais adequado para o seu cenário.

Padrão 1: database-per-tenant

Cada cliente tem seu próprio banco de dados. Isolamento total a nível de dados.

Como funciona

O application layer recebe a requisição, identifica o tenant (pelo subdomínio, header, ou token JWT), e roteia para o banco correto. A connection string é resolvida em runtime. Tipicamente, um serviço de "tenant registry" mantém o mapeamento tenant_id para connection_string.

Quando faz sentido

Quando seus clientes são grandes (enterprise) e exigem isolamento contratual de dados. Bancos, hospitais, governo. Quando a LGPD impõe que dados de um cliente não podem, sob nenhuma hipótese, ser acessados por outro. Quando cada cliente precisa de backup e restore independente.

Custos reais

Cada banco PostgreSQL em uma instância RDS da AWS custa, no mínimo, US$ 15/mês (db.t4g.micro). Com 200 clientes, são US$ 3.000/mês só em banco de dados, sem contar CPU e storage. Migrations precisam rodar em todos os bancos, um a um. Se uma migration falha no banco do cliente 47, você tem 46 bancos na versão nova e 154 na versão antiga. O rollback é manual.

Operacionalmente, monitorar 200 bancos é diferente de monitorar 1. Alertas de disk space, connection pool, slow queries: tudo multiplicado por N.

Na prática

Já implementamos database-per-tenant para um SaaS de saúde com 35 hospitais como clientes. Funcionou bem porque: cada hospital tem volume alto (milhões de registros), a regulação exige isolamento, e o ticket médio justifica o custo operacional (R$ 15 mil/mês por hospital). Para um SaaS com ticket de R$ 99/mês e meta de 5.000 clientes, seria inviável.

Padrão 2: shared schema com tenant_id

Todos os clientes compartilham o mesmo banco e as mesmas tabelas. Cada tabela tem uma coluna tenant_id. Toda query inclui WHERE tenant_id = ?.

Como funciona

Uma única instância de banco, um único schema. A aplicação injeta o tenant_id em toda operação de leitura e escrita. Frameworks como Django (django-tenants), Laravel, e Prisma oferecem middleware que faz isso automaticamente.

Quando faz sentido

Quando você tem muitos clientes com volume individual baixo a médio. SaaS SMB com ticket de R$ 49 a R$ 499/mês. Quando custo de infra precisa escalar de forma linear (ou sub-linear) com o número de clientes. Quando velocidade de desenvolvimento importa mais que isolamento absoluto.

Riscos reais

Data leak entre tenants: um desenvolvedor esquece o filtro tenant_id e o cliente A vê dados do cliente B. Noisy neighbor: uma query pesada do tenant 42 trava o banco para os outros 4.999. Compliance: sob a LGPD, exclusão completa de dados de um tenant (Art. 18, VI) significa DELETE em dezenas de tabelas com FK cascading.

Mitigações obrigatórias

Para data leak: use middleware no ORM que injeta tenant_id automaticamente. No PostgreSQL, RLS é a camada extra (veja Padrão 3). Para noisy neighbor: rate limiting por tenant e connection pooling (PgBouncer) com limites. Para compliance: construa um serviço de "tenant data purge" com delete em cascata e log auditável.

Padrão 3: Row Level Security (RLS) no PostgreSQL

Este é uma evolução do Padrão 2. O banco de dados impõe o isolamento, não a aplicação.

Como funciona

Você cria policies RLS no PostgreSQL que filtram automaticamente por tenant_id. Exemplo concreto:

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON orders
  USING (tenant_id = current_setting('app.current_tenant')::uuid);

No início de cada request, a aplicação executa SET app.current_tenant = 'uuid-do-tenant'. A partir daí, toda query naquela session só vê e modifica dados do tenant correto. Mesmo que o desenvolvedor escreva SELECT * FROM orders sem WHERE, o PostgreSQL aplica o filtro automaticamente.

Por que isso importa

RLS é a diferença entre "esperamos que o código esteja certo" e "o banco garante que está certo". É defesa em profundidade. Se o middleware da aplicação falha, se alguém roda uma query direta no banco, o RLS ainda protege.

Limitações

RLS adiciona overhead de 3 a 7% em queries simples e até 12% em JOINs complexos (benchmarks com PostgreSQL 16). Para queries analíticas pesadas, separe o banco OLTP (com RLS) do analítico (sem RLS, dados anonimizados). RLS também não funciona com superuser.

Billing multi-tenant no Brasil

Billing em SaaS brasileiro tem particularidades que não existem nos EUA.

Nota fiscal: todo pagamento recorrente precisa de NFS-e. Se você tem 2.000 clientes pagando R$ 199/mês, são 2.000 notas fiscais por mês. A emissão precisa ser automatizada via integração com prefeitura (ou via intermediários como Enotas, NFe.io, Focusnfe).

Boleto e Pix: cartão de crédito é minoria no B2B brasileiro. A maioria paga via boleto ou Pix. A taxa de inadimplência em boleto B2B é de 8 a 12% (dados Asaas 2025). Você precisa de régua de cobrança automatizada: lembrete 3 dias antes do vencimento, cobrança no dia, lembrete 3 dias depois, segunda via, suspensão do acesso após X dias.

Billing por usage: se o seu SaaS cobra por volume (APIs calls, storage, usuários ativos), o sistema de billing precisa agregar métricas por tenant em tempo real. A arquitetura típica: eventos de uso vão para uma fila (SQS, RabbitMQ), um worker agrega por tenant e período, e o resultado alimenta o sistema de billing. Cuidado com a precisão: diferenças de centavos por transação viram milhares de reais com escala.

Gateway de pagamento: para SaaS B2B no Brasil, os principais são Stripe (entrou no Brasil em 2023 com suporte a BRL), Pagarme (forte em boleto), e Asaas (billing recorrente nativo com boleto, Pix e cartão).

LGPD em multi-tenant: o que muda na prática

A LGPD trata dados pessoais, independente de estarem em banco shared ou isolado. Mas a implementação prática muda.

Em multi-tenant, o controlador é o seu cliente (o tenant), não você. Você é operador. O tenant coleta consentimento. Você processa conforme instruções do tenant.

Para portabilidade (Art. 18, V), tenha um endpoint de data export por titular e por tenant. Para RIPD, demonstre que o isolamento entre tenants é efetivo (RLS facilita). Para incidentes de segurança, tenha logging de acesso por tenant para determinar o escopo do vazamento.

Qual padrão escolher

Para SaaS SMB (ticket abaixo de R$ 500/mês, meta de centenas a milhares de clientes): shared schema com RLS. Custo baixo, desenvolvimento rápido, isolamento adequado.

Para SaaS mid-market (ticket de R$ 1.000 a R$ 10.000/mês, dezenas a centenas de clientes): schema-per-tenant (schemas separados no mesmo banco PostgreSQL). Bom equilíbrio entre isolamento e custo.

Para SaaS enterprise (ticket acima de R$ 10.000/mês, poucos clientes, regulação pesada): database-per-tenant. Custo alto, mas justificado pelo ticket e pelos requisitos de compliance.

Para a maioria dos SaaS B2B brasileiros que estão começando: comece com shared schema + RLS. Migre quando a receita justificar. Se cada query depende de um tenant_id injetado por middleware, trocar o backend de resolução é refatoração, não reescrita.

---

Precisa de ajuda com arquitetura multi-tenant? Fale com a Bradata.