How many Odoo workers do I need? A practical sizing guide
How to size Odoo workers: what a worker does, Odoo's rule of one worker per six concurrent users, memory per worker, and the signs that you need more or fewer.
By Muhammad Salman Ali Khan, Founder, Knova Digital Solutions · Published · 6 min read · Performance, Odoo hosting, Pricing
"How many workers do we need?" is the first sizing question in almost every Odoo project, and the one that drives the hosting bill when you pay per worker. The honest answer is "fewer than you fear, and more at month-end", but there is a method behind it. This guide explains what a worker is, the rule of thumb Odoo publishes, how to read the signs once you're live, and when more workers won't help at all.
What a worker is
In production, Odoo runs in multi-processing mode: several worker processes, each answering one HTTP request at a time. When someone opens a list, saves an invoice or prints a report, one worker handles that request from start to finish, then takes the next one. When every worker is busy, new requests wait their turn, and users feel it as a slow click.
Next to the HTTP workers, Odoo runs:
- cron workers for scheduled actions (emails, recurring invoices, bank synchronisation), which also need CPU;
- a live chat worker (gevent) that keeps the real-time connections for chat and notifications, so they don't occupy an HTTP worker.
Running Odoo in threaded mode (workers = 0) is fine on a laptop, not on a production server with several CPUs: one process can't use them all.
Odoo's rule of thumb
Odoo's own deployment guide gives three starting points:
- 1 worker serves about 6 concurrent users.
- The theoretical maximum on a server is (number of CPUs × 2) + 1 workers.
- For memory, assume 80% of requests are light (about 150 MB of RAM per worker) and 20% are heavy (about 1 GB).
Its worked example: a server with 4 CPUs and 60 concurrent users. 60 ÷ 6 gives 10 workers, but (4 × 2) + 1 caps the server at 9, so the guide uses 8 HTTP workers plus 1 for cron, and about 3 GB of RAM for Odoo. It also says to watch the CPU load afterwards, which is the part people skip.
Concurrent users are not named users
The rule counts concurrent users: people whose clicks reach Odoo at the same moment. A company with 40 people who have a login rarely has 40 requests in flight. Some are in meetings, some keep a tab open without touching it, and a single click takes a fraction of a second.
What matters are the peaks:
- month-end and year-end closing, when accounting runs reports all day;
- a busy point of sale, or a warehouse validating deliveries in waves;
- your website and portal, where every visitor's page is a request too;
- integrations (an e-commerce connector, a mobile app, the API) that call Odoo on their own schedule.
A useful exercise: count the people who use Odoo at the busiest hour of the busiest day, add your integrations, and size for that, not for the average.
A starting point
Applied to typical teams, the rule of thumb gives:
| Concurrent users at the peak | Workers by the rule (users ÷ 6) | A sensible start |
|---|---|---|
| Up to 6 | 1 | 1 to 2 |
| 7 to 12 | 2 | 2 to 3 |
| 13 to 24 | 3 to 4 | 4 |
| 25 to 48 | 5 to 8 | 6 to 8 |
| 60 | 10 | 8 plus 1 cron, on 4 CPUs (Odoo's example) |
The extra worker in the right-hand column is headroom for heavy requests: a large report or an import holds a worker for seconds, not milliseconds, and everyone else shares the rest meanwhile. Most small teams start with one or two workers and add more as usage grows.
What makes a request heavy
Heavy requests are where sizing goes wrong. The usual ones:
- printing large PDF reports, or many at once;
- importing or exporting thousands of lines;
- list and pivot views with computed fields over a big history;
- custom modules that run slow queries;
- scheduled actions that process everything at once.
A heavy request occupies a worker for its whole duration and uses more memory. Two or three running together can make Odoo feel slow for everyone, even though the average load is low.
When more workers help, and when they don't
More workers help when the slowness follows the number of people: pages are quick early in the morning and slow at 11:00, response times rise with the number of requests, and the CPU has room to spare.
More workers don't help when one action is slow on its own, even with nobody else around. A worker can't make a single request faster. Find out what that request does: a missing index, a computed field recalculated too often, a report that loads too much. Fixing it is cheaper than paying for capacity forever.
Memory is the other limit. Each worker needs RAM, and a server that runs out of memory gets slower, not faster, when you add workers. Size workers and memory together, as Odoo's guide does.
Sizing on Cloud Buddy
On the Cloud Buddy cloud you choose the number of production workers in your plan, $72 each a month (or $57.60 billed yearly), and you can change the plan later; the difference is prorated. To decide with data rather than guesses:
- the Monitor tab of each branch graphs CPU, memory, requests and response times, with your releases marked on the graphs, so you can see whether slowness follows traffic or a deploy;
- the code profiler in the Tools tab records what every worker does for up to five minutes and shows it as a flame graph, function by function, which is how you find the one slow request that more workers would never fix;
- staging runs on a copy of production, so you can test a heavy import or report there before production feels it.
On your own server, our installer computes the workers and memory limits from the server's CPUs and memory and any other Odoo already running on it, shows you the calculation, and lets you change it.
See the current prices for a plan of your size, and our Odoo.sh pricing guide for how per-worker billing compares.
The short version
- A worker handles one request at a time; cron and live chat have their own workers.
- Odoo's rule of thumb: 1 worker per 6 concurrent users, at most (CPUs × 2) + 1 per server, about 150 MB per light worker and 1 GB per heavy one.
- Size for the busiest hour, count integrations, and keep one worker of headroom for heavy requests.
- If one action is slow on its own, profile it; more workers won't fix it.
Odoo is a trademark of Odoo S.A. Cloud Buddy is an independent service, not affiliated with or endorsed by Odoo S.A.