LAST UPDATED SEPTEMBER 2025

Note that un-optimized customizations involving Python scripting (custom fields, custom automated actions, custom modules) are the most common root causes of performance problems. 

Imagine buying groceries from a large supermarket with a row of checkout lines at the front. 

Each checkout is staffed by a worker and they serve just the Customers in their line.

How many workers needed depends on:

• how many Customers are ready to leave [demand rate]; and 
• how many items each of them have [demand volume]

It could be that a worker could manage:

• 100 customers an hour scanning 8 to 12 items per transaction [high rate, low volume]
• 10 customers an hour scanning 12 to 50 items per transaction
• 1 customer an hour scanning 50 to 200 items per transaction [low rate, high volume]
  
  

Hire too many workers and they may not be needed, not enough and customers may get tired of waiting and leave.

With Odoo, think of the rate as the number of end Users logging in or visitors looking at your website and the volume as the resources needed. To search products matching a keyword takes very little resources. To generate and download a detailed multi-year, multi-company, consolidated accounting report needs more resources.

For planning purposes, you should start with 1 worker per: 

• 25 end users or 
• 5,000 daily website visitors. 

The resources that end users and/or visitors consume can vary a great deal depending on:

• what features have been configured
• how many hours a day end users are active
• number of pages a website visitors visits 
• spread of website traffic over time (steady), vs concentrated (surge)
• ratio of end users to visitors 

Given this, you only really know how many workers you need when you are live, so should be monitoring your performance prior to go live, during testing, and after go live in case you need to rollback to a point where performance was not an issue.

In addition to using logging (and looking at log files) we provide RESOURCE MONITORING features with Odoo.sh:

• performance analysis and CPU visualization (flamegraph)
• system, http and mail monitoring (grafana)

With this in mind:

• 1 worker is about 6 to 10 concurrent users.

concurrent = users clicking a button at the "exact same time".  

A large amount of time (can be over 98% of the time) there is no active use of Odoo. The use is passive - users are reading, typing, scrolling (and thinking) and that does not count as 'using' Odoo since only client (not server) resources are consumed.  Only when a User or Visitor clicks a button, runs a report, imports data, etc. are server resources consumed.

Considerations:

• Using Odoo once a day to enter time sheets is EXTREMELY LIGHT use
• Using Odoo 6 hours a day at a call center logging every call is EXTREMELY HEAVY use. 
• Most are somewhere in between - test multiple scenarios with different extremes.

For one database, a single worker may struggle to support 25 end users.

For another database, a single worker may support 100 users without any problems.

The great thing about Odoo.sh is that extra workers are not hard to add.

This same strategy applies for ON PREMISE installations of Odoo. For some databases, SQL profiling may identify database level optimizations - either with the database schema or with the performance parameters of PostgreSQL - that may require migrating to an on-premise deployment.

See also:

https://www.odoo.com/documentation/master/administration/hosting.html

https://www.odoo.com/documentation/master/developer.html

https://www.odoo.sh/pricing