Pooling de conexiones de Postgres con PgBouncer — los patrones que usamos en producción

Las conexiones de Postgres son caras. Un solo backend de Postgres ocioso usa 5-15 MB de memoria y mantiene recursos del SO que no se liberan hasta que la conexión se cierra. La mayoría de los frameworks de aplicación abren docenas de conexiones por instancia, multiplique por replicas, multiplique por entornos — y rápidamente tendrá 500-2000 conexiones a una BBDD que rinde mejor en quizás 100.

Para esto está PgBouncer. Lo desplegamos para casi cada cliente Postgres gestionado, y sigue siendo la pieza de herramientas de ops Postgres con mayor apalancamiento.

Una 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 defecto, transaction pooling. Use session pooling solo para el subconjunto específico de cargas que necesitan LISTEN/NOTIFY, advisory locks o tablas temp — idealmente en un puerto separado.

El artículo completo cubre:

• Session vs transaction vs statement pooling — cuándo cada uno está bien
• Dimensionar default_pool_size contra el max_connections real de Postgres
• Leer SHOW POOLS; durante la carga pico para ajustar
• Soporte nativo de prepared statements en PgBouncer 1.21+ (y retirar el workaround del cliente)
• Un PgBouncer por host de app vs clúster centralizado — los trade-offs
• auth_query para que las credenciales nunca salgan de Postgres

Lo entregamos en cada despliegue Postgres gestionado.