A arquitetura multi-tenant é a decisão que mais pesa no custo e na operação de um SaaS ao longo dos anos. Escolher mal no início significa migrações dolorosas quando o primeiro cliente enterprise exigir isolamento, ou uma conta de infraestrutura que cresce mais rápido que a receita.
Neste comparativo, analiso os três modelos de isolamento de dados mais usados, com prós, contras e critérios de escolha. Não existe resposta universal: uma boa arquitetura multi-tenant é a que combina com o seu perfil de cliente, seu time e seu modelo de preço.
O que uma arquitetura multi-tenant precisa resolver
Em uma arquitetura multi-tenant, várias organizações clientes (os tenants) compartilham a mesma aplicação e parte da infraestrutura. O desafio é manter a economia de escala sem abrir mão de segurança e previsibilidade. Na prática, o desenho precisa responder a quatro perguntas:
- Isolamento de dados: como evitar que um tenant leia ou altere dados de outro, inclusive por bug?
- Isolamento de desempenho: como impedir que um cliente pesado degrade os demais (o clássico noisy neighbor)?
- Operação: quanto custa aplicar migrations, fazer backup, restaurar e monitorar por tenant?
- Conformidade: há exigências contratuais ou da LGPD sobre segregação, residência de dados e exclusão?
Os três modelos de isolamento
1. Schema compartilhado com coluna tenant_id
Todos os tenants vivem nas mesmas tabelas, e cada linha carrega um tenant_id. É o modelo mais barato e simples de operar: uma migration roda uma vez, o pool de conexões é único e o onboarding de um novo cliente é apenas um INSERT.
O risco está na camada de aplicação. Uma query sem o filtro correto vaza dados entre clientes. Para reduzir esse risco, bancos como o PostgreSQL oferecem Row-Level Security (RLS), que move a regra de isolamento para o banco:
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON invoices
USING (tenant_id = current_setting('app.tenant_id')::uuid);
-- na conexão, antes das queries:
SET app.tenant_id = '8b1f0c52-0000-0000-0000-000000000000';Os contras são reais: índices compostos precisam começar por tenant_id, tabelas grandes tendem a ficar dominadas por poucos clientes, e restaurar os dados de um único tenant exige trabalho extra de extração. Nesse formato de arquitetura multi-tenant, o noisy neighbor só se resolve com rate limiting, filas e limites por tenant na aplicação.
2. Schema por tenant
Aqui há um único banco, mas cada cliente tem seu próprio schema (no PostgreSQL) com o mesmo conjunto de tabelas. O isolamento lógico é mais forte, o search_path define o contexto, e exportar ou apagar um tenant fica bem mais simples.
O preço aparece na escala. Milhares de schemas inflam o catálogo do banco, tornam migrations lentas (é preciso iterar por todos os schemas) e complicam ferramentas de monitoramento e de pooling. Em geral, funciona bem para dezenas ou poucas centenas de tenants, mas exige automação madura de migrations e controle de versão de schema por cliente.
3. Banco (ou instância) por tenant
É o isolamento mais forte: cada cliente tem seu próprio banco, às vezes sua própria instância ou até sua própria conta de cloud. Backup, restore, criptografia com chave própria, residência de dados e ajuste de recursos ficam independentes por cliente, o que agrada em contratos enterprise e setores regulados.
Em contrapartida, o custo fixo por tenant sobe, o número de conexões e de recursos ociosos cresce, e a orquestração de deploys e migrations vira um problema de plataforma. Sem automação (por exemplo, infraestrutura como código e pipelines que provisionam o tenant), esse modelo não se sustenta.
Trade-offs: como decidir
Em vez de escolher por preferência, compare os modelos por critério:
- Custo por tenant: menor no schema compartilhado, intermediário no schema por tenant, maior no banco por tenant.
- Isolamento e conformidade: o inverso: o banco por tenant é o mais forte, o schema compartilhado depende de disciplina e de RLS.
- Migrations: uma única execução no modelo compartilhado versus N execuções nos outros dois, com risco de divergência de versões.
- Restore pontual: trivial com banco por tenant, trabalhoso com schema compartilhado.
- Noisy neighbor: só o banco por tenant dá isolamento real de recursos; nos demais, é preciso controle na aplicação e no banco.
Uma regra prática: se o seu produto atende muitos clientes pequenos com ticket baixo, a arquitetura multi-tenant de schema compartilhado costuma ser a única que fecha a conta. Se vende para poucos clientes grandes, com exigências contratuais, o isolamento por banco compensa o custo extra. A escolha do SGBD também influencia, pois recursos como RLS, schemas e extensões variam; vale revisar o comparativo entre PostgreSQL e MySQL para o banco do seu SaaS antes de fechar o desenho.
O modelo híbrido na prática
Muitos SaaS B2B maduros acabam em uma arquitetura multi-tenant híbrida: o plano padrão roda no schema compartilhado, e clientes enterprise são promovidos para um banco dedicado. Para isso funcionar, a aplicação precisa de uma camada de roteamento que resolva, a partir do tenant, qual conexão usar, e de um catálogo central com o mapa tenant, shard e versão de schema.
Três cuidados evitam dor futura:
- Projete o tenant_id desde o dia um, mesmo que hoje todo mundo esteja no mesmo banco. Isso torna a migração para outro modelo uma operação de dados, não uma reescrita.
- Automatize o provisionamento e as migrations, com pipeline que registre o estado por tenant.
- Observe por tenant: métricas, logs e custo atribuídos a cada cliente mostram quem consome mais e embasam a decisão de promover alguém para isolamento dedicado.
Esse último ponto conecta com a conta de infraestrutura. Quanto mais isolamento, mais atenção ao desperdício, e vale combinar o desenho com as práticas de redução de custo de cloud sem perder performance, como dimensionamento correto e uso de recursos sob demanda.
Conclusão
Não há modelo certo em abstrato. Schema compartilhado maximiza eficiência, banco por tenant maximiza isolamento, e o schema por tenant ocupa um meio-termo com limites de escala. Defina sua arquitetura multi-tenant a partir do perfil de cliente, das exigências de conformidade e da maturidade de automação do time, e deixe a porta aberta para evoluir para um modelo híbrido. Decidir isso cedo, com critérios claros, é uma das formas mais baratas de proteger a margem do seu SaaS.
