Odoo Hosting Requirements in 2026: Server Sizing by User Count (With Real Configs)

For a production Odoo 17/18/19 deployment in 2026, the working baseline is: 2 vCPU and 4 GB RAM for up to 5 concurrent users, 4 vCPU and 8 GB for 10–25 users, 8 vCPU and 16 GB for 25–60 users, and 16 vCPU and 32 GB (with the database split onto its own server) somewhere past 75–100 concurrent users. Storage starts at 50 GB SSD/NVMe and grows mainly with attachments, not records. The numbers that actually determine performance, though, are not the headline specs — they are the Odoo worker configuration and PostgreSQL tuning, which is where most self-hosted deployments are misconfigured.

This guide gives you the full sizing tables, the worker math, the odoo.conf and postgresql.conf values we deploy in production, and an honest comparison of self-hosting against Odoo Online and Odoo.sh — including when each one is the wrong choice.

Key Takeaways

• Size by concurrent users, not named users: a 100-employee company rarely exceeds 30–40 concurrent Odoo sessions
• The worker formula is the heart of Odoo sizing: workers = (CPU cores × 2) + 1, with each worker consuming roughly 150–300 MB RAM (1 GB+ under heavy reports)
• PostgreSQL deserves 25% of system RAM as shared_buffers and is the first thing to move to its own server as you scale
• Storage growth is driven by the filestore (attachments, documents), not the database — plan 2–5 GB per active user per year for document-heavy businesses
• Heavy modules change the math: manufacturing (MRP), ecommerce, and large reports can double effective resource needs per user
• A misconfigured 8-core server is routinely outperformed by a well-tuned 4-core one — workers, memory limits, and PostgreSQL settings first, hardware second
• Always deploy a reverse proxy (Nginx), HTTPS, daily tested backups, and staging — these are requirements, not extras

---

Sizing by User Count: The Core Tables

First, the definition that prevents most over- and under-sizing: concurrent users means sessions actively clicking within the same few minutes — typically 30–40% of named users in an office-hours business, lower across timezones.

Application Server Sizing (Odoo 17/18/19)

Real Config Examples (Cloud Instance Mapping)

Two adjustments to apply on top of any table:

Module weight. Manufacturing (MRP runs, BoM explosions), ecommerce (anonymous traffic spikes that bypass your concurrent-user math entirely), and heavy reporting (large PDF runs, big exports) each push you up one tier. A 20-user pure-CRM deployment and a 20-user MRP + ecommerce deployment are two different servers.

Customization weight. Poorly written custom modules — N+1 ORM loops, unindexed searches, synchronous external API calls — consume more hardware than any standard module. If performance degrades after a customization sprint, profile before you resize.

---

The Worker Math (Where Most Sizing Goes Wrong)

Odoo's multi-process mode is controlled by workers in odoo.conf. The canonical formula:

workers = (CPU cores × 2) + 1

Each HTTP worker handles one request at a time, so workers are effectively your true concurrency ceiling. Each consumes roughly 150–300 MB RAM at rest and can spike past 1 GB on heavy operations, which is what the memory limits are for.

Production odoo.conf baseline for an 8 GB / 4 vCPU server (10–25 users):

[options]
workers = 9
max_cron_threads = 2
limit_memory_hard = 2684354560
limit_memory_soft = 2147483648
limit_time_cpu = 600
limit_time_real = 1200
limit_request = 8192
proxy_mode = True

Notes that save real incidents:

• limit_memory_soft (here 2 GB) recycles a worker gracefully after the current request; limit_memory_hard (2.5 GB) kills it immediately. Set soft below hard, and both below (total RAM − PostgreSQL − OS) ÷ workers headroom.
• max_cron_threads counts against your capacity — heavy scheduled jobs (mail queues, MRP scheduler, stock recomputation) need their own budget. Two is right for most SMB deployments.
• workers = 0 (threaded mode) is for development only. If a "slow Odoo" complaint lands on a production server, this is the first thing to check — it still ships as the default.
• proxy_mode = True is mandatory behind Nginx, or session and redirect behavior breaks subtly.

---

PostgreSQL Tuning: The Other Half of Performance

Odoo is a database-bound application. Default PostgreSQL settings target a 2005-era machine; on modern hardware they waste most of your RAM. For PostgreSQL 16/17 on a server where the DB gets 8 GB (e.g., a dedicated DB box or the DB share of a 16 GB combined server):

Three operational rules:

1. Move PostgreSQL to its own server once you pass roughly 50–60 concurrent users (or earlier for MRP/ecommerce). Odoo workers and PostgreSQL compete for the same CPU caches and I/O; separation is the single biggest scaling step.
2. random_page_cost = 1.1 matters more than people expect. On NVMe with the spinning-disk default, the planner avoids index scans it should be taking; this one line fixes a class of mysteriously slow list views.
3. Autovacuum stays on, tuned, never disabled. Odoo's write patterns (stock moves, mail messages, sessions) bloat tables quickly. If large tables like mail_message grow into the tens of GB, tune per-table autovacuum thresholds rather than turning anything off.

---

Storage: It Is the Filestore, Not the Database

A healthy Odoo database for a 50-user company typically sits at 5–30 GB. The filestore — attachments, scanned documents, product images, generated PDFs — is what actually grows, especially with the Documents app or heavy email volume:

Practical consequences: provision NVMe for the database volume (PostgreSQL latency is your UX), but the filestore can live on cheaper block storage or object storage with a sync layer. Back up both — a depressingly common disaster pattern is nightly pg_dump with no filestore backup, which restores a database full of attachment references pointing at nothing. Test restores quarterly; an untested backup is a hope, not a plan.

---

Self-Hosted vs Odoo Online vs Odoo.sh

Sizing only matters if self-hosting is the right call, so be honest about the alternatives:

The honest summary: Odoo Online is the right answer for businesses with standard workflows and no custom development — do not self-host out of habit. Odoo.sh suits Enterprise customers who need custom modules but not infrastructure control. Self-hosting wins when you need Community edition, full tuning control, specific data residency, deep integrations, or when worker-based Odoo.sh pricing crosses your own infra cost — but it transfers the entire ops burden (patching, monitoring, backups, upgrades, security) to you. If you want self-hosting economics without carrying that burden in-house, managed Odoo hosting providers such as ECOSIRE.IO run tuned, monitored, backed-up Odoo infrastructure as a service.

Whatever you choose, the non-negotiables for production are the same: Nginx (or equivalent) reverse proxy with HTTPS, proxy_mode = True, a firewall that exposes only 80/443 (never 8069 directly), daily off-site backups of database plus filestore with tested restores, a staging environment for upgrades, and monitoring on CPU, RAM, disk, and PostgreSQL connections.

---

Frequently Asked Questions

What are the minimum server requirements for Odoo in 2026?

For a small production deployment (up to 5 concurrent users), 2 vCPU, 4 GB RAM, and 50 GB SSD running Odoo and PostgreSQL together is a safe floor for Odoo 17/18/19. Below that — 2 GB RAM VPS tiers — Odoo will start, but worker limits and PostgreSQL will fight for memory and you will see worker recycling under normal use. Development and demo instances can run smaller with workers = 0, but never production.

How much RAM does Odoo need per user?

Plan via workers, not raw per-user math: workers = (CPU cores × 2) + 1, each worker using 150–300 MB at rest and up to 1 GB+ during heavy reports, plus 25% of system RAM reserved for PostgreSQL if co-hosted, plus 1–2 GB for the OS. In practice this lands near 300–500 MB per concurrent user on a tuned server. Remember concurrent users are typically only 30–40% of named users.

When should I move PostgreSQL to a separate server?

At roughly 50–60 concurrent users — earlier if you run manufacturing, ecommerce, or heavy reporting. Odoo workers and PostgreSQL compete for CPU and I/O on a shared box, and splitting them is the single most effective scaling step before horizontal app-tier scaling. The DB server wants fast NVMe storage, 25% of its RAM as shared_buffers, and random_page_cost = 1.1 so the planner trusts your SSDs.

Is Odoo.sh or self-hosting better?

Odoo.sh is better when you run Enterprise, need custom modules, and do not want to own infrastructure operations — it includes staging branches, backups, and managed upgrades. Self-hosting is better when you need Community edition, full tuning control, specific data residency, or when Odoo.sh worker pricing exceeds your infrastructure cost at scale. The trap is choosing self-hosting without budgeting the ops time; managed Odoo hosting (for example ECOSIRE.IO) is the middle path — self-hosted economics with the operations handled for you.

Why is my Odoo slow even though the server has plenty of resources?

The four most common causes, in order: workers = 0 (threaded development mode left on in production), untuned PostgreSQL (default shared_buffers and spinning-disk random_page_cost on SSD hardware), a custom module doing N+1 ORM queries or synchronous external API calls, and table bloat from disabled or starved autovacuum. A correctly tuned 4-core server routinely outperforms a misconfigured 8-core one — profile and tune before resizing.

How much storage does an Odoo deployment need over time?

Start at 50–100 GB SSD and plan growth around the filestore, not the database. The DB for a 50-user company typically grows 3–8 GB per year, while attachments, scanned documents, and generated PDFs grow 10–40 GB per year for inventory-driven businesses and 30–100 GB+ for document-heavy ones. Put the database on NVMe, allow the filestore on cheaper storage, and always back up both together — a database backup without its filestore restores broken attachment references.

---

Get Your Deployment Sized and Tuned Properly

Most Odoo performance complaints we investigate are not hardware problems — they are configuration debt: default workers, untuned PostgreSQL, missing proxy settings, and backups nobody has ever restored. ECOSIRE sizes, deploys, tunes, and operates production Odoo infrastructure: our support and maintenance service covers monitoring, tuning, backups, and upgrades on your servers, and our migration service handles moves between hosting models — Online to self-hosted, Odoo.sh to your own cloud, or version upgrades with staging and rollback plans. For fully managed hosting, ECOSIRE.IO runs the entire stack for you.

Contact us with your user count, module list, and current hosting — we will return a concrete sizing and tuning recommendation, not a generic tier.