O Cluster PostgreSQL
Em PostgreSQL, a palavra "cluster" não significa um grupo de máquinas em rede como em quase todos os outros lugares do vocabulário de bancos de dados.
//
Busque em todas as páginas da documentação
Em PostgreSQL, a palavra "cluster" não significa um grupo de máquinas em rede como em quase todos os outros lugares do vocabulário de bancos de dados.
Significa a única instância de servidor em execução e tudo o que essa instância possui: seu diretório de dados, sua memória compartilhada, suas roles e cada banco de dados criado dentro dela.
initdb, mantendo todos os bancos de dados, roles e memória compartilhada que essa instância gerencia em conjunto.max_connections como um orçamento compartilhado, ou planejar o isolamento multi-tenant.Todo servidor PostgreSQL começa sua vida com um único comando: initdb.
Esse comando cria um diretório no disco, convencionalmente chamado PGDATA, e tudo o que a instância do servidor gerenciará um dia vive dentro dele.
Este diretório PGDATA, mais o processo postmaster em execução que o atende, é o que a palavra "cluster" se refere em PostgreSQL.
Uma analogia útil é um prédio de escritórios: o cluster é o próprio prédio, os bancos de dados são os andares, os schemas são as salas em cada andar, e as tabelas são os arquivos dentro de cada sala.
Um prédio tem um saguão, um conjunto de elevadores e um balcão de segurança, não importa quantos andares ele tenha.
Da mesma forma, um cluster tem um processo postmaster, uma região de memória compartilhada e um conjunto de roles, não importa quantos bancos de dados vivam dentro dele.
CREATE DATABASE não inicia um novo processo de servidor nem aloca um bloco separado de memória compartilhada.
Ele copia um banco de dados template (template1 por padrão) para uma nova entrada de banco de dados dentro da mesma instância em execução.
Essa única instância compartilhada é também o motivo pelo qual o termo é confuso no início: não tem nada a ver com clustering de alta disponibilidade, conjuntos de réplicas ou grupos de failover gerenciados por Patroni, que são um conceito completamente diferente e de nível superior construído sobre clusters individuais.
Um único arquivo postgresql.conf governa todo o cluster, então configurações como shared_buffers e max_connections são orçamentos para todo o cluster, não permissões por banco de dados.
ALTER DATABASE ... SET e ALTER ROLE ... SET permitem substituir configurações específicas para um banco de dados ou role, mas elas se sobrepõem aos padrões do cluster em vez de substituir a instância compartilhada por baixo delas.
As roles são o exemplo mais claro desse escopo compartilhado, pois uma role criada em um banco de dados é visível e utilizável de qualquer banco de dados no cluster, mesmo que seus privilégios em nível de objeto sejam tipicamente concedidos por banco de dados.
Um processo backend se conecta a exatamente um banco de dados por vez, e não há JOIN entre bancos de dados embutido; acessar outro banco de dados no mesmo cluster requer dblink ou um foreign data wrapper, tratando-o quase como um servidor remoto.
-- Fatos do cluster vs fatos por banco de dados
SHOW data_directory; -- um caminho, cluster inteiro
SELECT datname FROM pg_database; -- cada banco de dados que este cluster possui
SELECT rolname FROM pg_roles; -- roles são visíveis em todo o clusterTablespaces permitem que você coloque bancos de dados individuais, tabelas ou índices em discos físicos diferentes enquanto permanece dentro do mesmo cluster lógico, o que é uma decisão de layout de armazenamento em vez de uma decisão de isolamento.
O WAL (write-ahead log) é gerado como um único fluxo em todo o cluster, que é exatamente o motivo pelo qual a replicação e a recuperação point-in-time são configuradas uma vez por cluster em vez de uma vez por banco de dados.
Como o stream WAL e o pool de buffers compartilhados são ambos em todo o cluster, um pico de atividade de escrita em um banco de dados compete diretamente pelo mesmo orçamento de I/O e memória que todos os outros bancos de dados nessa instância.
Atualizações de versão principal operam em todo o cluster de uma vez, pois pg_upgrade migra todos os bancos de dados em PGDATA juntos e não há como executar o PostgreSQL 17 para um banco de dados e o PostgreSQL 18 para outro dentro da mesma instância.
Essa restrição de versão única é uma entrada de planejamento real para sistemas multi-tenant, pois significa que todos os tenants que compartilham um cluster são forçados à mesma programação de atualização, quer estejam prontos ou não.
max_connections é a restrição de recurso compartilhado mais crítica na prática, pois é definida uma vez para todo o cluster e todos os bancos de dados, todas as roles e todas as aplicações competem pelo mesmo pool de slots de backend, que é exatamente por que o pool de conexões é importante mesmo em um cluster com pouca carga.
A granularidade do backup segue a mesma divisão de tudo o mais: pg_basebackup captura o cluster inteiro como uma unidade física, enquanto pg_dump pode ter como alvo um único banco de dados para um backup lógico e mais seletivo.
Os limites de segurança precisam da mesma correção, pois as credenciais de login de uma role funcionam em todos os bancos de dados do cluster, embora as instruções GRANT escopem seus privilégios reais por banco de dados ou por objeto, então "banco de dados diferente" não é a mesma garantia que "login diferente".
| Abordagem de isolamento | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| Schema por tenant, um banco de dados | Mais barato; pool de conexões único; relatórios fáceis entre tenants | Isolamento mais fraco; uma consulta ruim afeta a todos | Pequenas equipes, baixo número de tenants, tenants confiáveis |
| Banco de dados por tenant, um cluster | Isolamento mais forte; backup/restauração por banco de dados | Ainda compartilha max_connections, buffers compartilhados e atualizações de versão | SaaS de médio porte que busca isolamento sem nova infraestrutura |
| Cluster por tenant | Isolamento completo de recursos e versão | Custo operacional mais alto; mais instâncias para corrigir e monitorar | Tenants regulamentados ou de alto valor que precisam de isolamento rigoroso |
initdb, por mais confusa que essa sobreposição com o vocabulário moderno de HA possa parecer.postmaster em execução atendem a todos os bancos de dados em PGDATA, então todo o cluster é atualizado em conjunto via pg_upgrade.postmaster, o que derruba todos os bancos de dados no cluster de uma vez.max_connections, buffers compartilhados e taxa de transferência WAL, então os ganhos de isolamento vêm com trade-offs reais de recursos compartilhados.Refere-se a uma instância de servidor e seu diretório de dados (PGDATA), criada por uma única chamada initdb, juntamente com todos os bancos de dados e roles que essa instância gerencia.
Um cluster é toda a instância em execução; um banco de dados é um dos muitos contêineres lógicos potenciais dentro dessa instância, cada um com suas próprias tabelas e schemas, mas compartilhando as roles e recursos do cluster.
Sim, sempre - um binário atende a todo o cluster, então uma atualização de versão principal via pg_upgrade move todos os bancos de dados desse cluster juntos.
Sim - uma role criada em um banco de dados é visível e pode fazer login de qualquer banco de dados no mesmo cluster, mesmo que seus privilégios reais sejam concedidos por banco de dados ou por objeto.
Não - um backend se conecta a um banco de dados por vez, então o acesso entre bancos de dados requer dblink ou um foreign data wrapper em vez de um JOIN nativo.
Por cluster - é um orçamento compartilhado de slots de conexão de backend pelos quais todos os bancos de dados e todas as aplicações competem, que é um motivo importante pelo qual o pool de conexões é importante.
CREATE DATABASE funciona copiando um banco de dados template existente, template1 por padrão, para uma nova entrada dentro do mesmo cluster em vez de iniciar um novo processo de servidor.
Não - uma reinicialização para e inicia o único processo postmaster para todo o cluster, então todos os bancos de dados nessa instância caem e voltam juntos.
Um tablespace é uma decisão de localização de armazenamento, permitindo que você coloque dados em um disco diferente; um banco de dados é um limite de isolamento lógico para tabelas e schemas, e qualquer um pode usar qualquer tablespace no cluster.
Use banco de dados por tenant quando precisar de isolamento mais forte e backup e restauração por tenant, e puder aceitar que os tenants ainda compartilham o limite de conexão do cluster e o cronograma de atualização de versão.
Quando requisitos regulatórios ou preocupações com raio de explosão exigem isolamento completo de recursos e versão, pois um cluster separado é a única opção que remove completamente o compartilhamento de max_connections, buffers compartilhados e tempo de atualização.
Não diretamente - Patroni gerencia o failover de alta disponibilidade entre clusters PostgreSQL (um primário e suas réplicas), enquanto "cluster" em si apenas descreve uma dessas instâncias individuais.
initdb realmente cria no discoVersões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, linha de manutenção 17).
Revisado por Chris St. John·Última atualização: 15 de jul. de 2026