Odoo's default deployment guide is designed for simplicity. It gets you running. It does not get you to production at scale. This post covers the architectural decisions that separate a performant enterprise Odoo deployment from one that buckles under load.
The stack
For any Odoo deployment handling 500+ concurrent users, the standard single-server setup is a liability. We architect a multi-layer deployment:
- Nginx as reverse proxy and TLS terminator
- Multiple Odoo worker processes behind a load balancer
- Redis for session storage and caching
- PostgreSQL with read replicas for reporting workloads
- Separate longpolling server for live chat and notifications
PostgreSQL tuning
The database is almost always the bottleneck. Key tuning parameters: shared_buffers, work_mem, effective_cache_size, and checkpoint_completion_target. Add EXPLAIN ANALYZE to your slow query toolkit.
Caching strategy
Odoo's built-in caching is often underutilized. Use @tools.ormcache judiciously on read-heavy computed fields, and implement Redis-backed view caching for public-facing portal pages.