PgBouncer, Pgpool-II y otros: Intermediario para PostgreSQL 🐘

Un proxy o pooler de conexiones de PostgreSQL es una aplicación intermedia que se sitúa entre tus aplicaciones cliente y uno o varios servidores PostgreSQL. Usa el protocolo de red de PostgreSQL, lo que permite a cualquier cliente estándar (por ejemplo, tu servidor web o una aplicación en Java/Python/Go) conectarse al intermediario pensando que se comunica directamente con el servidor PostgreSQL.

A diferencia de MySQL, donde los proxies a menudo se usan para dividir lecturas/escrituras (R/W split) o para caching, en el mundo de PostgreSQL la tarea principal del intermediario es la gestión eficiente de las conexiones.

Problema: “Process per Connection” en PostgreSQL

PostgreSQL históricamente utiliza el modelo process per connection, donde por cada nueva conexión cliente se crea un proceso postgres. Es un modelo fiable, pero costoso en recursos: cada proceso consume aproximadamente 10–20 MB de RAM, además del overhead de fork/exec.

Si tu aplicación abre cientos o miles de conexiones cortas (por ejemplo, microservicios, FaaS, aplicaciones web), el servidor de BD se satura: aumenta la carga de CPU por fork, se agota la memoria y las conexiones se “atascan”.

La solución es connection pooling. Precisamente para eso sirven PgBouncer, Pgpool-II, Odyssey y sus análogos.

Cómo funciona el intermediario para PostgreSQL

En una configuración básica el pooler simplemente reenvía las solicitudes del cliente al servidor PostgreSQL. Pero su función clave es el multiplexado de conexiones:

1. Recepción — la aplicación cliente se conecta al pooler (por ejemplo, PgBouncer).

2. Espera — el pooler mantiene un pool de conexiones reales al servidor PostgreSQL (ya autenticadas).

3. Enrutamiento — cuando el cliente hace una petición:

   • el pooler toma una conexión libre del pool;
   • ejecuta la transacción del cliente;
   • devuelve la conexión al pool, reseteando el estado.

4. Respuesta — el resultado se devuelve al cliente.

En resumen: miles de “ligeras” conexiones cliente son atendidas por decenas de conexiones “pesadas” hacia la base. El ahorro de recursos puede ser de decenas de veces.

Funciones y responsabilidades principales

Algunos proxies también soportan cache de queries, recolección de métricas y exportadores para Prometheus.

Tipos de intermediarios para PostgreSQL

1. Poolers ligeros de conexiones (Capa 7, no SQL-aware)

Entienden el protocolo PostgreSQL, pero no analizan las consultas SQL. El objetivo principal es el multiplexado rápido con latencia mínima (<1 ms).

Modos de pooling:

• Session — la conexión se mantiene hasta el desconecto (conveniente, pero no ahorra recursos).
• Transaction — la conexión se asigna durante la transacción (BEGIN…COMMIT). Balance óptimo.
• Statement — la conexión se asigna para una sola consulta (ahorro máximo, pero con restricciones estrictas).

2. Proxies SQL-aware (entienden SQL)

Analizan el tráfico SQL, lo que permite hacer R/W split, caché y análisis de consultas.

3. Proxies TCP/Capa 4 (no entienden el protocolo)

Ejemplos de configuraciones

PgBouncer (pooling por transacción)

[databases]
my_app_db = host=127.0.0.1 port=5432 dbname=real_db_name

[pgbouncer]
listen_port = 6432
listen_addr = *
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = transaction  ; Modo recomendado
max_client_conn = 2000
default_pool_size = 20   ; Ajuste según RAM/CPU (~10–50 por núcleo)
reserve_pool_size = 5

Pgpool-II (R/W split y HA)

listen_addresses = '*'
port = 9999

enable_pooling = on
num_init_children = 32
max_pool = 4

backend_hostname0 = 'primary_host'
backend_port0 = 5432
backend_weight0 = 1.0

backend_hostname1 = 'replica_host'
backend_port1 = 5432
backend_weight1 = 1.0

load_balance_mode = on
primary_node_id = 0
watchdog_enable = on

Odyssey (multihilo, config YAML)

daemonize: false
pid_file_path: /tmp/odyssey.pid

listeners:
  - host: 0.0.0.0
    port: 6432
    database: my_app_db
    users:
      - name: app_user
        password: secret
        pool_size: 20
        pool_mode: transaction

storage:
  - name: postgres
    type: remote
    hosts:
      - host: 127.0.0.1
        port: 5432

Cómo elegir la herramienta

Mejores prácticas

• Monitorización: usa SHOW STATS; (PgBouncer) o exportadores para Prometheus.
• Tamaño del pool: default_pool_size = (RAM / 20MB) / databases, pero no más de 100–200 por servidor.
• Seguridad: habilita sslmode=require y termina TLS en el pooler.
• Carga: prueba con pgbench, buscando latencias <5 ms.
• Kubernetes: despliega PgBouncer como sidecar, HAProxy como DaemonSet.

Conclusión

En el ecosistema PostgreSQL, un pooler de conexiones es no una opción, sino una necesidad para cualquier sistema de alta carga (100+ RPS).

• Empieza con PgBouncer — resuelve el 90% de los problemas de conexiones.
• Usa Pgpool-II si necesitas R/W split integrado y cache de queries.
• Emplea Odyssey o PgCat para setups modernos y a gran escala.
• Añade HAProxy + Patroni si requieres alta disponibilidad y replicación a nivel TCP.

Con el intermediario correcto, tu PostgreSQL aguantará miles de clientes y seguirá tranquilo como un elefante 🐘.