dedicated e shared conforme se aplicam ao PostgreSQL.
Escolha dedicated quando o isolamento predomina
Use um banco de dados PostgreSQL dedicado por tenant quando o tenant precisa de uma fronteira forte de infraestrutura. O mesmo vale quando o tenant precisa de janelas de manutenção de banco de dados independentes, ou de um plano de recuperação desenhado em torno de um banco de dados dedicado. Exemplos típicos incluem uma instituição altamente regulada, um tenant de alto volume ou um tenant cuja carga de trabalho não deve compartilhar uma instância PostgreSQL com outros tenants. Essa escolha aumenta o custo de infraestrutura e de operação, então valide antes o desenho de conexão, backup e migração do produto.
Escolha shared quando a densidade predomina
Use um schema dedicado por tenant em um banco de dados PostgreSQL compartilhado quando o seu modelo de operação valoriza densidade e um custo de infraestrutura menor por tenant. O produto com suporte também deve conseguir operar no modo
shared.
Um incidente ou uma ação de manutenção no nível do banco de dados pode afetar os tenants na instância compartilhada. Planeje a capacidade, os backups, a recuperação e a manutenção em torno desse raio de impacto compartilhado.
Trate a migração como uma operação do produto
Não conte com uma promoção automática genérica de
shared para dedicated. Mover um tenant para armazenamento dedicado exige uma migração planejada pelo operador à qual o produto de destino ofereça suporte.
Antes de mudar um registro, estabeleça:
- o procedimento de migração com suporte no produto de destino
- um plano testado de backup, consistência e rollback
- uma janela de manutenção e um plano de comunicação
- verificações pós-migração de autenticação, roteamento e dados do tenant.
Checklist de decisão
Páginas relacionadas
Multi-tenancy
Suporte por produto, escopo das requisições e conceitos de armazenamento.