Multi-tenancy em Laravel: Single DB vs Schema Separado vs Banco Separado

Multi-tenancy é um dos requisitos mais comuns em produtos SaaS — e também um dos que mais gera dúvidas arquiteturais. Neste post, vou analisar as três abordagens principais no contexto do Laravel, com trade-offs honestos para cada uma.

As Três Abordagens

1. Single Database (Coluna tenant_id)

A abordagem mais simples: todos os tenants compartilham o mesmo banco, e cada tabela tem uma coluna tenant_id que filtra os dados.

Schema::create('projects', function (Blueprint $table) {
    $table->id();
    $table->foreignId('tenant_id')->constrained();
    $table->string('name');
    $table->timestamps();
});

Vantagens:

• Implementação simples e manutenção fácil
• Migrations rodam uma vez para todos os tenants
• Queries cross-tenant são triviais (relatórios, analytics)
• Custo operacional baixo

Desvantagens:

• Risco de vazamento de dados se o tenant_id for esquecido em alguma query
• Um tenant grande pode impactar performance dos demais
• Menos isolamento regulatório (problema em setores como saúde e financeiro)

Use quando: B2C com muitos tenants pequenos, equipe pequena, ou no início do produto para validar.

2. Schema Separado (PostgreSQL)

Cada tenant recebe seu próprio schema no PostgreSQL. As tabelas são idênticas, mas os dados ficam completamente isolados.

Vantagens:

• Isolamento real de dados sem overhead de banco separado
• Backups por tenant ficam mais simples
• Performance melhor para tenants grandes (índices menores)

Desvantagens:

• Migrations precisam rodar em cada schema (mais complexidade)
• Não funciona com MySQL (que não tem schemas reais)
• Queries cross-tenant são mais complexas

3. Banco Separado por Tenant

Cada tenant tem seu próprio banco de dados com suas próprias credenciais.

Vantagens:

• Isolamento máximo — ideal para compliance (HIPAA, LGPD setorial)
• Um tenant não impacta outro em hipótese alguma
• Personalização total por tenant (backup schedule, retenção de dados)

Desvantagens:

• Custo operacional alto — cada banco tem overhead de conexão e storage
• Migrations viram um processo de orquestração complexo
• Difícil de operar com muitos tenants (>100)

O que Usar em 2025?

Para a maioria dos SaaS B2B, single database com boas práticas (Global Scopes, Tenancy Middleware) é o ponto de partida certo. Só mude se tiver requisitos regulatórios ou de escala que justifiquem a complexidade adicional.

Pacotes como Tenancy for Laravel e Stancl/Tenancy abstraem muito do trabalho pesado das abordagens 2 e 3.