Multi-Tenant vs Single-Tenant | Escolher a Arquitetura SaaS Certa

Cada produto SaaS precisa de responder a uma pergunta fundamental: como servir multiplos clientes a partir do mesmo software? A resposta e o seu modelo de tenancy. Afeta o custo, a seguranca, a performance e a rapidez com que pode entregar. Acertar cedo poupa-o de migracoes dolorosas mais tarde.

Definicoes

Multi-tenant

Uma instancia da aplicacao serve todos os clientes. Toda a gente partilha os mesmos servidores, a mesma base de codigo e frequentemente a mesma base de dados. Os dados de cada cliente sao logicamente isolados, mas a infraestrutura e partilhada.

Pense nisto como um predio de apartamentos. Cada inquilino vive no mesmo predio, partilha o elevador e os corredores, mas tem a sua propria unidade trancada com a sua propria mobilia.

Single-tenant

Cada cliente obtem a sua propria instancia dedicada da aplicacao. Servidores separados, bases de dados separadas, por vezes bases de codigo separadas. Nada e partilhado entre clientes.

Pense nisto como moradias individuais. Cada inquilino tem o seu proprio edificio, a sua propria canalizacao, o seu proprio quintal. Isolamento completo, mas mais caro de manter.

Como Funciona o Multi-Tenancy

Ha tres abordagens comuns para arquitetura multi-tenant, cada uma com compromissos diferentes.

Modelo 1: Aplicacao partilhada, base de dados partilhada

Todos os tenants partilham uma unica instancia da aplicacao e uma unica base de dados. Os dados do tenant sao separados usando um identificador de tenant (geralmente uma coluna tenant_id) em cada tabela.

Arquitetura:

• Um servidor de aplicacao (ou cluster) trata todos os pedidos.
• Uma base de dados armazena todos os dados dos tenants.
• Cada query inclui uma clausula WHERE tenant_id = ? para restringir os dados ao tenant correto.

Vantagens:

• Menor custo de infraestrutura. Uma base de dados, uma implementacao de aplicacao.
• Mais simples de implementar e atualizar. Faca push uma vez, toda a gente recebe a alteracao.
• Facil de agregar dados entre tenants para analitica e relatorios.

Desvantagens:

• Maior risco de fuga de dados se uma query esquece o filtro de tenant.
• Um tenant ruidoso pode degradar a performance para todos.
• Migracoes de base de dados afetam todos os tenants simultaneamente.
• Mais dificil de cumprir regulamentacoes de residencia de dados.

Esta e a abordagem mais comum para produtos SaaS B2B com um grande numero de clientes pequenos a medios.

Modelo 2: Aplicacao partilhada, bases de dados separadas

Todos os tenants partilham a mesma instancia da aplicacao, mas cada tenant obtem a sua propria base de dados. A aplicacao encaminha queries para a base de dados correta com base no tenant autenticado.

Arquitetura:

• Um servidor de aplicacao (ou cluster) trata todos os pedidos.
• Uma base de dados separada para cada tenant.
• Uma camada de routing mapeia a identidade do tenant para a ligacao de base de dados correta.

Vantagens:

• Isolamento de dados mais forte. Sem risco de queries entre tenants.
• Mais facil de cumprir requisitos de residencia de dados. Pode colocar cada base de dados na regiao requerida pelo tenant.
• Backup e restauro por tenant e simples.
• A utilizacao pesada de um tenant nao bloqueia tabelas para outros tenants.

Desvantagens:

• Mais infraestrutura para gerir. Centenas de tenants significa centenas de bases de dados.
• Migracoes de esquema devem ser aplicadas a cada base de dados individualmente.
• Relatorios entre tenants requerem consultar multiplas bases de dados.
• Custo mais alto que um modelo totalmente partilhado.

Este e um forte meio-termo para produtos que precisam de melhor isolamento sem o custo de single-tenancy completo.

Modelo 3: Aplicacao separada, base de dados separada

Cada tenant obtem a sua propria instancia da aplicacao e a sua propria base de dados. Totalmente isolado. Isto e essencialmente single-tenancy, mas gerido pelo fornecedor de SaaS em vez do cliente.

Arquitetura:

• Uma implementacao de aplicacao dedicada por tenant.
• Uma base de dados dedicada por tenant.
• Uma camada de routing (frequentemente um load balancer ou API gateway) direciona o trafego para a instancia correta.

Vantagens:

• Isolamento completo. Sem recursos partilhados entre tenants.
• Maxima flexibilidade para personalizacao por tenant.
• A performance de um tenant nunca afeta outro.
• Historia de conformidade mais simples.

Desvantagens:

• Custo de infraestrutura mais alto de longe.
• A complexidade de implementacao cresce linearmente com a contagem de tenants.
• As atualizacoes devem ser distribuidas a cada instancia individualmente (ou automatizadas com muito cuidado).
• Nao escala economicamente para grandes numeros de tenants pequenos.

Este modelo faz sentido para SaaS empresarial onde os clientes exigem infraestrutura dedicada e estao dispostos a pagar um premium por isso.

Vantagens e Desvantagens de Relance

Fator	Multi-Tenant (BD Partilhada)	Multi-Tenant (BD Separada)	Single-Tenant
Custo de infraestrutura	Mais baixo	Medio	Mais alto
Isolamento de dados	Logico (nivel de linha)	Fisico (nivel de base de dados)	Completo
Complexidade de implementacao	Baixa	Media	Alta
Velocidade de atualizacao	Instantanea para todos	App instantanea, migracoes por BD	Rollout por instancia
Personalizacao	Limitada	Limitada	Total
Conformidade	Mais dificil	Moderada	Mais facil
Escalabilidade (contagem de tenants)	Excelente	Boa	Fraca
Risco de vizinho ruidoso	Alto	Medio	Nenhum

Isolamento e Seguranca de Dados

O isolamento de dados e a consideracao mais importante em qualquer modelo de tenancy. Uma violacao de seguranca onde um tenant consegue aceder aos dados de outro tenant e catastrofica para um negocio SaaS. Pode destruir a confianca, violar regulamentacoes e acabar com a empresa.

Row-level security

Num modelo de base de dados partilhada, o Row-Level Security (RLS) do PostgreSQL e uma das defesas mais fortes contra fugas de dados. O RLS impoe o isolamento de tenants ao nivel da base de dados, nao ao nivel da aplicacao. Mesmo que o codigo da sua aplicacao tenha um bug que esquece de filtrar por tenant, a base de dados em si previne o acesso entre tenants.

Eis como configura-lo:

-- Enable RLS on a table
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

-- Create a policy that restricts access to the current tenant
CREATE POLICY tenant_isolation ON projects
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

-- Force RLS even for table owners
ALTER TABLE projects FORCE ROW LEVEL SECURITY;

Antes de executar qualquer query, defina o contexto do tenant:

-- Set at the beginning of each request/transaction
SET LOCAL app.current_tenant_id = 'a1b2c3d4-e5f6-7890-abcd-ef1234567890';

-- Now this query automatically returns only the current tenant's data
SELECT * FROM projects;
-- No WHERE clause needed. RLS handles it.

Isolamento ao nivel da aplicacao

Alem da seguranca ao nivel da base de dados, a sua aplicacao deve impor fronteiras de tenant:

// Middleware that sets tenant context on every request
async function tenantMiddleware(req: Request, res: Response, next: NextFunction) {
  const tenantId = extractTenantId(req); // From JWT, subdomain, or header

  if (!tenantId) {
    return res.status(401).json({ error: "Tenant not identified" });
  }

  // Set tenant context for the database connection
  await db.raw(`SET LOCAL app.current_tenant_id = '${tenantId}'`);

  req.tenantId = tenantId;
  next();
}

A defesa em profundidade e o principio aqui. Nunca confie numa unica camada de isolamento. Combine filtragem ao nivel da aplicacao, seguranca ao nivel da base de dados e auditorias de seguranca regulares.

Consideracoes de Performance

Desafios da base de dados partilhada

Numa base de dados partilhada, todos os tenants competem pelos mesmos recursos. Um tenant a executar um relatorio pesado pode abrandar queries para todos os outros. Mitigacoes incluem:

• Connection pooling. Use PgBouncer ou ferramenta semelhante para evitar que um tenant esgote as ligacoes de base de dados.
• Timeouts de queries. Defina tempos maximos de execucao para que uma query descontrolada nao bloqueie recursos indefinidamente.
• Limitacao de taxa. Imponha limites por tenant em pedidos de API e operacoes de base de dados.
• Read replicas. Encaminhe operacoes de leitura pesada (relatorios, exportacoes) para uma replica para que nao afetem a base de dados principal.

Vantagens de bases de dados separadas

Com bases de dados por tenant, o isolamento de performance e integrado. A carga de trabalho pesada de um tenant afeta apenas a sua propria base de dados. Pode tambem provisionar bases de dados maiores ou menores com base no plano e utilizacao de cada tenant.

O compromisso e a sobrecarga de gestao. Monitorizar 500 bases de dados e mais dificil que monitorizar uma. Ferramentas automatizadas tornam-se essenciais.

Implicacoes de Custo em Escala

Vejamos alguns numeros aproximados. Assuma que tem 100 tenants.

Base de dados partilhada (multi-tenant):

• 1 cluster de aplicacao: ~200 EUR/mes
• 1 instancia gerida de PostgreSQL: ~100 EUR/mes
• Total: ~300 EUR/mes (3 EUR por tenant)

Bases de dados separadas (multi-tenant):

• 1 cluster de aplicacao: ~200 EUR/mes
• 100 instancias de base de dados pequenas: ~2.000 EUR/mes
• Total: ~2.200 EUR/mes (22 EUR por tenant)

Single-tenant:

• 100 instancias de aplicacao: ~5.000 EUR/mes
• 100 instancias de base de dados: ~2.000 EUR/mes
• Total: ~7.000 EUR/mes (70 EUR por tenant)

Estes numeros sao simplificados, mas o padrao mantem-se. A infraestrutura partilhada e dramaticamente mais barata. Com 1.000 tenants, a diferenca torna-se ainda maior.

E por isto que os precos devem estar alinhados com a arquitetura. Se cobra 20 EUR por mes e opera infraestrutura single-tenant a 70 EUR por tenant, perde dinheiro em cada cliente.

Quando Escolher Multi-Tenant

A arquitetura multi-tenant e a escolha certa quando:

• Esta a construir SaaS B2B para PMEs. Alto volume, precos mais baixos e conjuntos de funcionalidades padrao.
• A eficiencia de custos importa. Precisa de manter os custos de infraestrutura baixos relativamente a receita.
• Quer atualizacoes rapidas e uniformes. Implemente uma vez, todos os tenants recebem a melhoria.
• Os seus clientes nao exigem infraestrutura dedicada. A maioria das pequenas e medias empresas nao se importa onde os seus dados estao, desde que estejam seguros.
• Esta nas fases iniciais. Comece multi-tenant. E mais barato e mais simples. Pode sempre oferecer single-tenant mais tarde para clientes enterprise.

Quando Escolher Single-Tenant

A arquitetura single-tenant faz sentido quando:

• Esta a vender a empresas grandes. Grandes organizacoes frequentemente exigem infraestrutura dedicada como parte do seu processo de aquisicao.
• A conformidade exige. Setores como saude (HIPAA), financas (SOX, PCI-DSS) e governo tem requisitos rigorosos de isolamento de dados.
• Os clientes precisam de personalizacao. Se cada cliente requer diferentes configuracoes, integracoes ou ate funcionalidades, single-tenant da-lhe a flexibilidade.
• O seu preco suporta. Se esta a cobrar 5.000 EUR ou mais por mes por cliente, o custo de infraestrutura e facilmente justificado.
• A residencia de dados e um requisito firme. Quando os dados devem residir num pais especifico, infraestrutura separada por tenant e a abordagem mais direta.

Abordagens Hibridas

Nao tem de escolher apenas uma. Muitas empresas SaaS de sucesso usam um modelo hibrido:

• Multi-tenant para niveis padrao. Clientes gratuitos, starter e pro partilham infraestrutura. Isto mantem custos baixos e permite escalar.
• Single-tenant para enterprise. Clientes premium obtem instancias dedicadas com SLAs personalizados, certificacoes de conformidade e suporte dedicado.

O codigo da aplicacao e o mesmo. O modelo de implementacao difere. Isto requer boa automacao de infraestrutura, mas e um padrao comprovado.

Como implementar um modelo hibrido

1. Construa a aplicacao como multi-tenant primeiro. Toda a logica de isolamento de tenant permanece a mesma independentemente do modelo de implementacao.
2. Use infrastructure-as-code (Terraform, Pulumi ou CDK) para automatizar a criacao de ambientes.
3. Crie um pipeline de provisionamento que possa criar um novo ambiente dedicado em minutos, nao dias.
4. Mantenha uma unica base de codigo. A mesma imagem Docker corre em ambientes partilhados e dedicados. A configuracao (nao o codigo) determina o comportamento.

Estrategias de Base de Dados em Detalhe

A base de dados e onde as decisoes de tenancy tem mais impacto. Eis tres estrategias comprovadas.

Estrategia 1: Tabelas partilhadas com tenant_id

Cada tabela tem uma coluna tenant_id. Todas as queries filtram por ela.

CREATE TABLE projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX idx_projects_tenant ON projects(tenant_id);

-- Always query with tenant context
SELECT * FROM projects WHERE tenant_id = $1;

Melhor para: A maioria dos produtos SaaS. Simples, custo-eficaz, bem compreendida.

Estrategia 2: Schema por tenant

Cada tenant obtem o seu proprio schema PostgreSQL dentro de uma base de dados partilhada. As tabelas tem a mesma estrutura, mas os dados sao fisicamente separados.

-- Create a schema for a new tenant
CREATE SCHEMA tenant_abc123;

-- Create tables in the tenant's schema
CREATE TABLE tenant_abc123.projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Set the search path per request
SET search_path TO tenant_abc123, public;

-- Now queries are automatically scoped
SELECT * FROM projects;

Melhor para: Produtos que precisam de isolamento mais forte que ao nivel de linha mas nao querem o custo de bases de dados separadas. Funciona bem ate algumas centenas de tenants.

Estrategia 3: Bases de dados separadas

Cada tenant obtem uma instancia PostgreSQL dedicada (ou uma base de dados dedicada num servidor partilhado).

// Database connection routing
class TenantDatabaseRouter {
  private connections: Map<string, DatabasePool> = new Map();

  async getConnection(tenantId: string): Promise<DatabasePool> {
    if (this.connections.has(tenantId)) {
      return this.connections.get(tenantId)!;
    }

    const config = await this.loadTenantDbConfig(tenantId);
    const pool = new DatabasePool({
      host: config.host,
      port: config.port,
      database: config.database,
      user: config.user,
      password: config.password,
    });

    this.connections.set(tenantId, pool);
    return pool;
  }

  private async loadTenantDbConfig(tenantId: string): Promise<DbConfig> {
    // Look up tenant's database connection details
    // from a central configuration store
    return await configStore.get(`tenants/${tenantId}/database`);
  }
}

Melhor para: SaaS empresarial com clientes de alto valor, requisitos de conformidade rigorosos ou obrigacoes de residencia de dados.

Tomar a Decisao

Eis um framework de decisao simples:

1. Qual e a dimensao do seu cliente-alvo? PME aponta para multi-tenant. Enterprise aponta para single-tenant ou hibrido.
2. Qual e o seu preco? Abaixo de 100 EUR/mes, precisa de multi-tenant para ser rentavel. Acima de 1.000 EUR/mes, single-tenant torna-se viavel.
3. Quais sao os requisitos de conformidade? Setores regulamentados frequentemente requerem isolamento mais forte.
4. Quantos tenants espera? Centenas ou milhares de tenants precisam de infraestrutura partilhada. Dez a cinquenta tenants grandes podem funcionar com instancias dedicadas.
5. Qual e a capacidade operacional da sua equipa? Single-tenant requer mais investimento em DevOps. Multi-tenant e operacionalmente mais simples.

Se nao tem a certeza, comece com multi-tenant usando uma base de dados partilhada e row-level security. E a opcao de menor custo, e segura quando implementada corretamente e mantem a sua arquitetura simples. Pode sempre adicionar um nivel dedicado para clientes enterprise mais tarde.

A Conclusao

Nao ha um modelo de tenancy universalmente correto. A escolha certa depende dos seus clientes, dos seus precos, dos seus requisitos de conformidade e das suas capacidades operacionais.

A maioria dos produtos SaaS deve comecar multi-tenant. E mais barato, mais simples e escala bem. A medida que se move para o mercado superior e comeca a vender a organizacoes maiores, adicione opcoes single-tenant para clientes que as precisam e que pagarao em conformidade.

A arquitetura deve servir o negocio, nao o contrario. Construa para os clientes que tem hoje e desenhe com flexibilidade suficiente para servir os clientes que quer amanha.

---

Precisa de ajuda a escolher a arquitetura certa para o seu produto SaaS? Construimos sistemas multi-tenant e single-tenant em varios setores. Vamos descobrir a melhor abordagem para o seu projeto.