> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Casos de uso de multi-tenancy > Escolha o isolamento dedicado ou compartilhado no PostgreSQL para um serviço de tenant BYOC com suporte. Escolha um modo de isolamento por serviço de tenant depois de confirmar que o produto oferece suporte a multi-tenancy. Nos registros do Tenant Manager, os valores são `dedicated` e `shared`. Esta página usa os conceitos correspondentes do PostgreSQL `DATABASE` e `SCHEMA`. ## Escolha `DATABASE` (`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 `SCHEMA` (`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 `SCHEMA` para `DATABASE`. 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: 1. o procedimento de migração com suporte no produto de destino 2. um plano testado de backup, consistência e rollback 3. uma janela de manutenção e um plano de comunicação 4. verificações pós-migração de autenticação, roteamento e dados do tenant. ## Checklist de decisão *** | Pergunta | Favorece `DATABASE` | Favorece `SCHEMA` | | :------------------------------------------------------------------------------------------- | :------------------ | :---------------- | | O tenant exige uma fronteira de banco de dados dedicada? | Sim | Não | | O tenant pode compartilhar um domínio de manutenção e incidentes no nível do banco de dados? | Não | Sim | | O custo de infraestrutura por tenant é aceitável? | Sim | Não | | O produto oferece suporte ao modo selecionado de forma explícita? | Obrigatório | Obrigatório | ## Páginas relacionadas *** Suporte por produto, escopo das requisições e conceitos de armazenamento. Como os registros de serviço de tenant provisionam os recursos com suporte.