Key Takeaways
- PostgreSQL tuning is the single biggest performance improvement for most Odoo deployments
- Worker count should be set to (2 x CPU cores + 1) with proper memory limits
- Redis session store and CDN for static assets reduce server load significantly
- Regular database maintenance (VACUUM ANALYZE, archiving old data) prevents degradation
- Monitor with Prometheus/Grafana to identify bottlenecks before users complain
PostgreSQL Performance Tuning
PostgreSQL configuration is the single most impactful performance optimization for Odoo. Default PostgreSQL settings are conservative and designed for minimal resource usage, not production ERP workloads.
| Parameter | Default | Recommended | Purpose |
|---|---|---|---|
| shared_buffers | 128MB | 25% of RAM | Shared memory for caching |
| effective_cache_size | 4GB | 75% of RAM | Query planner cost estimation |
| work_mem | 4MB | 32-64MB | Per-operation sort/hash memory |
| maintenance_work_mem | 64MB | 512MB-1GB | VACUUM, CREATE INDEX memory |
| random_page_cost | 4.0 | 1.1 (SSD) | SSD-aware query planning |
| checkpoint_completion_target | 0.5 | 0.9 | Spread checkpoint I/O |
Use PGTune (pgtune.leopard.in.ua) to generate optimized PostgreSQL configuration based on your server specifications. Input your RAM, CPU count, storage type, and connection count for customized recommendations.
Odoo Worker Configuration
Odoo workers handle incoming requests. Proper worker configuration balances concurrency with resource consumption to prevent server overload.
| Parameter | Formula/Value | Purpose |
|---|---|---|
| workers | (2 x CPU cores) + 1 | Number of HTTP request handlers |
| max_cron_threads | 2 | Background job processors |
| limit_memory_hard | 2684354560 (2.5GB) | Kill worker exceeding this RAM |
| limit_memory_soft | 2147483648 (2GB) | Recycle worker after request |
| limit_time_cpu | 60 | Max CPU seconds per request |
| limit_time_real | 120 | Max wall-clock seconds per request |
| limit_request | 8192 | Recycle worker after N requests |
Total RAM needed = (workers + max_cron_threads) x limit_memory_hard + PostgreSQL memory. For 8 workers + 2 cron threads: 10 x 2.5GB = 25GB for Odoo alone. Size your server accordingly.
Caching and CDN Configuration
Caching reduces server load by serving frequently requested data from fast storage. A CDN offloads static assets to edge servers closer to users.
- Install Redis and configure Odoo to use Redis for session storage (faster than PostgreSQL sessions)
- Configure Nginx to cache static assets (images, CSS, JS) with long expiration headers
- Set up a CDN (Cloudflare, AWS CloudFront) for static asset delivery
- Enable Odoo's asset bundling and minification in production mode
- Configure browser caching headers: 1 year for versioned assets, 1 hour for HTML
- Use Nginx micro-caching for anonymous pages (website, product catalog)
Redis session storage is particularly important for multi-worker deployments. Without Redis, sessions are stored in PostgreSQL, adding database load. With Redis, session lookups are sub-millisecond.
Database Maintenance and Cleanup
Odoo databases accumulate data that degrades performance over time. Regular maintenance keeps the database lean and queries fast.
| Maintenance Task | Frequency | Impact |
|---|---|---|
| VACUUM ANALYZE | Daily (automated) | Reclaims space, updates statistics |
| Archive mail messages | Monthly | Reduces mail_message table bloat |
| Purge old logs | Monthly | Reduces ir_logging table size |
| Clean attachments | Quarterly | Removes orphaned file references |
| Reindex tables | Quarterly | Rebuilds indexes for efficiency |
| Archive old records | Annually | Moves historical data to archive |
The mail_message, ir_attachment, and ir_logging tables are the most common sources of database bloat. A 3-year-old Odoo instance can have millions of mail_message records. Archiving or purging old entries can reduce database size by 30-50%.
Infrastructure Monitoring and Sizing
Proactive monitoring identifies performance issues before users notice them. Proper infrastructure sizing prevents capacity-related slowdowns.
| Concurrent Users | Odoo Server | PostgreSQL Server | Architecture |
|---|---|---|---|
| 10-25 | 2 CPU, 4GB RAM | 2 CPU, 8GB RAM | Single server OK |
| 25-50 | 4 CPU, 8GB RAM | 4 CPU, 16GB RAM | Separate DB recommended |
| 50-100 | 8 CPU, 16GB RAM | 8 CPU, 32GB RAM | Separate servers required |
| 100-200 | 16 CPU, 32GB RAM | 16 CPU, 64GB RAM | Load balancer + replicas |
| 200+ | Multiple app servers | Primary + replicas | Full HA architecture |
- Monitor: response time (p95 should be under 3 seconds), CPU usage, memory consumption
- Alert thresholds: CPU above 80% sustained, RAM above 85%, response time above 5 seconds
- Tools: Prometheus + Grafana dashboards, or Datadog/New Relic for managed monitoring
- Log analysis: centralize Odoo and PostgreSQL logs with ELK stack or Loki for troubleshooting
Frequently Asked Questions
Related services from Verbsz Technologies
If this article is relevant to a project on your roadmap, these are the services our team typically delivers.