Benchmarks de performances Odoo 19 : numéros de réglage PostgreSQL 17

Performance discussions about Odoo tend to drift into vague claims ("Odoo 19 is faster"). This article gives you typical benchmark ranges for Odoo 17 vs 19 on comparable hardware and workloads, plus the PostgreSQL 17 tuning that delivers the largest gains. We'll cover web client latency, ORM throughput, scheduler runtime, and the worker/connection-pool thresholds that determine how many users your instance can support.

The numbers below are illustrative ranges for instances from t3.medium to c6i.4xlarge; benchmark your own workload before you size production.

Key Takeaways

• List-view rendering is 40-60% faster in Odoo 19 vs 17 for typical 80-record-per-page lists
• ORM bulk operations (create(), write() on large recordsets) gained 25-40% throughput
• MRP scheduler is 3-5x faster on databases with 100+ open MOs (covered in earlier post)
• PostgreSQL 17's incremental sort and improved JSON path filters help analytics queries
• Worker process count formula: 2 * vCPU + 1 for cron, separate count for HTTP
• Connection pool sizing: keep PG max_connections at 200, use PgBouncer for >10 workers
• Filestore on local SSD beats NFS for response time but loses HA — pick based on your priority

Hardware baseline

The illustrative figures below assume:

• AWS EC2 t3.xlarge: 4 vCPU, 16 GB RAM
• Ubuntu 24.04 LTS
• PostgreSQL 17 on the same instance (production sizing — at scale, separate the DB)
• 100 GB gp3 EBS for database
• 50 GB gp3 EBS for filestore
• Ubuntu kernel default tuning + the changes documented later in this article

The Odoo 17 baseline assumes Odoo 17.0+e with PG 14 (the recommended pairing at the time of 17 release).

Web client benchmarks

Typical figures for 50 concurrent users on common workflows (open list, search, drill into form, edit, save). A Playwright script can generate the same synthetic load against your own instance.

The asset-bundle split (covered in the Odoo 19 website article) drives part of the gain. The OWL refactor of stock components handles the rest.

ORM throughput

To measure bulk operations on your own instance, time the ORM methods directly:

import time
products = self.env['product.template'].search([])  # ~5000 products
start = time.time()
for p in products:
    p.write({'description': p.description + ' [tagged]'})
elapsed = time.time() - start
# Records per second

The big create/write gains come from improved batch SQL emission in 19's ORM and PostgreSQL 17's better COPY-based ingestion.

PostgreSQL 17 tuning

PG ships with conservative defaults. For Odoo 19 on a 16 GB / 4 vCPU box, the following postgresql.conf values produce noticeably better performance:

# Memory
shared_buffers = 4GB              # 25% of RAM
effective_cache_size = 12GB       # 75% of RAM
work_mem = 32MB                   # for sort/hash
maintenance_work_mem = 1GB        # for vacuum/index
huge_pages = try

# Write-ahead log
wal_buffers = 16MB
max_wal_size = 4GB
min_wal_size = 1GB
checkpoint_completion_target = 0.9

# Query planner
random_page_cost = 1.1            # SSD; default 4.0 assumes spinning disk
effective_io_concurrency = 200    # SSD parallelism
default_statistics_target = 100

# Parallelism
max_worker_processes = 4          # = vCPU count
max_parallel_workers = 4
max_parallel_workers_per_gather = 2

# Connections
max_connections = 200

After applying:

• Restart PostgreSQL (most settings need restart)
• Run ANALYZE on the database
• Monitor with pg_stat_statements

Compared to defaults, expect a configuration like this to give roughly 25-35% faster query response on a typical mixed workload. Measure yours with pg_stat_statements before and after.

Worker process count

Odoo runs as multiple worker processes. The right count balances concurrency against memory:

• HTTP workers: handle web requests
• Cron workers: handle scheduled jobs
• Live chat / longpolling worker: separate process for long-lived connections

Formula:

• HTTP workers = (2 * vCPU) + 1 for typical mid-traffic ERP usage
• Cron workers = 1-2, more if heavy automation
• Total memory budget: each worker uses 200-500 MB depending on loaded modules

For example, on a t3.xlarge (4 vCPU, 16 GB):

• 9 HTTP workers (2 × 4 + 1)
• 2 cron workers
• 1 longpolling worker
• = ~6 GB worker memory + 4 GB shared_buffers + system overhead = comfortable

If you push HTTP workers higher than 2 × vCPU + 1, you start incurring context-switch overhead that reduces per-request throughput.

Connection pooling

Odoo opens a PostgreSQL connection per worker per database. With 9 HTTP + 2 cron workers, 1 database = 11 connections. Multi-database deployments multiply this.

For 1 database + ≤12 workers, direct connection works fine. For multi-database or >12 workers, use PgBouncer in transaction-pooling mode:

# pgbouncer.ini snippet
[databases]
* = host=127.0.0.1 port=5432

[pgbouncer]
pool_mode = transaction
max_client_conn = 200
default_pool_size = 25
reserve_pool_size = 10
server_reset_query = DISCARD ALL

Note: PgBouncer in transaction-pooling mode does NOT support Odoo's prepared-statement caching. Either disable Odoo's prepared statements or use session-pooling mode (with proportional connection scaling).

Filestore considerations

Odoo's filestore (binary attachments) lives at /var/lib/odoo/filestore/<dbname>/. Two options:

• Local SSD: lowest latency, no HA. Good for single-node deployments.
• NFS / EFS: HA-friendly, higher latency. Necessary for multi-node clusters.
• S3-backed via custom module: scalable, slowest first-byte. Use for read-heavy attachments only.

Typical read latencies:

• Local SSD attachment read: 2-5 ms
• NFS attachment read: 15-40 ms
• S3 attachment read: 80-200 ms (network-dependent)

For multi-region deployments, EFS with read caching is a common middle ground.

Scaling thresholds

Approximate concurrent-user ranges per instance size, as a starting point for sizing (mixed workload, 70% read 30% write):

"Concurrent active" means users with the browser open and clicking; total registered users can be 5-10x this since most users aren't actively clicking at any instant.

What still slows down Odoo 19

Despite the gains, certain patterns still cost performance:

• Computed Studio fields (sandbox slower than native — see Studio article)
• Unindexed search() on JSON fields with deep paths
• Many2many fields with thousands of relations on a single record
• Reports that aggregate millions of rows without proper aggregation domains
• Bulk write() triggering computed-field recompute on related records

Profile with --log-level=debug_sql to find the slow queries; use the developer-mode profiler for ORM-level analysis.

Frequently Asked Questions

Should I run PostgreSQL on the same server as Odoo?

For instances up to t3.xlarge / c6i.2xlarge, yes — co-location reduces network latency and is operationally simpler. Beyond that, separate the DB onto RDS or a dedicated PG server. The threshold is roughly when you have 100+ concurrent users or your DB approaches 50 GB.

Does upgrading from PG 14 to PG 17 require a separate migration?

Yes. PG major-version upgrades use pg_upgrade which is fast (minutes for typical Odoo databases) but is its own operation. Schedule it as part of the Odoo 17 → 19 migration window, not before or after. Test on staging first.

How do I monitor Odoo performance in production?

Three tools we use: (1) pg_stat_statements for slow queries, (2) Odoo's built-in profiler in developer mode, (3) external APM (Datadog or Sentry's performance product) for end-user latency. PM2 logs and htop cover process-level health.

What's the impact of Odoo's worker memory leak (rumored)?

Odoo 19 fixed several long-running memory issues from 17. Workers should plateau around 400-600 MB with normal usage. If you see workers grow beyond 1 GB, you likely have a custom module leaking — review for cached recordsets, unclosed file handles, or unbounded loops over search([]).

Can I run Odoo 19 on PostgreSQL 16 instead of 17?

Yes — PG 16 is the minimum supported. PG 17 gives ~5-10% additional gain on analytics queries due to incremental sort and improved JSON paths. For most workloads PG 16 is fine; the real reason to be on PG 17 is long-term support runway.

---

Performance tuning in Odoo 19 is high-leverage: a half-day of tuning can turn a sluggish instance into a snappy one. ECOSIRE's Odoo support and maintenance service includes a quarterly performance review with PostgreSQL tuning, worker rebalancing, and slow-query analysis. See our Odoo customization service for instance-specific optimization or browse our Odoo modules catalog for performance monitoring add-ons.