> ## 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 isolamento PostgreSQL dedicado ou compartilhado para um serviço de tenant BYOC compatível.

Escolha um modo de isolamento por serviço de tenant depois de confirmar que o produto suporta multi-tenancy. Nos registros do Tenant Manager, os valores são `dedicated` e `shared`; esta página usa os conceitos PostgreSQL correspondentes `DATABASE` e `SCHEMA`.

## Escolha `DATABASE` (`dedicated`) quando isolamento predomina

***

Use um banco PostgreSQL dedicado por tenant quando ele precisar de um limite de infraestrutura forte, janelas independentes de manutenção de banco ou um plano de recuperação desenhado para um banco dedicado.

Exemplos típicos incluem uma instituição altamente regulada, um tenant de alto volume ou um tenant cuja carga não deve compartilhar uma instância PostgreSQL com outros tenants. Essa escolha aumenta o custo de infraestrutura e operação; valide antes o desenho de conexões, backups e migrações do produto.

## Escolha `SCHEMA` (`shared`) quando densidade predomina

***

Use um schema dedicado por tenant em um banco PostgreSQL compartilhado quando o produto compatível puder operar no modo `shared` e seu modelo operacional valorizar densidade e menor custo de infraestrutura por tenant.

Um incidente ou ação de manutenção no nível do banco pode afetar tenants na instância compartilhada. Planeje capacidade, backups, recuperação e manutenção para esse raio de impacto compartilhado.

## Trate a migração como uma operação de produto

***

Não dependa de uma promoção automática genérica de `SCHEMA` para `DATABASE`. Mover um tenant para armazenamento dedicado exige uma migração planejada pelo operador e suportada pelo produto alvo.

Antes de mudar um registro, defina:

1. o procedimento de migração suportado pelo produto alvo;
2. um plano testado de backup, consistência e rollback;
3. uma janela de manutenção e plano de comunicação; e
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 um limite de banco dedicado?                                      | Sim                 | Não               |
| O tenant pode compartilhar domínio de manutenção e incidentes no nível do banco? | Não                 | Sim               |
| O custo de infraestrutura por tenant é aceitável?                                | Sim                 | Não               |
| O produto suporta explicitamente o modo escolhido?                               | Obrigatório         | Obrigatório       |

## Páginas relacionadas

***

<CardGroup cols={2}>
  <Card title="Multi-tenancy" icon="layer-group" href="/pt/multi-tenancy" cta="Ver visão geral">
    Suporte por produto, escopo de requisições e conceitos de armazenamento.
  </Card>

  <Card title="Provisionamento automático" icon="wand-magic-sparkles" href="/pt/multi-tenancy/auto-provisioning" cta="Ver provisionamento">
    Como registros de serviço de tenant provisionam recursos compatíveis.
  </Card>
</CardGroup>
