Introducción
Cuando Odoo crece—más usuarios, más compañías, más integraciones—PostgreSQL empieza a sentir la presión: ráfagas de conexiones, sesiones “idle in transaction”, bloqueos y latencias impredecibles. Subir max_connections rara vez ayuda; suele incrementar el consumo de memoria y el context switching del servidor, sin resolver el fondo del problema: gestionar la concurrencia.
Aquí entra PgBouncer, un connection pooler ligero que se coloca entre las aplicaciones (Odoo, integraciones, BI) y la base de datos. En vez de abrir miles de conexiones reales, PgBouncer las reutiliza y suaviza los picos, manteniendo la base estable en momentos críticos (cierres, campañas, procesos masivos). En este artículo verás qué es, cómo funciona, las configuraciones clave, y un checklist de despliegue para aplicarlo con seguridad en tu entorno
¿Qué es PgBouncer?
PgBouncer es un pooler de conexiones para PostgreSQL. Tus apps se conectan a PgBouncer (por convención, puerto 6432); PgBouncer mantiene y reutiliza un número reducido de conexiones reales hacia Postgres. El resultado es menos overhead por apertura/cierre de conexiones y concurrencia controlada.
Por qué Odoo lo necesita
- Picos (cierre contable, campañas, masivos, ETLs) → ráfagas de conexiones.
- Sesiones colgadas (idle in transaction) → bloqueos y autovacuum ineficiente.
- Latencias erráticas → equipos frustrados y SLAs incumplidos.
- Infra sobredimensionada solo para momentos críticos → costo alto.
Con PgBouncer estabilizas conexiones y priorizas el trabajo útil.
Cómo funciona
- Pooling: en lugar de miles de sockets directos, las apps hablan con PgBouncer; este reutiliza conexiones al backend.
-
Modos:
- session (por defecto, seguro): una conexión de servidor por sesión de cliente.
- transaction (más eficiente): devuelve la conexión al terminar cada transacción.
- statement (agresivo): no permite transacciones multi-sentencia.
Elige session para empezar en Odoo; evalúa transaction si tu stack no depende de estado de sesión/prepared statements.
Resultados típicos
- Max connections bajo control.
- Menos “idle in transaction” y menos bloqueos.
- Latencia más predecible en horas pico.
(Los porcentajes exactos dependen de carga, versión de Odoo y personalizaciones.)