La diferencia entre “funciona” y “escala”
Cuando Odoo se conecta directo a PostgreSQL puede ir bien… hasta que llega la carga real.
PgBouncer no es un “turbo”: es el componente que evita que PostgreSQL se ahogue por exceso de conexiones y hace que el rendimiento sea predecible.
🧱 Conexiones directas (Odoo → PostgreSQL)
Cuando Odoo conecta directo:
cada worker mantiene su conexión (y bajo carga retiene conexiones más tiempo)
los picos de usuarios y crons se traducen en picos de conexiones reales
PostgreSQL crea un proceso por conexión y reserva memoria por conexión
se incrementa el overhead: scheduling, context switching, memoria, contención
Qué se ve en producción
Odoo rápido a ratos, lento a ratos
CPU relativamente baja pero sistema “pesado”
RAM alta en PostgreSQL con muchas conexiones idle
timeouts intermitentes
reiniciar “mejora” (porque limpia conexiones), pero el problema vuelve
👉 Si esto te suena, no es tu imaginación: es el patrón clásico sin pooling.
🔄 Con PgBouncer (Odoo → PgBouncer → PostgreSQL)
Con PgBouncer:
Odoo puede abrir muchas conexiones lógicas
PgBouncer limita y reutiliza conexiones reales hacia PostgreSQL
PostgreSQL ve un número estable de conexiones, no picos
la RAM se estabiliza y disminuye el caos interno del motor
Qué cambia de verdad
menos latencia intermitente
menos “micro-caídas” y menos timeouts
PostgreSQL deja de inflarse por conexiones
el sistema se vuelve predecible bajo picos
🧠 La diferencia clave (en una frase)
Sin pooler: conexiones = carga
Con pooler: conexiones = control
En Odoo, ese control vale más que “optimizar una query”.
🧪 Ejemplo típico (simplificado)
Sin PgBouncer:
12 workers + crons + usuarios
40–120 conexiones reales en picos
PostgreSQL gasta RAM y overhead en gestionar procesos
Con PgBouncer:
Odoo mantiene conexiones lógicas
PgBouncer sostiene, por ejemplo, 20–40 conexiones reales estables
PostgreSQL trabaja mejor con menos procesos y menos contención
👉 Mismo Odoo, mismo servidor: comportamiento totalmente distinto.
⚠️ Importante: PgBouncer no arregla todo
PgBouncer no:
acelera queries lentas por falta de índices
arregla locks causados por transacciones largas
corrige módulos pesados o reportes mal diseñados
Pero sí evita que el sistema colapse por el patrón más común de Odoo en producción: demasiadas conexiones reales.
✅ Cuándo PgBouncer es “obligatorio”
más de ~20 usuarios concurrentes reales
crons pesados en horario laboral
varios Odoo/instancias contra la misma base
picos de uso impredecibles (ventas, inventario, cierres)
PostgreSQL con RAM alta y muchas conexiones idle
..