Banco de dados dedicado versus compartilhado: desempenho e isolamento

A documentação oficial da Microsoft sobre a arquitetura de aplicativos SaaS multilocatários distingue três modelos de locação, geralmente chamados de Silo (recursos dedicados por locatário), Pool (recursos totalmente compartilhados) e Bridge (uma mistura dos dois, alguns locatários isolados, outros compartilhados). Esses três modelos se aplicam diretamente ao Postgres, no nível do esquema, do banco de dados ou de todo o cluster.

Concretamente, para um back-end do Postgres, isso fornece três arquiteturas distintas. O esquema compartilhado (uma base única, uma coluna tenant_id, políticas RLS que filtram as linhas) é o modelo de Pool mais comum em guias multilocatários: econômico, mas a fronteira entre dois clientes se torna uma expressão SQL avaliada tabela por tabela. A base por locatário em um cluster compartilhado é um modelo Bridge intermediário: cada locatário tem sua própria base Postgres (um comando CREATE DATABASEreal), mas várias bases coexistem no mesmo cluster físico, compartilhando, portanto, CPU, IO e conexões. O cluster totalmente dedicado por locatário é o modelo Silo completo: recursos de CPU, RAM e IO completamente isolados, geralmente reservados para locatários com alta conformidade ou problemas de carga.

Terminologia Silo/Pool/Bridge: documentação oficial da Microsoft, padrões de arquitetura SaaS multi-tenant (Azure Architecture Center).

O modelo intermediário, base por locatário em um cluster compartilhado, muitas vezes está ausente dos guias que apresentam a escolha como binária entre “uma base única para todos” e “um servidor por cliente”. No entanto, este é o que o Aurabase usa por padrão, detalhado abaixo.

A escolha entre esses três modelos surge com cada decisão de arquitetura multilocatário, não apenas com um provedor de BaaS: uma equipe que constrói seu próprio back-end SaaS em Postgres gerenciados (RDS, Cloud SQL ou uma instância auto-hospedada) faz exatamente a mesma arbitragem, com os mesmos mecanismos de contenção em ação, uma vez que vários clientes são colocados na mesma instância física.

Um noisy neighbor (vizinho barulhento) é um locatário que consome uma parcela desproporcional dos recursos compartilhados de uma infraestrutura, em detrimento de outros locatários no mesmo servidor. O termo vem da nuvem pública, mas se aplica diretamente a um cluster Postgres compartilhado: um banco de dados pode degradar o desempenho de outros sem nunca tocar em seus dados.

Seis mecanismos surgem com mais frequência na produção:

• Contenção de CPU: uma consulta cara (junção sem índice, classificação massiva) consome ciclos de CPU que o kernel compartilha entre todos os bancos de dados ativos no cluster.
• Contenção de IOPS: um backup, um VACUUM FULL ou uma importação massiva satura a taxa de transferência do disco do cluster, retardando leituras e gravações em outros bancos de dados.
• Esgotamento da conexão: max_connections limita o número de conexões ativas em todo o nível do cluster, não por base. Uma base que abre demais diminui a margem das outras.
• Contenção de autovacuum: o autovacuum é executado com um número limitado de trabalhadores por cluster; um banco de dados com alta taxa de gravação pode atrasar a limpeza das tabelas de outro banco de dados.
• Remoção de cache: shared_buffers é uma memória única para todo o cluster; um banco de dados com um grande conjunto de trabalhos pode remover as páginas em cache de um banco de dados vizinho menor.
• Janelas de manutenção compartilhadas: backup, failover de réplica ou atualização principal aplicam-se a todo o cluster, não por base.

Diagrama estrutural, não um resultado de medição: nenhum número comparativo de desempenho publicado até o momento para essas duas topologias.

O orçamento de conexão costuma ser o sintoma mais visível na produção, mesmo antes da latência. Este é o assunto detalhado de nosso guia de ajuste de max_connections e nossa comparação PgBouncer, Supavisor e PgCat.

Um pooler de modo de transação (PgBouncer, Supavisor, PgCat) atenua o esgotamento da conexão, mas não remove a contenção de CPU ou IOPS: ele reutiliza conexões de servidor existentes, não adiciona núcleos de CPU adicionais ou taxa de transferência de disco ao cluster. Nosso artigo sobre o modo de pool de transações detalha o que esse modo realmente muda e o que ele não muda.

A segurança em nível de linha resolve um problema diferente: evita que uma consulta leia ou modifique as linhas de outro locatário, no nível lógico. Ele não reserva nenhum ciclo de CPU, nenhum slot de conexão, nenhuma taxa de transferência de disco para um locatário específico.

Dois inquilinos podem ter políticas de RLS perfeitamente estanques e degradar-se ao mesmo tempo: o vizinho barulhento é um problema de recursos físicos, não de direitos de acesso. Confundir os dois leva a uma falsa sensação de segurança operacional quando o EPIRB estiver em vigor.

O código do provisionador (aura-provisioner) documenta exatamente duas arquiteturas possíveis para um projeto Postgres ativo, a partir de uma consolidação de provisionamento que o código chama de Tarefa 12: FullyDedicated e SharedClusterDedicated. Os modelos legados com granularidade de esquema foram removidos do caminho de provisionamento.

O nível enterprise aciona FullyDedicated: um cluster CNPG inteiro, reservado para este único projeto. Todos os outros níveis (gratuito, profissional, equipe) são direcionados para SharedClusterDedicated: um banco de dados Postgres project_<uuid> completo, no cluster CNPG da organização do projeto. Portanto, não é um esquema compartilhado: mesmo em um plano padrão, seu banco de dados é um banco de dados Postgres completo, e não uma linha entre outras em uma tabela comum. O que é compartilhado é o cluster (CPU, RAM, disco, conexões), não a base em si.

O cluster CNPG de uma organização é criado quando seu primeiro projeto Postgres é provisionado e nunca hospeda um projeto de outra organização, uma opção de design bloqueada no nível do código (org_cluster.rs, bloqueio de aconselhamento do Postgres por organização na criação). O único possível vizinho barulhento no patamar compartilhado do Aurabase é, portanto, outro projeto de sua própria organização, nunca de um cliente terceirizado.

/// Capacidade nominal (número de bases de projetos) de um cluster organizacional.
/// Limite de observabilidade: além disso, direcione a organização para FullyDedicated.
/// Controlável via FLEET_CLUSTER_CAPACITY (padrão 1000, limitado [1, 1_000_000]).
pub fn fleet_cluster_capacity() -> i32 {
    std::env::var("FLEET_CLUSTER_CAPACITY")
        .ok()
        .and_then(|v| v.parse::<i32>().ok())
        .filter(|n| (1..=1_000_000).contains(n))
        .unwrap_or(1000)
}

Especificações de arquitetura de cluster PostgreSQL gerenciada pela Aurabase.

Este limite de 1.000 bases por cluster não é um limite rígido: é um benchmark de observabilidade que aciona uma recomendação para migrar para FullyDedicated, não um bloqueio automático. Ele não orienta mais nenhuma decisão de posicionamento; agora é possível apenas um cluster por organização.

Cada cluster, dedicado ou frota, expõe um Pooler CNPG (PgBouncer) que absorve parte da pressão nas conexões ativas, em ambas as topologias. O que esse pooler realmente altera para a contenção de recursos é detalhado abaixo.

O dimensionamento de CPU/RAM de um cluster compartilhado também não é uniforme entre organizações: ele deriva do nível da organização através de uma função dedicada (FleetSizing::from_org_plan, verificada em org_cluster.rs), e não de um tamanho único aplicado a todos os níveis. Uma organização no nível de equipe não dimensiona seu cluster da mesma forma que uma organização no nível livre.

Essas duas arquiteturas rodam no PostgreSQL 16, e não na versão 17, verificada no Dockerfile da imagem CNPG utilizada na produção. Esta escolha de versão tem suas próprias implicações de ajuste, detalhadas em nossa comparação Postgres 16 vs 17 vs 18.

Para projetos sujeitos a uma obrigação contratual de isolamento físico documentado, nossas páginas DPA e detalham o que cada nível cobre.

A desvantagem do modelo base por locatário, destacada por diversas ferramentas de gerenciamento de migração de esquema como o Bytebase, é operacional e não técnica: cada migração deve ser aplicada e verificada em cada base, uma por uma, mesmo quando coexistem no mesmo cluster. Um cluster totalmente dedicado não elimina esse custo, até o acrescenta: uma migração por cluster para monitorar de forma independente, em vez de apenas uma.

Recursos especializados em arquitetura de software multilocatário, como CodeOpinion, apresentam regularmente essa abordagem intermediária (por locatário em infraestrutura compartilhada) como um compromisso razoável entre o esquema compartilhado e o cluster totalmente dedicado, em vez de uma escolha binária entre os dois extremos.

Passar de compartilhado para dedicado não requer reescrever um esquema ou alterar mecanismos: em ambos os casos, é Postgres, com a mesma cadeia pg_dump / pg_restore descrita em nosso guia de migração Supabase para Aurabase. Alterar o nível continua sendo uma operação de alternância, não uma reescrita do aplicativo.

Base dedicada e base compartilhada não entram em conflito na segurança dos dados: ambos os modelos podem isolar corretamente um inquilino de outro no nível lógico. Eles se opõem em recursos físicos (CPU, IOPS, conexões, cache, janelas de manutenção). É este plano que define um vizinho barulhento, e não uma política de RLS mal escrita.

O modelo Aurabase, verificado no código do provisionador, mantém por padrão um compromisso intermediário: um banco de dados Postgres dedicado por projeto, em um cluster compartilhado, mas estritamente reservado para uma única organização, com um cluster totalmente dedicado reservado para o nível de negócios. A escolha certa depende dos seus reais constrangimentos e não de um reflexo onde o dedicado seria sempre a melhor opção.