Odoo Performance Optimization: Tuning Guide for UAE Businesses

Odoo performance complaints — slow page loads, timeouts during reporting, sluggish month-end closes — are almost never an Odoo problem. They are usually configuration, infrastructure, or database hygiene issues. This article walks through the diagnostic and tuning steps that solve 95% of Odoo performance problems.

Step 1: Establish the Baseline

Before tuning anything, measure. Note typical response times for the workflows users complain about most:

• Opening the sales pipeline
• Loading an invoice
• Generating the trial balance
• Loading a product form with many variants
• Running monthly inventory valuation

Step 2: Check the Workers Configuration

Odoo’s worker model is the single biggest performance lever. The right number depends on your server’s CPU and RAM. A rough starting point:

• Workers = (2 × CPU cores) + 1, capped by RAM (each worker uses 200–400 MB)
• cron workers = 1 or 2 separate workers dedicated to scheduled jobs
• longpolling worker = 1 dedicated for real-time chat

Under-configured workers cause queueing; over-configured workers cause RAM exhaustion. Both manifest as “slow Odoo”.

Step 3: PostgreSQL Tuning

Default PostgreSQL config is built for any workload, not Odoo specifically. Key parameters to tune:

• shared_buffers = 25% of available RAM
• effective_cache_size = 75% of available RAM
• work_mem = 16-64 MB depending on workload
• maintenance_work_mem = 256 MB minimum
• random_page_cost = 1.1 for SSD-backed storage

Tools like PGTune produce safe starting values based on your hardware.

Step 4: Index Audit

Custom modules sometimes introduce queries that miss indexes. Use PostgreSQL’s pg_stat_statements extension to find slow queries, then add indexes on the columns being filtered or joined.

Step 5: Database Maintenance

• VACUUM ANALYZE regularly (autovacuum should handle this; verify it is enabled)
• REINDEX on indexes that have bloated
• Archive or purge old data — message attachments, log records, computed fields no longer needed
• Truncate mail_message and mail_tracking_value for very old chatter where retention is not legally required

Step 6: Custom Module Audit

Custom modules are the most common performance villains. Look for:

• Computed fields that recompute on every read
• Inefficient ORM patterns (loops doing queries inside the loop)
• Unindexed search criteria in _compute methods
• Excessive @api.depends dependencies triggering recomputation cascades

Step 7: Asset and Page Load Optimization

• Enable HTTPS with HTTP/2
• Use a CDN for static assets (CloudFlare common)
• Enable Odoo’s asset bundling and minification
• Configure long-cache headers for static assets
• Compress responses (gzip or Brotli)

Step 8: Reporting Workload Isolation

Heavy reports (especially custom Python reports across large data sets) can monopolise workers. Strategies:

• Schedule heavy reports to run at night and email results
• Use Odoo’s read-replica setup to offload reporting to a separate database server
• Materialise complex aggregations into summary tables refreshed periodically

When to Add Hardware

Hardware upgrades are a last resort, not a first response. Most Odoo performance complaints are solved by the steps above. When hardware is genuinely needed, the order is usually: more RAM, faster SSD, more CPU cores, separate database server, then horizontal scaling.