El punto que define si PgBouncer te salva o te rompe
PgBouncer puede ser la diferencia entre un Odoo estable y una pesadilla de timeouts. Pero todo empieza con una decisión que muchos pasan por alto:
pool_mode define cuándo PgBouncer devuelve una conexión real al pool.
Si eliges mal, no solo no mejoras nada: puedes empeorar el sistema.
🧠 Qué hace exactamente pool_mode
PgBouncer recibe muchas conexiones “cliente” (Odoo) y administra un número menor de conexiones “servidor” (PostgreSQL).
pool_mode define cuánto tiempo se “reserva” una conexión real de PostgreSQL para un cliente.
Si la reservas demasiado tiempo → te quedas sin pool.
Si la liberas rápido → reutilizas conexiones y PostgreSQL respira.
1) pool_mode = session
Cómo funciona
En modo session, PgBouncer asigna una conexión real a un cliente y la mantiene durante toda la sesión.
En la práctica:
Odoo abre conexión
PgBouncer asigna una conexión a PostgreSQL
esa conexión queda “ocupada” para ese cliente
aunque el cliente esté idle
Por qué suele fallar en Odoo
Odoo no se comporta como una app que abre/cierra sesiones perfectas. En producción se mezcla:
requests cortos
usuarios que dejan pestañas abiertas
longpolling (según tu stack)
crons
workers con cargas irregulares
Resultado típico con session:
el pool se “congela”
clientes empiezan a esperar conexión
aparecen timeouts intermitentes
PostgreSQL puede no estar al 100%, pero Odoo se siente muerto
Traducción: con session, PgBouncer puede convertirse en un “cuello de botella” si tus conexiones quedan retenidas.
2) pool_mode = transaction (recomendado para Odoo)
Cómo funciona
En modo transaction, PgBouncer asigna una conexión real solo mientras dura la transacción.
Cuando la transacción termina:
la conexión real vuelve al pool
otro cliente la reutiliza inmediatamente
Por qué encaja con Odoo
Odoo trabaja a base de:
transacciones frecuentes
operaciones ORM que abren/cierran transacción por request/acción
Eso hace que transaction sea el modo natural para:
maximizar reutilización
mantener pocas conexiones reales
estabilizar latencia
evitar pools secuestrados por clientes idle
✅ Recomendación base:
pool_mode = transaction
🚨 ¿Hay riesgos usando transaction?
Sí, pero son controlables.
En transaction hay una regla importante:
no debes depender de estado de sesión persistente en PostgreSQL (ciertos SET, tablas temporales, prepared statements a nivel sesión, etc.)
En Odoo estándar, lo normal es que funcione bien.
Si tienes módulos muy particulares o integraciones raras, conviene validar con pruebas.
🔥 Cómo se ve el fallo en la vida real
Cuando session está mal elegido:
los usuarios reportan lentitud “a ratos”
algunas pantallas cargan, otras mueren
reiniciar Odoo “arregla”
al rato vuelve
Cuando transaction está bien aplicado:
el sistema se vuelve predecible
la latencia baja en picos
PostgreSQL deja de inflarse en RAM
se reduce el “modo bombero”
✅ Recomendación práctica (para empezar bien)
Si estás implementando PgBouncer para Odoo y quieres estabilidad:
Usa pool_mode = transaction
Ajusta pools con números reales (capítulo siguiente)
Monitorea con SHOW POOLS; y SHOW STATS;
🔗 Enlaces internos
📌 Conclusión
Si te llevas una sola idea de este capítulo:
Para Odoo, transaction casi siempre es el modo correcto.
session suele parecer “seguro”, pero en producción es donde nacen starvation y timeouts.