Pular para o conteúdo principal
Escolher um modo de isolamento é um trade-off entre força do isolamento e custo operacional. Esta página percorre dois cenários realistas — um para cada modo — e mostra como um deployment pode começar em um modo e migrar para o outro à medida que cresce. Para a comparação completa entre os modos, veja Modos de isolamento em Multi-tenancy.

​
Quando escolher cada modo

Modo DATABASE

Isolamento máximo — um banco de dados separado por tenant. Melhor quando os tenants são grandes, regulados ou sensíveis a noisy neighbors e você consegue absorver um custo por tenant mais alto.

Modo SCHEMA

Isolamento eficiente — um schema separado por tenant dentro de um banco de dados compartilhado. Melhor para muitos tenants menores, onde densidade e eficiência de custo importam mais.

​
Exemplo 1 — Fintech regulada e de alto volume

O “Banco ACME” é uma instituição financeira licenciada que processa um alto volume de transações sob rigorosa supervisão regulatória. Requisitos:
  • Isolamento físico forte para satisfazer auditores e reguladores.
  • O menor blast radius possível — um incidente que afete um tenant não pode tocar os outros.
  • A capacidade de fazer backup e restore de um único tenant de forma independente, incluindo point-in-time recovery.
  • Performance previsível sob carga pesada e sustentada.
Modo recomendado: DATABASE O Banco ACME roda no modo DATABASE. Cada tenant recebe um banco de dados PostgreSQL dedicado, então:
  • O isolamento físico é completo — não há superfície de schema compartilhada entre tenants.
  • O blast radius de qualquer falha, migration ou restore fica confinado a um único tenant.
  • Um restore seletivo toca apenas o banco de dados do tenant afetado, sem impacto nos demais.
  • O isolamento de performance é forte, já que os tenants não compartilham espaço de tabelas nem competem dentro do mesmo banco de dados.
O custo de infraestrutura por tenant mais alto do modo DATABASE se justifica aqui pelos requisitos regulatórios e de isolamento — e por volumes de transação que, por si só, tornariam o isolamento de performance valioso.

​
Exemplo 2 — Startup em estágio inicial

A “FinX” é uma startup em estágio inicial que faz o onboarding de muitos clientes pequenos rapidamente, com restrições apertadas de custo e volume modesto por tenant. Requisitos:
  • Custo baixo por tenant para suportar um grande número de contas pequenas.
  • Onboarding rápido de novos tenants.
  • Isolamento bom o suficiente para o estágio atual, com margem para reforçar depois.
Modo recomendado: SCHEMA A FinX roda no modo SCHEMA. Cada tenant recebe um schema dedicado dentro de um banco de dados PostgreSQL compartilhado, então:
  • O custo de infraestrutura permanece baixo porque os tenants compartilham uma instância de banco de dados.
  • Os dados do tenant ainda são logicamente isolados — o schema de um tenant nunca é alcançável a partir do de outro.
  • O onboarding é leve, o que combina com uma alta taxa de cadastros de tenants pequenos.
O modo SCHEMA compartilha uma instância de banco de dados entre tenants, então o blast radius de um incidente no nível do banco de dados é mais amplo e o isolamento de performance é mais fraco do que no modo DATABASE. Planeje migrar tenants de alto valor ou alto volume à medida que eles crescem.

​
Um caminho de migração à medida que a FinX cresce

Quando um dos tenants da FinX se torna grande, regulado ou sensível a performance, a FinX pode migrar esse tenant do modo SCHEMA para o DATABASE — sem reemitir tokens nem alterar a identidade do tenant, porque o isolamento é uma propriedade do serviço, não do tenant.
1

Identifique o tenant a ser promovido

Escolha o tenant cujo volume, perfil de risco ou necessidades de conformidade agora justificam um banco de dados dedicado.
2

Provisione um banco de dados dedicado

A plataforma provisiona um novo banco de dados PostgreSQL isolado para o tenant e executa as migrations, exatamente como no provisionamento automático.
3

Migre os dados do tenant

Os dados do tenant são movidos do schema no banco de dados compartilhado para o novo banco de dados dedicado.
4

Reaponte o serviço

O registro de serviço do tenant é atualizado para a configuração do modo DATABASE. A claim tenantId permanece inalterada, então as integrações continuam funcionando sem modificação.
Começar no modo SCHEMA e promover tenants individuais para o modo DATABASE permite manter os custos baixos no início e reservar bancos de dados dedicados para os tenants que realmente precisam deles.

​
Páginas relacionadas

Multi-tenancy

A comparação completa entre DATABASE vs. SCHEMA e o fluxo de migração.

Provisionamento automático

Como a infraestrutura de um tenant é provisionada e migrada.

Segurança

Garantias de isolamento e credenciais para ambos os modos.