Odoo server sizing calculator.
How many workers, how much RAM, and what to put in odoo.conf — worked out from Odoo's own documented formulas rather than a vendor's guess. Adjust the inputs and the configuration file rewrites itself.
Size an Odoo server
Answer four questions. You get a worker count, a vCPU and RAM figure, PostgreSQL settings that match, and an odoo.conf you can paste. Everything runs in your browser — nothing is sent anywhere.
- HTTP workers
- —
- Cron workers
- —Background jobs
- vCPU
- —
- RAM
- —
—
—What the calculator is actually doing
No black box. Three of the four numbers come straight from Odoo's own deployment documentation, and the fourth is an assumption we make visible rather than hide.
Workers, from concurrent users
Odoo documents that one worker handles roughly six concurrent users, and that a worker manages about six concurrent requests. So the HTTP worker count starts at ceil(concurrent users ÷ 6), with a floor of two — a single worker means one slow report blocks everybody, and there is no such thing as a production Odoo with one worker.
Website traffic and integration load add workers on top, because anonymous visitors and API callers compete for exactly the same processes your staff are using. That is the mistake behind most "Odoo got slow when we launched the shop" tickets.
vCPU, from workers
Odoo's rule of thumb runs the other way: workers = (CPU × 2) + 1. Invert it and you get the CPU count that suits the workers you need — ceil((workers − 1) ÷ 2). Cron workers are not in that formula but they still consume CPU, so the calculator adds headroom for them rather than pretending they are free.
RAM, from an assumption we then enforce
Here is the honest part. Nobody can tell you what a worker on your database will use, because it depends on your custom code and the size of the recordsets you touch. So rather than assert a number, the calculator picks a per-worker memory budget from your workload profile — and then writes that same number into limit_memory_soft in the generated config.
That makes the estimate self-consistent by construction. Odoo recycles a worker that exceeds the soft limit after it finishes its current request, so the budget is not a prediction, it is a policy. The hard limit sits above it as the abort threshold. If your workers are constantly recycling, the budget was too tight and you raise both — but you will find that out from the logs, which is the correct way to find it out.
PostgreSQL, from the RAM
Standard proportions: shared_buffers at a quarter of system memory, effective_cache_size at three quarters, maintenance_work_mem at a sixteenth capped at 2 GB. Connections are the Odoo-specific trap — each worker can open up to db_maxconn connections, so leaving it at the default while running a dozen workers asks PostgreSQL for hundreds of connections it should not have to serve. The config keeps db_maxconn deliberately low and sizes max_connections to match.
Four things that will change the answer
- Your custom modules. One badly written compute field on a frequently-read model will outweigh every number above. Profile before you scale up — a bigger server makes slow code cheaper to tolerate, not faster.
- Your data volume. Fifty users on a 5 GB database and fifty on a 500 GB database are not the same workload. Above roughly 100 GB, PostgreSQL tuning and index review matter more than adding workers.
- Your attachments. The filestore lives on disk, not in the database, and it grows quietly until a backup fails. Size storage for both, and back them up as one unit — a dump without its filestore restores to broken attachments.
- Peak versus average. Month-end close, a Black Friday hour, an inventory count. Size for the peak you cannot reschedule, not the Tuesday-afternoon average.
The deeper checklist — reverse proxy, dbfilter, backups, monitoring, who owns the upgrade — is in Odoo self-hosted requirements. Hardware is the easy half of this problem.
Turning the numbers into a machine
Once you have a vCPU and RAM figure, the VPS decision is mostly about who you want to call when the disk fills up. A few notes that save money:
- Prefer fewer, faster cores over many slow ones. Odoo request handling is largely single-threaded per worker, so clock speed shows up in page load times in a way core count does not.
- Insist on NVMe. PostgreSQL on network storage with unpredictable latency is the most common cause of “Odoo is slow” that turns out not to be Odoo.
- Buy RAM before CPU. Running out of memory means the OOM killer takes a worker mid-request; running short on CPU means requests queue. One is an outage, the other is a slow afternoon.
- Keep 30% headroom. A server sized exactly to today has no room for the upgrade, the import, or the report someone writes next quarter.
Provider-specific setup: Hetzner, the VPS comparison, or the install walkthrough once you have picked one. If the whole exercise reads as work you would rather not own, flat-fee managed hosting is the version where somebody else holds the pager.
FAQ
How many workers does Odoo need?
Odoo documents roughly six concurrent users per worker, so start at ceil(concurrent users ÷ 6) with a floor of two. Add workers for public website traffic and for API or integration load, because those compete for the same processes your staff use.
What is Odoo's worker formula?
Odoo’s rule of thumb is workers = (CPU × 2) + 1. Inverted, the CPU count you need for a target worker count is ceil((workers − 1) ÷ 2). Cron workers sit outside that formula but still consume CPU, so leave headroom for them.
How much RAM does an Odoo server need?
It depends on your custom code and recordset sizes, so treat any figure as a budget rather than a prediction — then enforce it with limit_memory_soft, which recycles a worker that exceeds it. Budget roughly 384 MB per worker for light CRM use, 640 MB for typical ERP and 1 GB for heavy reporting, plus PostgreSQL and the OS.
What should max_connections be for Odoo?
Size it from workers, not from users. Each Odoo worker can open up to db_maxconn connections, so keep db_maxconn low — around 8 — and set PostgreSQL’s max_connections to roughly (workers + cron) × db_maxconn plus a reserve of about 20.
Is more CPU or more RAM better for Odoo?
RAM first. Running out of memory means the OOM killer takes a worker mid-request, which is an outage; running short of CPU means requests queue, which is a slow afternoon. Also prefer fewer fast cores to many slow ones — request handling is largely single-threaded per worker.
Does this calculator send my data anywhere?
No. It runs entirely in your browser. Nothing is submitted, stored or logged.
Related reading
Or skip the arithmetic entirely.
Flat-fee managed Odoo Community — sized, monitored, backed up and upgraded. $150/month up to 25 people, $450/month unlimited.