Connection pooling do Postgres com PgBouncer — os padrões que rodamos em produção

Conexões Postgres são caras. Um único backend Postgres ocioso usa 5-15 MB de memória e segura recursos do SO que não são liberados até a conexão fechar. A maioria dos frameworks de aplicação abre dezenas de conexões por instância, multiplique por réplicas, multiplique por ambientes — e rapidamente você tem 500-2000 conexões para uma DB que rende melhor em talvez 100.

É para isso que o PgBouncer existe. Implantamos em quase todo cliente Postgres gerenciado, e segue sendo a peça de tooling de ops Postgres com maior alavancagem.

Uma config base de transaction pooling

[databases]
app = host=db.internal port=5432 dbname=app
 
[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = scram-sha-256
pool_mode = transaction
max_client_conn = 5000
default_pool_size = 25
server_lifetime = 3600
server_reset_query = DISCARD ALL
max_prepared_statements = 100

Por padrão, transaction pooling. Use session pooling apenas para o subconjunto específico de cargas que precisam de LISTEN/NOTIFY, advisory locks ou tabelas temp — idealmente em uma porta separada.

O artigo completo cobre:

• Session vs transaction vs statement pooling — quando cada um está certo
• Dimensionar default_pool_size contra o max_connections real do Postgres
• Ler SHOW POOLS; durante a carga de pico para ajustar
• Suporte nativo a prepared statements no PgBouncer 1.21+ (e remover o workaround do lado cliente)
• Um PgBouncer por host de app vs cluster centralizado — os trade-offs
• auth_query para que credenciais nunca saiam do Postgres

Entregamos isso em cada deploy Postgres gerenciado.