Um sistema, vários clientes, sem virar bagunça
Como um sistema só atende várias empresas sem misturar os dados de ninguém, e o que quebra quando o primeiro cliente grande chega.
O problema que multi-tenant resolve
Multi-tenant é quando o mesmo sistema atende vários clientes, cada um enxergando só o que é dele. Parece detalhe técnico, mas é decisão de negócio: é o que separa vender um software de vender o mesmo software cinquenta vezes.
A alternativa é subir uma cópia por cliente. Funciona nos três primeiros e vira inferno no décimo, quando você precisa aplicar uma correção e tem dez servidores, dez bancos e dez versões ligeiramente diferentes pra atualizar.
Três formas de isolar, e o preço de cada uma
Um banco por cliente é o isolamento mais forte e o mais caro de manter: cada migração roda N vezes e qualquer relatório que cruze clientes vira trabalho manual.
Um schema por cliente é o meio termo, e costuma ser o pior dos dois mundos em escala: você ainda multiplica migração, mas já perdeu a simplicidade do banco único.
Uma coluna de cliente em cada tabela é o que eu uso na maioria dos casos. Migração roda uma vez, relatório é uma consulta, e o isolamento passa a depender de disciplina no acesso, que é onde mora o risco.
O erro que vaza dado entre clientes
Com coluna de cliente, o vazamento não acontece por invasão. Acontece por esquecimento: uma consulta sem o filtro do cliente, num relatório que ninguém revisou, e de repente um cliente vê o número do outro.
Por isso o filtro não pode depender de o desenvolvedor lembrar. Ele tem que estar na camada que lê o banco, aplicado por padrão, de forma que consultar sem cliente definido seja erro e não descuido. Se o teu banco suporta política por linha, melhor ainda: aí a regra vive junto do dado.
Um endereço só
Subdomínio por cliente parece profissional e cobra caro depois: certificado, DNS, e um monte de caso estranho de login entre domínios.
Prefiro um endereço único, com o cliente resolvido depois do login. Quem precisa de marca própria ganha isso na tela, não na URL. E quando alguém realmente precisa do próprio domínio, aí sim vale o trabalho, pra esse cliente.
O que quebra quando o cliente grande chega
Enquanto todo mundo é pequeno, tudo parece rápido. O primeiro cliente com volume alto revela o que estava escondido: consulta sem índice pelo campo do cliente, relatório que varre a tabela inteira, e trabalho pesado rodando no meio da requisição em vez de numa fila.
Nada disso é difícil de resolver, mas é bem mais barato resolver antes, quando ainda dá pra mudar o formato dos dados sem precisar avisar ninguém.
Como eu monto hoje
Banco único com coluna de cliente, filtro aplicado na camada de acesso, índice composto começando pelo cliente, um endereço só e trabalho pesado em fila. É o que roda no Fluxnavi e no que eu construo pra cliente.
Se você está montando um SaaS agora, essa é a hora barata de acertar. Depois de cem clientes, mudar isolamento é migração, não decisão.
Tem um sistema no ar sem dono?
Assumo o que outra pessoa começou, fecho o que está vazando e sigo dali.