Introduction
Enterprise Odoo performance depends on much more than the number of employees who have login accounts. A company may have 500 named users but only 50 to 60 active users during its busiest period, while another company with 150 users may create heavier server load because most of them are processing warehouse transfers, manufacturing orders, accounting reports, POS transactions and API requests at the same time.
That is why Odoo infrastructure planning should begin with workload analysis rather than a generic server specification. The hosting model determines how much infrastructure responsibility the business carries, while the workload determines how much CPU, RAM, storage and PostgreSQL capacity the environment actually needs.
For this article, Cloud refers primarily to Odoo Online, where Odoo manages the infrastructure. If Odoo is installed manually on AWS, Azure, Google Cloud or another public-cloud provider, the sizing approach is closer to self-hosted Odoo because the business or implementation partner still controls virtual machines, PostgreSQL, storage and operating-system configuration.
Understanding Odoo Online, Odoo.sh and On-Premise
Odoo Online is the simplest model from an infrastructure perspective. Odoo hosts and manages the database, so the customer does not choose CPU cores, RAM or PostgreSQL settings. The key limitation is that Odoo Online does not support custom modules or modules from the Odoo Apps Store which makes it most suitable for organizations that can stay close to standard Odoo functionality.
Odoo.sh is a managed Platform as a Service designed for customized Odoo deployments. It integrates with GitHub and provides development, staging and production environments, automated backups and continuous integration. Businesses can deploy custom modules without taking full responsibility for operating the underlying server stack.
On-premise hosting provides the highest level of technical control. The organization chooses the operating system, processor, RAM, database architecture, storage, reverse proxy, backup strategy and monitoring platform. That flexibility can be valuable for enterprise workloads but the organization also becomes responsible for reliability, security and performance tuning.
| Area | Odoo Online | Odoo.sh | On-Premise |
|---|---|---|---|
| Infrastructure management | Managed by Odoo | Managed Odoo platform | Company or hosting partner |
| Custom modules | Not supported | Supported | Supported |
| Worker control | Abstracted | Platform capacity | Fully configurable |
| PostgreSQL tuning | Managed | Managed | Fully controlled |
| OS-level access | No | Limited | Full |
| Staging environments | Limited | Built in | Must be created |
| Backups | Managed | Managed production backups | Organization responsibility |
| Best fit | Standard deployments | Customized Odoo | High-control enterprise deployments |
Size for Concurrent Workload, Not Total Users
One of the most common Odoo sizing mistakes is using total licensed users as the primary hardware metric. Named users do not all generate requests simultaneously and different users create very different levels of server load.
Odoo's official production guidance uses concurrent users when discussing worker sizing. Its rule of thumb is approximately one worker for six concurrent users, while the theoretical worker ceiling is roughly the number of CPU cores multiplied by two plus one. Cron workers also consume CPU capacity, so they need to be included in the final configuration.
Important sizing inputs include:
Peak concurrent internal users.
Website and eCommerce traffic.
Number of active POS sessions.
Barcode and warehouse activity.
MRP and manufacturing calculations.
Accounting and reporting workloads.
Scheduled actions and cron jobs.
Third-party API integrations.
Data imports and exports.
Custom module complexity.
CPU Sizing for Enterprise Odoo
CPU capacity determines how many application workers can process requests and how quickly business logic can execute. Odoo benefits from strong per-core performance because a single request may involve Python logic, ORM operations and database queries while multiple cores allow more workers to serve concurrent requests.
Odoo recommends multiprocessing for production environments and gives the approximate worker formula of CPU cores × 2 + 1 as a rule of thumb. This should not be treated as a command to run the maximum possible number of workers because PostgreSQL, cron jobs and the operating system also need processing capacity.
Enterprise workloads also include background activity. Large stock updates, bank synchronization, automated emails, manufacturing planning and batch invoicing may consume CPU even when user activity looks moderate. Capacity should therefore be tested during real peak periods rather than only during normal screen navigation.
RAM Sizing for Odoo and PostgreSQL
Memory planning must account for more than the Odoo application processes. Odoo's official deployment guidance estimates around 150 MB for a lighter worker and around 1 GB for a heavier worker when computed fields and SQL requests are well designed. These figures are useful for estimating worker memory but should not be treated as total server RAM requirements.
The operating system, PostgreSQL, page cache, reverse proxy, monitoring agents, cron processes and temporary workloads also need memory. A server that assigns nearly all RAM to Odoo workers can leave PostgreSQL with insufficient cache and create unnecessary disk I/O.
For enterprise deployments, RAM should include headroom for temporary spikes caused by imports, spreadsheet exports, PDF reports or custom code. Memory pressure that causes swapping can damage response times even when CPU capacity is otherwise adequate.
Practical Hardware Starting Points
The following ranges are practical planning estimates rather than official Odoo hardware requirements. Actual capacity should be validated with representative data, custom modules and realistic load tests before production.
| Peak Concurrent Workload | CPU Starting Point | RAM Starting Point | Storage |
|---|---|---|---|
| Up to 10 active users | 2–4 vCPU | 8 GB | SSD |
| 10–30 active users | 4–8 vCPU | 16 GB | SSD or NVMe |
| 30–60 active users | 8 vCPU | 16–32 GB | NVMe |
| 60–120 active users | 8–16 vCPU | 32–64 GB | High-performance NVMe |
| 120+ heavy concurrent users | 16+ vCPU or scaled architecture | 64 GB+ | Enterprise NVMe |
These estimates should be increased for high-volume manufacturing, large accounting databases, heavy custom reporting, busy eCommerce traffic or intensive integrations. A 200-user professional-services company may require fewer resources than a 70-user manufacturing company running complex MRP and inventory activity all day.
Storage and PostgreSQL Matter as Much as CPU
Disk capacity is only one part of storage sizing. PostgreSQL performance depends heavily on latency and IOPS, especially when the active dataset no longer fits comfortably in memory. Slow storage can make searches, reports and large transactions feel sluggish even when CPU utilization remains low.
SSD should be considered the minimum standard for production Odoo while NVMe is preferable for enterprise databases with significant read and write activity. Storage planning should include the PostgreSQL database, Odoo filestore, attachments, logs, temporary files, backups and expected future growth.
Odoo 19 requires PostgreSQL 13 or later. Smaller deployments often run Odoo and PostgreSQL on the same server while larger environments may evaluate a dedicated database server when application workers and database processes are competing heavily for CPU or memory.
Odoo Online: When Hardware Sizing Is Abstracted
Odoo Online removes most infrastructure sizing decisions from the customer. The business does not select physical cores, configure PostgreSQL memory or decide how many operating-system processes should run. Odoo manages the hosting environment while the customer focuses on application configuration and business usage.
This model is attractive for companies that can use standard Odoo because it reduces infrastructure administration. It is less suitable when the business depends on custom Python modules, third-party Apps Store modules or deeper server-level control because those are outside the Odoo Online deployment model.
Even in a managed cloud environment, application design still matters. Large reports, unnecessary automations and poor data structure can create performance complaints even though the underlying infrastructure is managed.
Odoo.sh: Scale Capacity Without Managing the Full Server
Odoo.sh is often the preferred middle ground for businesses that require custom modules but do not want to manage Linux and PostgreSQL directly. The platform provides GitHub integration, production and staging builds, logs, continuous integration and managed backups.
For enterprise sizing, the important concept is worker capacity. Adding workers can increase the number of concurrent requests the environment can handle but it does not automatically make a slow custom method or inefficient query faster.
If one report takes 30 seconds because of poor code, more workers may allow more users to run it simultaneously while the report itself remains slow. Odoo.sh should therefore be sized together with code profiling, storage growth analysis and scheduled-job review.
On-Premise: Maximum Control Requires Strong Administration
On-premise Odoo allows infrastructure teams to choose bare-metal servers, virtual machines or private-cloud resources and tune each layer according to internal requirements. Organizations can control worker counts, PostgreSQL settings, storage architecture, reverse proxies, monitoring and backup systems.
This model is valuable for companies with strict data-location policies, private network integrations or specialized security requirements. It also places responsibility for Linux updates, PostgreSQL maintenance, SSL, backups, monitoring and recovery on the organization.
Odoo's current installation guidance discourages Windows for normal production deployment because the Windows packaging is mainly intended for testing or single-user local environments. Linux should therefore be the normal starting point for enterprise self-hosted Odoo.
Manufacturing Workloads Need More Headroom
Manufacturing environments often create heavier workloads through MRP calculations, multi-level Bills of Materials, procurement rules, work orders and large stock movements. Several departments may also be updating the same operational data simultaneously.
Capacity should be evaluated during realistic production peaks. A server that performs well with office users may struggle when planners run replenishment, warehouse teams validate transfers and production staff update work orders at the same time.
Manufacturing organizations should pay particular attention to CPU headroom, PostgreSQL query performance, storage latency and scheduled jobs. Complex custom manufacturing logic should also be profiled because inefficient computed fields can affect thousands of records.
Accounting and Reporting Create Different Server Pressure
Finance teams often create a database-heavy workload rather than a large concurrent-user workload. General Ledger reports, aged receivables, reconciliation, tax reporting and large spreadsheet exports can place substantial pressure on PostgreSQL even when only a few accountants are active.
Month-end and year-end should therefore be treated as peak workload periods. Infrastructure that performs well during daily invoice entry may become noticeably slower when several large financial reports and reconciliation processes run together.
Adequate RAM, fast storage and optimized database queries become especially important for long-lived Odoo databases containing many years of accounting transactions.
eCommerce, POS and API Traffic Also Count
Internal users are not the only source of requests. A busy eCommerce site may receive hundreds of visitor requests while relatively few employees are logged into the backend. POS terminals can remain active throughout the day and API integrations may continuously create or update records.
Server capacity should therefore include both human and machine-generated activity. Integrations with logistics providers, marketplaces, CRMs and payment systems can create continuous background traffic that is invisible when administrators only count employees.
Rate limits, queues and scheduled synchronization can help control integration workloads. Poorly designed connectors that repeatedly query the same records or process everything one record at a time can create unnecessary pressure on an otherwise capable server.
Custom Modules Can Be a Bigger Problem Than Hardware
Enterprise Odoo performance issues are often blamed on server specifications first. In reality, poorly designed custom code can make powerful infrastructure behave like an underpowered system.
Common technical problems include repeated ORM searches inside loops, excessive computed fields, non-stored calculations across large datasets, unnecessary external API calls and reports that load very large recordsets into memory.
Odoo provides profiling guidance for analyzing SQL-heavy operations and other performance bottlenecks. Hardware should therefore be increased only after administrators understand whether the real limitation is CPU, memory, storage, PostgreSQL or custom application logic.
Backups and Disaster Recovery Affect Capacity
Enterprise server sizing should include backup and recovery requirements. A production server may handle daily transactions correctly but still fail operational expectations if database backups take too long or restoration cannot meet the required recovery time.
Odoo.sh includes automated backup capabilities as part of its managed platform. For on-premise installations the organization must define database backups, filestore backups, retention periods, off-site copies and restoration testing.
Backup activity also consumes storage and I/O. Large installations should schedule heavy backup tasks carefully so they do not compete with production workloads during peak business hours.
Monitor Before You Scale
Infrastructure scaling should be based on measurements rather than assumptions. A slow Odoo system does not automatically mean the server needs more CPU.
Administrators should regularly monitor:
CPU utilization and load averages.
Memory usage and swap activity.
Disk latency and IOPS.
PostgreSQL slow queries.
Worker saturation.
Cron execution time.
Integration queues.
Database and filestore growth.
HTTP response times.
Backup duration and restore readiness.
If CPU is consistently high, more processing capacity may be justified. If CPU is low but reports are slow, PostgreSQL, storage or application logic should be investigated first. BrowseInfo's current performance guidance similarly recommends reviewing infrastructure, PostgreSQL and custom modules together rather than relying only on hardware upgrades.
Choosing the Right Hosting Model
The right option depends on how much customization, infrastructure control and operational responsibility the organization is prepared to manage. Odoo Online fits standard deployments that want minimal infrastructure administration while Odoo.sh suits customized environments that benefit from managed development and staging.
On-premise is strongest when infrastructure control itself is a business requirement. Before deciding, enterprises should review custom-module requirements, peak concurrency, database growth, integration volume, backup objectives, security policies, internal DevOps capability and expected growth over the next three to five years.
How BrowseInfo Can Help With Odoo Infrastructure Planning
BrowseInfo's current Odoo performance guidance emphasizes evaluating CPU, memory, PostgreSQL, storage, worker configuration, custom modules and scheduled workloads together rather than assuming a larger server will solve every performance issue.
For Odoo.sh or self-hosted deployments, infrastructure planning can include worker sizing, PostgreSQL review, SSD or NVMe storage, custom-code profiling, database-growth analysis and monitoring.
The objective is to match infrastructure with the real enterprise workload while leaving enough capacity for future expansion instead of repeatedly redesigning the server whenever transaction volume increases.
Common Odoo Server Sizing Mistakes
Several mistakes repeatedly create performance problems:
Sizing by total employees instead of concurrent users.
Adding workers without checking available CPU and RAM.
Using slow storage for PostgreSQL.
Ignoring cron jobs and API integrations.
Treating eCommerce visitors as zero server load.
Increasing hardware before profiling custom code.
Planning storage only for the current database size.
Skipping backup restoration and peak-load testing.
A balanced deployment scales the resource that is actually limiting performance instead of upgrading every component blindly.
Frequently Asked Questions
1. What is the main difference between Odoo Online, Odoo.sh and on-premise?
Odoo Online is fully managed and does not support custom modules. Odoo.sh supports custom development on a managed platform while on-premise provides full infrastructure control.
2. How many Odoo workers are needed?
Odoo's rule of thumb is approximately one worker for six concurrent users. CPU capacity, memory and cron workers must also be considered before setting the final number.
3. How much RAM does an enterprise Odoo server need?
There is no fixed amount. Concurrent workload, worker count, PostgreSQL activity, reporting and custom modules determine the real requirement.
4. Is Odoo.sh faster than on-premise?
Not automatically. Performance depends on capacity, PostgreSQL workload and code quality rather than the hosting label alone.
5. Is NVMe required for Odoo?
It is not mandatory but it is highly useful for enterprise PostgreSQL workloads where low storage latency and high IOPS matter.
6. Should PostgreSQL use a separate server?
Only when workload or operational requirements justify it. Many moderate deployments perform well with Odoo and PostgreSQL on the same properly sized server.
7. Can more workers fix slow custom code?
No. More workers improve concurrent request capacity while inefficient queries and custom logic still require profiling and optimization.
8. Which option is best for heavily customized Odoo?
Odoo.sh or self-hosted Odoo are usually the practical choices because both support custom modules. The decision depends on how much infrastructure control the business wants.
Conclusion
Odoo server sizing is a workload-engineering problem rather than a simple user-count calculation. CPU, RAM, PostgreSQL, workers, storage and custom application design must be balanced around the busiest real business periods.
Odoo Online removes most hardware responsibility while Odoo.sh provides managed capacity for customized deployments. On-premise provides maximum control but also requires the strongest operational discipline around Linux, PostgreSQL, monitoring, backups and security.
For self-hosted environments, strong CPU with too little memory can still perform badly while large RAM cannot compensate for slow storage or inefficient SQL. Every infrastructure layer needs to support the same expected workload.
The most reliable strategy is to start with realistic capacity estimates, test representative workloads and monitor production continuously. Infrastructure should be increased when measurements show a real bottleneck while custom code and database queries should be optimized when hardware is not the limiting factor.
A well-sized enterprise Odoo environment is not the server with the largest specification. It is the environment where hosting model, database performance, worker capacity, CPU, RAM and storage are matched to actual business demand with enough headroom for future growth.
