Postgres max_connections sem pooler

O Postgres não usa um pool de threads leve para suas conexões. Cada conexão do cliente aciona um processo de sistema completo.

O processo postmaster cria um novo (“fork”) para cada tentativa de conexão, dedicado a esta única sessão até que ela seja fechada. A documentação oficial do projeto descreve precisamente esse mecanismo em seu capítulo sobre fundamentos arquitetônicos (postgresql.org/docs/current/connect-estab.html, seção “Connection Semantics”, acessado em 24 de agosto de 2026).

Esta escolha tem uma vantagem real: uma falha em uma conexão não afeta as outras, ficando cada processo isolado do resto do servidor. Também tem um custo direto: cada conexão adicional adiciona um processo inteiro do sistema operacional para agendar, com seu próprio espaço de memória e sua própria sobrecarga de troca de contexto para o kernel.

Dois mecanismos distintos afetam a memória e confundi-los quase sempre leva a um diagnóstico errado.

O primeiro está consertado. Na inicialização, o Postgres reserva estruturas de memória compartilhada (bloqueios, tabela de processos) dimensionadas no valor de max_connections, independentemente de essas conexões serem abertas posteriormente ou não. A documentação oficial para a configuração aponta explicitamente: aumentá-la pode exigir mais memória compartilhada do sistema do que a configuração padrão do seu sistema operacional permite (postgresql.org/docs/current/runtime-config-connection.html, acessado em 24 de agosto de 2026).

A segunda é variável e muito mais perigosa em escala: work_mem não é alocado uma vez por conexão, mas uma vez por operação de classificação ou hash no plano de consulta. A documentação oficial é explícita neste ponto: uma consulta complexa pode lançar várias dessas operações em paralelo, e várias sessões podem fazer o mesmo simultaneamente, de modo que a memória realmente utilizada pode valer várias vezes work_mem (postgresql.org/docs/current/runtime-config-resource.html, acessado em 24 de agosto de 2026).

O wiki oficial do projeto PostgreSQL documenta uma fórmula de referência para calcular quantas conexões ativas seu hardware pode processar eficientemente em paralelo, não quantas conexões abertas no total (wiki.postgresql.org/wiki/Number_Of_Database_Connections, acessado em 24 de agosto de 2026).

Em um servidor com 8 núcleos físicos e armazenamento SSD, a fórmula fornece (8 × 2) + 1 = 17 conexões ativas antes que o rendimento comece a diminuir. Esse número costuma ser surpreendente: parece minúsculo comparado às centenas de conexões que um aplicativo abre na prática. Este é precisamente o assunto do parágrafo seguinte.

O número calculado pela fórmula mede a simultaneidade que a CPU e o disco podem absorver, e não o número de conexões de cliente que seu aplicativo precisa abrir. Uma frota de 20 processos de aplicação, cada um com seu próprio conjunto de 10 conexões, abre 200 conexões simultâneas com o Postgres, mesmo que apenas 17 delas estejam funcionando ativamente em um determinado momento. Sem um pooler, max_connections deve cobrir 200, não 17. É essa lacuna que leva a maioria das arquiteturas a adicionar um pooler no modo de transação, mesmo que isso signifique escolher qual deles (veja nossa comparação PgBouncer, Supavisor e PgCat).

max_connections não é hot swap. Este é um parâmetro de contexto postmaster: o Postgres o lê uma vez, na inicialização, para dimensionar sua memória compartilhada. Uma recarga de configuração (pg_reload_conf() ou SIGHUP) não é suficiente, é necessário reiniciar o servidor.

Primeiro verifique o valor atual e seu contexto, para confirmar se será necessário reiniciar:

SHOW max_connections;

SELECT name, setting, context
FROM pg_settings
WHERE name = 'max_connections';

-- context='postmaster' confirma que uma reinicialização é necessária

Em seguida, aplique o novo valor e reinicie:

ALTER SYSTEM SET max_connections = '300';

-- Escrito em postgresql.auto.conf.
-- Nenhum efeito até que o Postgres seja reiniciado.

# Com sistema
sudo systemctl restart postgresql

# Sem systemd, diretamente com pg_ctl
pg_ctl restart -D $PGDATA -m fast

Dimensionar max_connections não é apenas um exercício teórico. Aqui está como a Aurabase faz o orçamento em seus clusters Postgres gerenciados:

Clusters dedicados: um cluster Postgres por projeto

Neste nível (veja nossa comparação dedicada vs base compartilhada), cada projeto recebe seu próprio cluster CloudNativePG e seu próprio orçamento max_connections, dimensionado com o tamanho da instância:

Clusters compartilhados: vários projetos de uma organização, um orçamento compartilhado

Neste segundo caminho, todos os projetos da mesma organização se conectam através de um pooler CNPG (PgBouncer, modo transaction) na frente de um primário compartilhado:

Todos os projetos de uma organização se conectam por meio de uma função de aplicativo compartilhada. max_user_connections portanto, por si só, limita o total de conexões de servidor que esta função pode abrir em todo o cluster: esta é a verdadeira proteção global do cluster, não max_client_conn, que limita apenas as conexões do cliente ao próprio pooler.

No entanto, esse pooler atende apenas ao tráfego de aplicativos SDK. O PostgREST, por sua vez, permanece diretamente conectado ao primário (serviço-rw): o pooling no modo de transação quebraria seu mecanismo de recarga de esquema, que escuta um canal LISTEN dedicado chamado pgrst. Suas próprias conexões (2 por réplica no nível compartilhado, 10 por réplica no nível dedicado) contam, portanto, diretamente no orçamento max_connections do primário, fora de qualquer pooler, exatamente o tipo de conexão “esquecida” que a etapa 1 do procedimento abaixo deve incluir.

Este procedimento não depende de nenhuma ferramenta específica: aplica-se a qualquer servidor Postgres, gerenciado ou auto-hospedado.

1. Conte suas conexões reais de cliente. Número de processos de aplicação multiplicado pelo tamanho do seu pool interno, além de ferramentas de administração, replicação e monitoramento. É esse número, e não a fórmula, que define o limite mínimo de max_connections.
2. Calcule a simultaneidade ideal do seu hardware com a fórmula do wiki do PostgreSQL: (núcleos físicos × 2) + discos eficientes. Este número indica quantas dessas conexões podem realmente funcionar em paralelo sem degradar o rendimento.
3. Defina max_connections acima da necessidade real da etapa 1, com margem para superuser_reserved_connections e para quaisquer ferramentas administrativas que abram suas próprias conexões fora do aplicativo.
4. Aplique a alteração com ALTER SYSTEM SET e reinicie o servidor. Este é um parâmetro do postmaster: uma simples recarga não é suficiente, conforme detalhado acima.
5. Monitore pg_stat_activity ao longo do tempo. Se o número de conexões ociosas exceder muito o número de conexões ativas, isso não é um problema de max_connections: é o sinal de que você precisa de um pooler na frente do servidor, e não de um número maior.

A solicitação de monitoramento da etapa 5, diretamente utilizável:

SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state
ORDER BY count(*) DESC;

Três sinais retornam sistematicamente quando max_connections por si só não é mais suficiente, qualquer que seja o seu valor.

1. O erro FATAL: sorry, too many clients already aparece durante o pico de carga, enquanto a maioria das conexões exibidas por pg_stat_activity estão no estado inativo.
2. O aplicativo é executado em um ambiente sem servidor ou com trabalhadores efêmeros (funções de borda, trabalhos curtos), que abrem e fecham conexões muito mais rápido do que o modelo de processo por conexão do Postgres foi projetado para acomodar.
3. A fórmula e o procedimento acima já foram aplicados, e a necessidade real de conexões de clientes continua excedendo a memória disponível que pode ser alocada sem colocar em risco work_mem ou shared_buffers.

Nestes três casos, a resposta correta é quase sempre um pooler posicionado entre a aplicação e o Postgres, e não um max_connections mais alto. Nossa comparação PgBouncer, Supavisor e PgCat detalha as três opções, e nosso guia para modo de transação explica o comprometimento mais comum quando o pooler estiver instalado. Para todos os ajustes do Postgres além das conexões, consulte nossa lista de verificação de ajuste do Postgres de produção.