O que é o pooling de conexões e por que um banco de dados fica saturado?

Publicado em 2026-10-26 por frfrand

Pooling de conexões explicado: como reutilizar conexões, limites, filas e PgBouncer.

Um pool de conexões é um conjunto reutilizável de conexões a um banco de dados. Reduz o custo de abrir e fechar sessões continuamente e permite controlar quantas conexões simultâneas o servidor recebe.

Uma forma simples de entender

Imagine uma empresa onde cada visitante precisa de uma mesa de atendimento. Construir uma mesa nova para cada pessoa seria absurdo: é melhor manter um número razoável de mesas disponíveis e atribuí-las à medida que as solicitações chegam.

Como funciona na prática?

O aplicativo ou um componente intermediário mantém conexões que podem ser reutilizadas. Ferramentas como PgBouncer para PostgreSQL oferecem diferentes modalidades de pooling. O tamanho do pool deve ser ajustado à carga e aos recursos do servidor; cem processos com vinte conexões cada um podem exceder o que o banco de dados suporta.

O que não resolve e seus limites

Um pool não torna uma consulta mal projetada mais rápida nem evita bloqueios. Se estiver cheio, as solicitações podem esperar e esgotar seus tempos limite. Além disso, certas funções vinculadas à sessão precisam de atenção especial quando se utiliza pooling por transação, porque uma solicitação pode receber uma conexão física diferente.

Como aplicá-lo e verificá-lo sem surpresas

Revise conexões ativas, tempos de espera, carga de consultas e parâmetros máximos do PostgreSQL. Não aumente o pool indefinidamente: mais conexões podem aumentar o consumo de memória e piorar o desempenho. Teste o que ocorre durante reinicializações e falhas de rede.

Como aparece no ArduMaker?

Em projetos com PostgreSQL e backends hospedados em VPS do ArduMaker, um pool bem dimensionado pode ajudar a lidar com tráfego concorrente. Sua configuração depende do número de workers e das necessidades de cada aplicação.

Por que muitas conexões pioram uma aplicação

Cada conexão ativa utiliza recursos do mecanismo, mesmo que não esteja executando uma consulta o tempo todo. Uma frota de workers que abre dezenas de conexões cada um pode esgotar o limite disponível mesmo com CPU relativamente baixa. O pool permite coordenar esse uso, mas se todas as operações bloquearem por muito tempo, ainda haverá esperas.

Um detalhe de produção

As migrações de esquema e as conexões de longa duração podem precisar de um comportamento diferente do tráfego normal. Antes de introduzir o PgBouncer, verifique a compatibilidade com transações, prepared statements e estado de sessão de acordo com seu cliente e modalidade escolhida. Teste sob concorrência real e revise os tempos de espera.

Como calcular um ponto de partida?

Conte as conexões abertas no banco de dados durante um horário habitual e um pico. Compare esse número com os processos que executam consultas, a duração das transações e os limites do servidor. Um pool muito pequeno provoca esperas; um muito grande pode esgotar a memória e aumentar a competição. Escolha uma configuração inicial mensurável e revise-a com carga real.

Para lembrar

Um pool de conexões é um conjunto reutilizável de conexões com um banco de dados. Entender quando se aplica, como falha e quais dados revisar é mais útil do que memorizar comandos soltos.

Para ampliar: PgBouncer: características y configuración.