Summary: This article explains that sizing Odoo workers should be driven by peak concurrency and what users actually do, not total user count. During busy periods, heavy actions like warehouse validations, reporting, accounting batches, and integrations can keep workers occupied; in inventory-heavy systems, concurrent operations often collide on stock.quant, causing locks and retries that lead to “random” slowdowns. The article also outlines a practical way to choose the right number of workers and shows how reducing collisions (shorter transactions, fewer shared hotspots, and better bin/location distribution) helps achieve stable performance.

Why it depends on concurrency and what your users do — not just how many users you have

This article explains how to size Odoo workers based on peak concurrency and what users actually do rather than on total user count. We will show you how heavy peak-hour actions, especially inventory operations colliding on stock.quant can cause locks/retries that make Odoo feel “randomly slow.”

Business case

One of our clients, a supplement manufacturer with an online store and a wholesale channel, ran into the same pattern each day: every morning, pickers started processing last night’s online orders, accountants posted entries, and sales confirmed wholesale orders – all at the same time. That’s when Odoo became painfully slow.

So why does this happen? Does this mean that Odoo is not suitable for operationally demanding businesses? And what do Odoo workers have to do with it?

Let’s break it down.

What are Odoo workers?

Workers are additional server processes that allow Odoo to handle multiple users and requests at the same time.

“How many workers do we need for Odoo?” sounds like a simple sizing question. And it usually starts with a number: We have 40 users, we have 120 users, we’re growing to 200 users. 

But establishing such a number rarely gives you the right answer. 

Workers don’t care how many user accounts exist. They care about how many things are happening at the same time — and how costly those things are.

Workers are about “how busy Odoo gets at any single moment” 

A ‘worker’ is Odoo’s capacity to process requests. When users click, scan, validate, post, print, or search, those actions consume worker time. If enough actions land at the same moment, workers become busy, and new requests start waiting. 

That’s when people sometimes describe Odoo as “slow,” even though the system is technically running. 

So instead of asking, “How many users do we have?” the better question is: “How much concurrency do we have during peak moments?” 

User count is misleading, because not all actions cost the same 

Some usage patterns are light, such as: 

• browsing records 
• editing a customer’s profile 
• checking a sales order 

While other patterns are heavy, such as: 

• validating lots in stock operations 
• generating PDF/Excel reports 
• posting a batch of accounting entries 
• unning automated processes during business hours 

For example, two companies can each have 80 users. One may feel like it is running smoothly with modest worker capacity because usage is light and spread out. The other may struggle with high latency because many users perform heavy actions at the same time.

It’s not the number of people. It’s the shape of the workload.

Related article: How to set up monitoring for your Odoo instance 

The most important sizing factor: concurrency

Concurrency means: how many requests hit Odoo at the same time, especially during your busiest hours. 

A common real-world example:

• 15 warehouse operators scanning and validating operations 
• 10 salespeople confirming orders 
• an integration pushing orders in the background 

All at once, every day, between 10:00 a.m. and 12:00 noon. 

That moment defines your worker requirement — not the number of named users on your license.

Why concurrency can create “surprisingly slow” Odoo performance

If your business uses inventory heavily, there’s one place where concurrency becomes quite visible: stock.quant. 

stock.quant is at the center of “what’s available, where.” It gets touched constantly by: 

• reservations and unreservations 
• barcode workflows 
• picking validation 
• receipts, deliveries, internal transfers

Here’s the key point: These operations often hit the same products and locations, especially with fast-moving items. 

When multiple users (or automated processes) try to update the same stock state at the same time, Odoo and PostgreSQL must protect consistency. That protection often shows up as: 

• one transaction waiting for another (i.e., locking) 
• the operation conflicting and being tried again — which means retries

And retries are not a minor detail — they change the whole user experience. 

A request that normally completes quickly can suddenly take much longer, not because the action itself changed, but because it collided with other concurrent operations touching the same quants. 

This is why teams often experience a pattern like this:

• “Validating a picking is usually quick… but sometimes it takes 10–20 seconds.” 
• “Odoo feels fine until the warehouse peak, then everything lags.”

What’s happening is simple: more concurrency → more contention → more retries → workers stay busy longer → latency grows. 

So, in an inventory-heavy environment, you’re not sizing for “how many warehouse users exist.” You’re sizing for “how many stock operations collide at the same time.”

Related app: Ventor PRO: Odoo barcode app for advanced warehouse workflows.

The practical takeaway for Odoo worker sizing 

Considering Odoo workers, focus on these three questions:

1. What do users actually do in Odoo?
Keep in mind that light browsing behaves much differently than barcode scanning, validation, and reporting. 
2. When is the busiest time of day (or month)?
Workers must survive peak moments, not just average moments.
3. Where do operations collide on shared records?
Inventory often collides on stock.quant (fast movers, popular locations). These collisions create retries, which inflate latency and worker occupancy

That’s the core idea.

How to choose the number of Odoo workers

According to official Odoo documentation, you can add 1 worker per 6 concurrent users, or use this formula: (#CPU x 2) + 1, which we explained in the article about Odoo hardware requirements. But if we are considering operationally demanding businesses with many potentially concurrent operations, this is only a starting point. From here, we adjust this formula based on your company’s fact situation, or evidence.

Our approach is to increase workers step by step and at the same time reduce friction that affects the load.

At each step, we run:

• automatic Odoo performance tests (i.e., repeatable load)
• tests with real warehouse users doing normal work (e.g., scanning/validating, confirming, etc.)

And we measure two things:

• Odoo response times (especially the slow “tail” — that is, the requests users actually complain about)
• concurrency errors in SQL logs (serialization failures / concurrent update patterns that indicate retries and collisions)

We stop increasing workers when the results become stable, such as when response times stayed acceptable under peak concurrency, and concurrency errors dropped to a level that no longer caused noticeable spikes.

How to reduce collisions (so workers do not get stuck in retries)

If your bottleneck is stock.quant contention, adding workers helps only up to a point. The following mitigations usually make the biggest difference:

• Split fast movers across more locations/bins, so the same SKUs are not constantly updating the same quant rows.
• Avoid long transactions in customizations and integrations (i.e., do not keep database transactions open while calling external APIs, generating big files, or looping heavy logic).
• Move heavy work out of interactive flows (async patterns / background jobs where possible), so user actions stay short and release locks quickly.

The practical takeaway: Treat worker count as something you validate under real concurrency, and treat collision reduction as the lever that often turns “spiky latency” into “stable performance.”

Conclusion

When calculating Odoo workers, we do not start with user count. Instead, we start with workload and concurrency. If you run a busy warehouse, concurrency hotspots like stock.quant can trigger lock waits and retries, turning “normal” operations into slow ones during peak moments. This is why the same number of users can require very different worker capacities — and why sizing based on user count alone is one of the most common reasons Odoo feels slow in production performance.

Odoo Workers Aren’t the Only Factor Affecting Performance — Want to Fix Your Odoo Issues?

Recommended articles:

1. Will your Odoo Enterprise contract be surcharged 25% in April? Tricky cases explained…
2. Odoo Implementation Steps
3. Odoo Access Rights Structure
4. AI Order Processing in Odoo
5. Odoo EDI Integration
6. Key Performance Indicators (KPIs) and their Role in Successful ERP Implementation
7. 10 most common questions to the official Odoo partner