Project Name
71% PostgreSQL Connection Reduction on Odoo Servers with PgBouncer
The client is a mid-size technology organisation operating multiple Odoo ERP instances to manage internal business processes across departments. Headquartered in India, the organisation runs a containerised Odoo deployment using Docker, with each service stack maintaining its own database connections to a shared PostgreSQL cluster. As the number of concurrent users and automated workflows grew, the database layer became the primary performance constraint, with connection counts regularly exceeding safe operational thresholds. The engagement was initiated to resolve production-grade database latency without requiring application-level refactoring.
- Connection Exhaustion Under Normal Load: Internal Odoo servers sustained 500 to 800+ active PostgreSQL connections across Docker containers during standard business hours, regularly approaching the database's maximum connection limit.
- Page-Load Latency Tied to Connection Queuing: End users experienced significant page-load delays as new connection requests queued behind long-running or idle transactions that continued to hold open connections.
- No Connection Reuse Across Containers: Each Docker container opened and maintained its own dedicated connections to PostgreSQL with no shared pooling layer, resulting in significant connection sprawl even at moderate concurrency.
- Idle Connection Accumulation: Connections opened by background jobs, cron tasks, and inactive browser sessions persisted long after their transactions completed, consuming database slots without performing any useful work.
- Risk of Cascading Failures: When connection limits were reached, new requests were rejected outright, causing application errors visible to end users and triggering cascading retry storms that worsened the overload.
- No Application-Code Change Window: The team required a solution deployable at the infrastructure layer without modifying Odoo's ORM, connection-handling logic, or application configuration, ruling out any code-level intervention.
Ksolves deployed a transparent PgBouncer connection-pooling layer between the Odoo application containers and the PostgreSQL database. The governing principle was zero application change; the pooler intercepts, multiplexes, and recycles connections at the infrastructure level, invisible to Odoo's ORM and application logic, within the existing Docker architecture.
- PgBouncer Transaction Pooling: PgBouncer was deployed in transaction-pooling mode as a lightweight proxy between all Odoo Docker containers and the PostgreSQL server. Each connection is returned to the pool immediately after a transaction completes, eliminating idle hold and freeing database slots in real time.
- Connection Multiplexing Across Containers: A shared pool was configured through which all Docker containers connect, collapsing hundreds of per-container connections into a controlled set of reusable backend connections to PostgreSQL.
- Idle Connection Eviction: PgBouncer's server_idle_timeout and server_lifetime parameters were tuned to aggressively reclaim connections held by inactive sessions, cron jobs, and background workers, maintaining a stable connection footprint at all times.
- Containerised Deployment: PgBouncer was packaged as a Docker container within the existing stack, ensuring that deployment, scaling, and monitoring remain consistent with the current infrastructure-as-code workflow.
- Transparent Proxy Configuration: Odoo's database connection strings were reconfigured to point to the PgBouncer endpoint instead of PostgreSQL directly, requiring no changes to Odoo application code, ORM, or configuration files.
Technology Stack
| Category | Technology |
|---|---|
| Database | PostgreSQL |
| Infrastructure | PgBouncer |
| Platform | Odoo |
| Infrastructure | Docker |
| Methodology | Transaction Pooling |
- 71% Reduction in Active PostgreSQL Connections: PgBouncer transaction pooling brought active backend connections down from 500 to 800+ to approximately 230, freeing over 500 database connection slots during peak business hours.
- Page-Load Latency Eliminated: Connection pooling absorbed burst demand that previously caused queuing and database contention, returning page-load response times to sub-second levels across the production environment.
- Zero Application-Code Changes Required: PgBouncer was deployed as a transparent infrastructure-layer proxy, delivering the full performance improvement without any modifications to Odoo's ORM, application code, or configuration files.
- Idle Connection Accumulation Eliminated: PgBouncer's timeout and eviction policies now reclaim connections held by background jobs, cron tasks, and inactive sessions in real time, maintaining a stable and predictable connection footprint continuously.
- Cascading Failure Risk Neutralised: Pooled connection management absorbs burst traffic within a fixed backend pool, eliminating the connection-limit breaches that previously triggered user-facing errors and retry storms
Before the engagement, internal Odoo servers were sustaining 500 to 800+ active PostgreSQL connections, causing database contention, page-load latency, and ongoing production instability for end users. PgBouncer transaction pooling brought active backend connections down to approximately 230, a 71% reduction, delivered with zero application-code changes and no deployment downtime. The optimisation freed over 500 database connection slots, eliminating query queuing and restoring sub-second page-load performance across the production environment. Deploying the solution at the infrastructure layer preserved application stability and avoided a multi-sprint code refactoring effort, substantially reducing both delivery time and operational risk. With connection pooling in place, the platform can now scale additional Odoo containers and support greater user concurrency without revisiting database connection limits or requiring further infrastructure changes.
Is Your Odoo Deployment Running Out of Database Connections Before It Runs Out of Users?
