Por que você precisa de connection pooling (PgBouncer)?

Question

Accepted Answer

**Connection pooling** reutiliza um pequeno conjunto de conexões de banco de dados em muitas requisições de clientes, em vez de abrir uma nova conexão por requisição. Conexões PostgreSQL são **caras** (cada uma é um processo separado usando memória significativa), então o pooling é essencial para performance e escalabilidade sob carga. **PgBouncer** é o pooler padrão.

## O problema: conexões PostgreSQL são caras

```text
Each PostgreSQL connection = a separate OS PROCESS, using ~5-10MB of memory.
  ✗ Opening a connection has overhead (process creation, auth, setup)
  ✗ Many connections (e.g. 1000s from a busy app) → huge memory use, contention
  ✗ Postgres has a max_connections limit (often ~100); exceeding it = errors
→ Opening/closing a connection per request, or holding thousands open, doesn't scale.
```

## A solução: um connection pool

```text
A POOL maintains a small set of REUSABLE connections to Postgres.
Application requests BORROW a connection from the pool, use it, and RETURN it.
  ✓ Connections are reused (no per-request open/close overhead)
  ✓ Many app requests share a few DB connections (e.g. 10000 clients → 20 connections)
  ✓ Stays within max_connections, controls resource use → scales
```

## PgBouncer — o pooler externo padrão

```text
PgBouncer sits BETWEEN the application and PostgreSQL — lightweight, efficient.
Pooling modes:
  Session   → a connection is assigned for the client's whole session
  Transaction → a connection is held only for the duration of a TRANSACTION (most
               efficient — connections returned between transactions; common choice)
  Statement → per-statement (most aggressive; limited)
→ Transaction pooling maximizes connection reuse for typical web apps.
```

## Onde o pooling acontece

```text
Application-level → many ORM/driver libraries have built-in pools (per app instance)
External pooler (PgBouncer) → a shared pool in front of Postgres (best for many app
  instances / serverless, where per-instance pools would still overwhelm the DB)
→ Serverless especially needs an external pooler (many short-lived instances).
```

## Por que isso importa

Connection pooling é conhecimento essencial para rodar PostgreSQL **em escala**, porque conexões PostgreSQL são excepcionalmente caras (cada uma é um processo separado do SO usando memória significativa), então entender por que o pooling é necessário e como funciona é conhecimento importante de nível sênior para deployments performáticos e escaláveis.

O problema central é que a abordagem ingênua — abrir uma conexão por requisição, ou manter milhares de conexões abertas a partir de uma aplicação movimentada — não escala com Postgres: conexões são custosas (memória por processo, overhead de criação), e Postgres tem um limite `max_connections` (geralmente ~100) que é facilmente excedido, causando erros e esgotamento de recursos. **Connection pooling** resolve isso mantendo um pequeno conjunto de conexões reutilizáveis que muitas requisições da aplicação compartilham (emprestando e devolvendo) — então milhares de clientes podem ser servidos por algumas dezenas de conexões de banco de dados, eliminando o overhead por requisição e respeitando os limites.

Entender **PgBouncer** (o pooler externo padrão) e seus **modos de pooling** — especialmente **transaction pooling** (manter uma conexão apenas durante a duração de uma transação, maximizando reutilização, a escolha comum para web apps) — é conhecimento prático importante.

Saber **onde o pooling acontece** (pools em nível de aplicação por instância, versus um pooler externo como PgBouncer para muitas instâncias ou serverless) é um ponto arquitetural chave — **serverless especialmente precisa de um pooler externo** porque muitas instâncias de curta duração sobrecarregariam Postgres com conexões (um problema comum e real).

Porque gerenciamento de conexão afeta diretamente escalabilidade e estabilidade sob carga (e o modelo processo-por-conexão do Postgres torna isso crítico), e porque pooling (especialmente PgBouncer com transaction pooling) é a solução padrão e essencial, entender connection pooling — por que Postgres precisa, como funciona, PgBouncer e seus modos, e a consideração serverless — é conhecimento importante de nível sênior para operar PostgreSQL em escala, uma preocupação frequentemente crítica para sistemas em produção que distingue aqueles que conseguem escalar Postgres daqueles que falham com erros de limite de conexão.