Odoo 19 Framework & Enterprise Performance Benchmark
As enterprise workloads scale, ERP performance is no longer just about raw server specs—it relies heavily on database query isolation, asynchronous request handling, and virtual DOM patch latencies. In this R&D benchmark, Gradiant Infotech's engineering team subjected Odoo 19 Enterprise to rigorous load testing under 10,000 concurrent user requests, multi-warehouse stock allocations, and PostgreSQL 17 query planner optimizations.
R&D Test Objective
Evaluate transaction throughput, memory footprint, and SQL query lock contention across Odoo 17, 18, and 19 under peak enterprise workloads.
1. Benchmark Test Infrastructure & Server Topology
To eliminate bottleneck noise, testing was executed on isolated bare-metal instances within an enterprise cloud environment running Ubuntu 24.04 LTS.
| Component | Specification | Configuration / Tuning Parameters |
|---|---|---|
| Application Nodes | 2x AMD EPYC 9654 (192 Cores, 384 Threads) | workers = 16, limit_memory_soft = 4294967296, limit_memory_hard = 8589934592 |
| Database Server | PostgreSQL 17.2 on NVMe Gen5 RAID 10 | max_connections = 400, shared_buffers = 64GB, effective_cache_size = 192GB |
| Cache / Session Store | Redis 7.2 Cluster (In-Memory) | maxmemory-policy = allkeys-lru, Unix Socket binding |
| Load Generator | Locust 2.25 & k6 Distributed Swarm | 1,000 to 10,000 virtual users ramping over 15 minutes |
2. Concurrency & Throughput Benchmark Results
We simulated real-world enterprise operations: simultaneous web store orders, warehouse barcode scans, accounting journal postings, and CRM updates.
| Concurrent Users | Metric | Odoo 17 Enterprise | Odoo 18 Enterprise | Odoo 19 Enterprise (R&D Test) | Performance Gain |
|---|---|---|---|---|---|
| 1,000 Users | Throughput (Req/Sec) | 1,840 req/s | 2,150 req/s | 2,920 req/s | +35.8% |
| P95 Latency (ms) | 142 ms | 110 ms | 68 ms | -38.1% | |
| Error Rate (%) | 0.00% | 0.00% | 0.00% | Nominal | |
| 5,000 Users | Throughput (Req/Sec) | 4,210 req/s | 5,400 req/s | 7,850 req/s | +45.3% |
| P95 Latency (ms) | 385 ms | 270 ms | 145 ms | -46.2% | |
| Error Rate (%) | 0.12% | 0.04% | 0.00% | Zero Errors | |
| 10,000 Users | Throughput (Req/Sec) | 6,100 req/s (Throttled) | 7,890 req/s | 11,420 req/s | +44.7% |
| P95 Latency (ms) | 940 ms | 610 ms | 290 ms | -52.4% | |
| Error Rate (%) | 1.85% | 0.42% | 0.01% | Stable |
3. OWL 2 Reactive Store & DOM Patching Latency
Odoo 19 introduces a streamlined reactive store in the OWL 2 framework. By utilizing fine-grained signal subscriptions instead of full component tree re-evaluations, list and kanban views render significantly faster.
List View (10,000 Rows Scroll)
Initial mount & virtual scroll patch latency:
Form View Field Re-evaluations
Onchange trigger execution latency:
4. PostgreSQL 17 Query Lock Elimination & Index Selectivity
High-volume sales order processing often causes database row locks on stock.quant and account.move.line. Odoo 19 leverages PostgreSQL 17's FOR UPDATE SKIP LOCKED and batch sequence reservations to eliminate lock wait times during peak checkout events.
SELECT id, quantity, reserved_quantity
FROM stock_quant
WHERE product_id = 94021 AND location_id = 14
FOR UPDATE SKIP LOCKED;
/* Execution Time: 0.8ms vs 42.5ms under 500 concurrent threads */
Engineering Summary & Recommendations
- Upgrade to PostgreSQL 17: Query planner enhancements reduce memory sorting overhead by 30% for financial ledger queries.
- Tune Worker Limits: Set
workers = (CPU cores * 2) + 1and allocate at least 4GB RAM per worker process for heavy reporting tasks. - Leverage OWL 2 Signals: Custom web client views should replace legacy store subscriptions with OWL 2 reactive signals to maintain sub-5ms DOM render times.