# Connection pooling database: pool ou nova conexão?

> Connection pooling database é a prática de reutilizar conexões abertas com o banco de dados em vez de criar uma nova conexão a cada requisição. O pool reduz latência e custo de handshake, melhora escalabilidade sob alta concorrência e exige configuração de tamanho, timeout e validação, sendo indicado para aplicações com tráfego frequente.

*PosUp · Apps e Software · 16 de setembro de 2026 · Patrícia Lemos*

Toda aplicação que fala com banco de dados enfrenta a mesma escolha: reutilizar conexões com connection pooling ou abrir uma nova a cada requisição. Comparamos os dois caminhos em custo, latência, escalabilidade e complexidade para você decidir com base no seu contexto.

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.

---

Fonte (canonical): https://posup.com.br/apps-e-software/connection-pooling-database-pool-ou-nova-conexao/