Most Odoo hosting decisions are made once, during signup, and then never looked at again. Someone counts the team, picks the plan whose user count matches, and moves on. That is a reasonable starting point and a poor long term answer, because Odoo's demand on a server tracks what people do far more closely than how many of them hold a login.
Here is what actually determines the size of an Odoo instance, and how to reason about it without guessing.
Named users are not concurrent users
A company with 60 Odoo accounts rarely has 60 people submitting requests in the same second. A sales rep opens a record, reads it, types for two minutes, saves. Accountants work in bursts around period close. The number that stresses a server is concurrent activity, and in a typical back office it is a fraction of the named user count at any given moment.
The exceptions matter more than the rule. A retail chain running Point of Sale has cashiers hitting the system continuously through opening hours. A manufacturing floor with barcode scanners produces a steady stream of small writes. An ecommerce storefront puts anonymous visitors on the same instance as your staff. If any of that describes you, headcount tells you almost nothing and traffic shape tells you almost everything.
What consumes CPU and memory
Odoo serves requests through a pool of worker processes. Each worker handles one request at a time and holds its own memory. That leaves you two practical levers, worker count and memory per worker, and a handful of workloads that pull on them differently:
- Interactive use. Cheap per request, but it arrives constantly and it is what users notice first when there is nothing free to answer them.
- Report generation. A PDF with hundreds of lines, or a pivot across a full year, can hold a worker far longer than a normal page view.
- Imports and bulk edits. One person importing tens of thousands of rows occupies a worker for the duration and competes with everyone else.
- Scheduled actions. Crons, recurring invoices, replenishment, and integrations run on their own clock, and the heaviest ones often run overnight where nobody sees them until they overlap with the backup window.
- API traffic. An external system polling your instance is a user that never sleeps, never takes lunch, and never gets bored of retrying.
Database growth comes from places nobody plans for
Transaction volume is the obvious driver. The quieter ones do more damage over time:
- Attachments. Scanned invoices, product images, and inbound email attachments frequently outgrow the business data itself.
- Chatter. Every message, log note, and tracked field change is stored. On a busy record type that accumulates faster than the records do.
- Point of Sale and stock. Order lines and stock moves are individually small and collectively enormous.
Storage is usually the cheapest resource to add, so the size itself is not the problem. The consequences are. A database that has quietly tripled changes how long a backup takes, how long a restore takes, and how long a version upgrade takes. Those are the numbers that hurt on the day you need them.
How to tell you sized too small
Under-sizing rarely announces itself as an outage. It shows up as pages that take several seconds in the afternoon and feel fine at 8am, month end reports that time out while the same report is fine mid-month, imports that have to be scheduled after hours because running them in the day slows everyone down, and integrations that start timing out during your busiest window. When the complaint is "the system is slow after lunch", you are usually looking at a capacity shape rather than a bug.
How to tell you sized too large
Over-sizing is quieter, and it bills you every month. If your instance has been on the same tier for two years, your transaction volume has not changed much, and nobody has complained about speed, you are probably paying for headroom you never reach. That is a legitimate trade if it buys you calm during a known peak. It is waste if the peak never comes.
A practical way to size
- Start from peak concurrent activity, not from headcount. Ask when the system is busiest and how many people are genuinely working in it then.
- Name your heavy operations explicitly. Month end close, payroll runs, large imports, scheduled integrations. These, not the average day, set the requirement.
- Estimate growth over the next 12 months rather than the next 5 years. Anything beyond a year is a guess you will revise anyway.
- Separate what needs capacity from what needs fixing. A slow report is often a report problem, and buying a bigger plan will not correct it.
Sizing is a decision you revisit
The most common mistake is treating the plan choice as permanent. Businesses open a branch, launch a store, absorb an acquisition, or add a module that changes the workload profile entirely. The useful habit is to look at how the instance is actually behaving on a set cadence, once a quarter is enough for most companies, and adjust deliberately instead of waiting for users to escalate.
On Plemo, managed Odoo hosting comes with automated backups, point in time recovery, monitoring, and staging environments across the Starter, Professional, and Enterprise plans, so changing tier is an operational step rather than a migration project. Whoever hosts you, the principle holds: size for the peak you can actually name, and treat the number as a decision with a review date.
If your instance is already live and you are not sure whether the slowness is a capacity problem or something in the configuration, settle that question before you pay for more hardware. An ERP health check exists for exactly that distinction.