🧠 Por qué este capítulo es clave
Muchos problemas de rendimiento en Odoo no se entienden hasta que comprendes una cosa:
Odoo no reutiliza conexiones a PostgreSQL como la mayoría de las aplicaciones web modernas.
Y eso tiene consecuencias directas en:
consumo de memoria
escalabilidad
latencia
estabilidad del sistema
🔌 El modelo de conexión de Odoo (simplificado)
Odoo funciona con:
un servidor Python
múltiples workers
un ORM que interactúa con PostgreSQL
Cada worker:
mantiene su propia conexión a PostgreSQL
abre transacciones frecuentemente
retiene la conexión mientras dura la transacción
👉 No hay pooling interno real.
⚙️ Workers de Odoo y conexiones
Regla básica:
1 worker = 1 conexión activa a PostgreSQL (como mínimo)
Ejemplo típico:
workers = 12
Resultado:
12 conexiones base
más conexiones para cron jobs
más conexiones para longpolling
más conexiones en picos de carga
Con facilidad terminas con:
30, 50 o más conexiones activas
incluso con pocos usuarios concurrentes
🔄 Qué pasa durante una request
Cuando un usuario hace una acción en Odoo:
El request llega a un worker
El ORM inicia una transacción
Se ejecutan múltiples queries
La conexión queda ocupada
La transacción se cierra (a veces tarde)
Mientras tanto:
esa conexión no puede ser usada por otro request
PostgreSQL mantiene recursos reservados
🧨 El problema de las transacciones largas
Odoo tiene muchas operaciones que generan:
transacciones largas
múltiples queries encadenadas
locks implícitos
Ejemplos:
validación de facturas
movimientos de inventario
recalculo de stock
reportes complejos
👉 Una transacción larga = conexión bloqueada más tiempo.
❌ Por qué PostgreSQL sufre con este modelo
PostgreSQL:
crea un proceso por conexión
asigna memoria por conexión
no escala bien con cientos de conexiones
Cuando Odoo abre muchas conexiones:
aumenta el uso de RAM
aumenta el context switching
baja el rendimiento global
Resultado típico:
PostgreSQL lento con CPU baja y RAM alta.
📉 El efecto dominó en producción
Sin control de conexiones:
los workers empiezan a esperar
los usuarios perciben latencia
aparecen timeouts
los admins reinician servicios
el problema vuelve
👉 Reiniciar Odoo solo libera conexiones, no soluciona la causa.
🔍 Cómo ver el problema en vivo
En PostgreSQL puedes verlo así:
SELECT count(*) FROM pg_stat_activity;
O más detallado:
SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state;
Suele aparecer:
muchas conexiones idle
varias idle in transaction
Eso es Odoo reteniendo conexiones.
🧩 Por qué Odoo no puede “arreglar esto solo”
El ORM de Odoo:
no está diseñado para pooling externo
asume conexión directa
depende del ciclo de vida del worker
Por eso:
subir workers empeora el problema
subir max_connections lo agrava
más hardware solo retrasa el colapso
🚀 La solución correcta: desacoplar conexiones
Lo que Odoo necesita es:
abrir muchas conexiones lógicas
pero mantener pocas conexiones reales a PostgreSQL
Eso no se puede hacer dentro de Odoo.
👉 Se hace con un connection pooler.
🔗 Aquí entra PgBouncer
PgBouncer:
se coloca entre Odoo y PostgreSQL
recibe miles de conexiones de Odoo
mantiene pocas conexiones reales
reutiliza conexiones eficientemente
👉 En el siguiente capítulo lo vemos en detalle:
Qué es PgBouncer y cómo funciona
🔗 Enlaces relacionados
📌 Conclusión
Odoo no es lento por diseño.
Es exigente con PostgreSQL.
Si no entiendes cómo gestiona las conexiones:
optimizarás mal
escalarás mal
reiniciarás demasiado
La solución no es tocar Odoo.
Es poner la pieza que falta en la arquitectura.
Siguiente capítulo ->