Connection pooling database: pool ou nova conexão?

Toda aplicação que conversa com um banco de dados chega a um ponto em que precisa escolher: manter um conjunto de conexões abertas e reaproveitá-las (connection pooling database) ou abrir uma conexão nova a cada requisição? A resposta curta é que o pool é a estratégia padrão para quase todo sistema web. Mas essa escolha não é binária, e o contexto muda o veredito. Vamos comparar os dois caminhos em cinco critérios que importam para a decisão, não para o glossário.

Custo de recursos: o que cada abordagem consome

Abrir uma conexão nova envolve handshake TCP, autenticação, negociação TLS e alocação de memória no servidor. Esse custo se repete a cada requisição e cresce com o volume. Um pool mantém um número fixo de conexões ativas, reutilizando-as. O ganho aparece justamente em cargas com muitas requisições curtas.

No caso de um sistema com 200 requisições por segundo, abrir e fechar conexões a cada operação multiplica o trabalho de CPU e rede. Com pool, esse custo é diluído. A ressalva: se o pool for grande demais, o banco gasta memória mantendo conexões ociosas. O tamanho ideal depende do banco e da concorrência real, não de um número mágico.

Latência: quanto tempo o usuário espera

Latência é o critério que o usuário sente. Conexões novas adicionam o tempo de handshake e autenticação a cada operação. Em redes com latência de 20 ms entre aplicação e banco, esse acréscimo é perceptível. O pool elimina essa etapa na maioria das requisições, porque a conexão já está pronta.

Em contrapartida, se o pool estiver saturado, a requisição espera na fila até uma conexão liberar. Ou seja, o pool troca latência de estabelecimento por latência de espera. O ponto de equilíbrio está em dimensionar o pool para a concorrência média, com uma fila que não estoure em picos.

Escalabilidade: como cada estratégia se comporta sob carga

Sob carga crescente, abrir conexões novas escala mal porque cada requisição compete por recursos do banco. O pool limita o número de conexões simultâneas, protegendo o banco de sobrecarga. Isso é especialmente importante em arquiteturas com muitos servidores de aplicação.

Um detalhe prático: se você tem 10 instâncias da aplicação e cada uma abre 20 conexões, são 200 conexões no banco. Sem pool, esse número pode ser muito maior e derrubar o servidor. O pool impõe um teto previsível.

Complexidade de implementação e manutenção

Abrir conexão nova é simples de codificar, mas gerenciar o ciclo de vida (fechar corretamente, tratar erros, evitar vazamentos) fica trabalhoso. O pool adiciona uma camada de configuração: tamanho mínimo e máximo, timeout, validação de conexão. Essa complexidade inicial compensa em qualquer sistema com mais de algumas dezenas de requisições por segundo.

A ressalva é que um pool mal configurado é pior que não ter pool. Timeout muito alto faz requisições travarem; pool pequeno demais gera filas; pool grande demais estoura o banco. Não existe configuração universal.

Quando abrir novas conexões ainda faz sentido

Há cenários em que abrir conexão nova é aceitável: scripts de migração, jobs em lote que rodam uma vez por dia, ou ambientes de desenvolvimento com baixo volume. Nesses casos, o custo de estabelecer conexão é irrelevante frente ao tempo total da operação.

Também faz sentido quando a aplicação é serverless e o provedor já oferece um proxy de pool gerenciado. Aí a decisão não é entre pool e conexão nova, mas entre pool próprio e pool gerenciado.

Tabela comparativa

| Critério | Connection pooling | Nova conexão a cada requisição | | --- | --- | --- | | Custo de recursos | Baixo após aquecimento | Alto e repetido | | Latência | Baixa, com risco de fila | Alta pelo handshake | | Escalabilidade | Limitada pelo tamanho do pool | Degrada rápido sob carga | | Complexidade | Configuração inicial maior | Código simples, manutenção difícil | | Melhor para | Aplicações web com muitas requisições curtas | Jobs em lote, scripts, baixo volume |

Veredito: qual escolher

Para quem busca performance previsível e escala em aplicação web, a escolha é connection pooling. Para quem roda scripts esporádicos ou tem volume baixo, abrir conexão nova é suficiente e mais simples. O critério decisivo é a frequência e a concorrência das operações, não a preferência técnica.

Antes de configurar, meça: quantas requisições por segundo sua aplicação faz? Qual a latência aceitável? Qual o limite de conexões do banco? Essas respostas definem o tamanho do pool. Dado sem decisão é só enfeite.

FAQ

O que é connection pooling database?

É uma técnica que mantém um conjunto de conexões abertas e as reutiliza para várias requisições, em vez de abrir e fechar uma conexão a cada operação. Isso reduz latência e consumo de recursos no banco e na aplicação.

Quando devo usar connection pooling?

Use quando sua aplicação faz muitas requisições curtas ao banco, especialmente em ambiente web com múltiplos usuários simultâneos. Se o volume é baixo ou as operações são esporádicas, abrir conexão nova pode ser suficiente.

Qual o tamanho ideal de um pool de conexões?

Não há número universal. O tamanho depende da concorrência real, do limite do banco e da latência aceitável. Comece com um valor conservador, monitore filas e ajuste com base em métricas de uso.

Connection pooling funciona com serverless?

Sim, mas requer cuidado. Em serverless, cada instância pode abrir conexões próprias. Provedores oferecem proxies de pool gerenciado para evitar esgotamento do banco. Avalie o custo e a compatibilidade antes de adotar.

O que acontece se o pool ficar saturado?

As requisições esperam na fila até uma conexão liberar. Se a fila cresce muito, a latência sobe e pode haver timeout. Por isso, dimensionar o pool e definir timeouts adequados é essencial.

Abrir conexão nova é sempre pior?

Não. Em scripts de migração, jobs em lote ou ambientes de desenvolvimento, o custo de estabelecer conexão é irrelevante. Nesses casos, a simplicidade de abrir conexão nova pode ser vantajosa.