Hosting Odoo in Saudi Arabia: The Right Specs for Every Company Size
The right Odoo spec follows one rule: workers = (CPU cores × 2) + 1, with about 150 MB of RAM per worker. Here is the matching plan for 10, 25, and 50 concurrent users on a Saudi server with 8ms latency.
The right Odoo hosting spec is calculated, not guessed. The practical rule is that the number of parallel worker processes equals (CPU cores × 2) + 1, so a four-core server gives you nine workers, and each worker needs about 150 MB of RAM in normal use rising to 250 MB during heavy reports. On average one worker serves six to eight real concurrent user sessions, because a user does not fire a request every second, they read and write in gaps. Based on this, a company with ten concurrent users fits the Growth plan (2vCPU/4GB), twenty-five users need the Business plan (4vCPU/8GB) with extra RAM, and fifty concurrent users start from the Enterprise plan (8vCPU/16GB) with a well-tuned PostgreSQL database. Hosting inside Saudi Arabia delivers about 8ms latency from Riyadh instead of 80 to 120ms from European servers, a noticeable difference in a system where dozens of screens open daily. On top of that, Saudi e-invoicing and ZATCA requirements make keeping financial data on Saudi soil a practical decision rather than a luxury.
Why Odoo Is Popular in the Saudi Market
Odoo is an open-source enterprise resource planning system that combines accounting, sales, inventory, HR, and point of sale in one platform, which suits the mid-sized Saudi company that does not want to buy five separate systems. The community edition is free of license fees, so you pay only for the server and management with no monthly per-user charge, and that alone saves thousands of riyals a year compared with closed subscription clouds. More importantly, hosting it on your own cloud server gives you full control over installed modules, backup scheduling, and integration with e-invoicing and local payment platforms through direct APIs.
Companies running Odoo usually have a developer or technical partner managing custom modules, and that is exactly the Cloud audience: companies with custom systems that need a stable Saudi infrastructure, not cheap WordPress hosting. The difference between running Odoo on a tuned server versus a random one shows at month end during accounting close, when consolidated reports and journal entries load all at once.
How to Calculate Resources by the Numbers
Start from your real concurrent user count, not the total headcount. A company with forty employees might peak at just twelve concurrent users. After estimating the concurrent load, apply these steps:
- Worker count = (CPU cores × 2) + 1. Example: 4 cores give 9 workers.
- Worker RAM = worker count × 200 MB as a safe average that covers heavy requests.
- PostgreSQL RAM = allocate 25% to 30% of total RAM to the database via shared_buffers.
- OS and services RAM = reserve about 1 GB as a safety margin.
The golden rule: one worker serves six to eight active sessions. If you have twenty concurrent users, you need three to four active workers, which translates to a four-core server giving nine workers with comfortable headroom for close-period reports. Do not forget to dedicate one worker to scheduled cron jobs separate from request workers, because a heavy scheduled task can freeze the interface if it shares the same resource.
The Right Plan for Every Company Size
The table below maps concurrent users directly to Cloud plans, with the add-ons we recommend from the Cloud Server page:
| Size | Concurrent users | Base plan | Workers | Suggested add-ons | Approx. annual cost |
|---|---|---|---|---|---|
| Small | Up to 10 | Growth 2vCPU/4GB | 5 | +2GB RAM (600 SAR) for close-period safety | About 7,500 SAR |
| Medium | Up to 25 | Business 4vCPU/8GB | 9 | +2GB RAM (600) + daily backup 30-day (2,000) | About 14,100 SAR |
| Large | Up to 50 | Enterprise 8vCPU/16GB | 17 | +100GB SSD (500) + daily backup 30-day (2,000) | About 20,500 SAR |
These figures are based on Cloud annual pricing including 15% VAT. Growth starts at 6,900 SAR, Business at 11,500, and Enterprise at 18,000, with the server activating automatically within seconds after payment via Virtualizor. For full pricing see the pricing and plans page.
Why We Raise RAM Before Cores
Odoo consumes memory more than CPU under most loads, because accounting reports load large datasets into memory. That is why we add RAM before considering extra cores, and our add-on is +2GB RAM at 600 SAR per year and +1 vCPU at 500 SAR, so you expand only the resource you actually need instead of buying a whole larger plan.
Baseline PostgreSQL Tuning
The database is the heart of Odoo performance, and simple tuning makes a large difference. On an eight-gigabyte server, start with these values as a launch point then monitor and adjust:
- shared_buffers = 2GB (about 25% of RAM).
- effective_cache_size = 5GB (about 60% of RAM).
- work_mem = 16 to 32 MB per sort operation.
- maintenance_work_mem = 512 MB for indexing and maintenance.
- max_connections = set it close to your worker count plus a margin, and do not raise it blindly because each connection consumes memory.
Run a scheduled VACUUM ANALYZE at least weekly so query plans stay accurate, and add indexes on fields you search often in invoices and sales orders. As the database grows past twenty gigabytes, fast SSD space matters more than core count, and our add-on is +100GB SSD at 500 SAR per year.
E-Invoicing and Local Sovereignty
An Odoo system hosted inside Saudi Arabia integrates with ZATCA e-invoicing through its APIs, and keeping financial data on a Saudi server simplifies any audit and protects the confidentiality of your numbers. About 8ms latency from Riyadh means every invoicing API call returns quickly, and high uptime ensures your system works when invoices are issued rather than when the server rests. Daily, weekly, and monthly backups protect you from any human error or failed update before the monthly close.
When to Scale: Load Signals by the Numbers
Do not wait for user complaints to learn the server is full, watch four numeric signals that tell you when to add a resource. The first signal is CPU usage: if it stays above 80% for more than ten minutes at peak repeatedly, you need more cores or workers. The second is RAM usage: if the OS starts using disk swap, performance collapses immediately because disk is hundreds of times slower than RAM, and this is an urgent RAM-raise signal. The third is page response time: if opening an ordinary screen consistently exceeds two seconds, look for the cause in the database or the workers. The fourth is request queue length: if users start waiting their turn because all workers are busy, you have hit the real capacity limit.
The practical rule is to add the resource that hit its limit first, not to upgrade the whole plan. If RAM is the bottleneck, add +2GB at 600 SAR, if CPU, add +1 vCPU at 500 SAR, and if disk fills as the database grows, add +100GB SSD at 500 SAR. This partial scaling is far cheaper than jumping to a whole larger plan, and activation is instant by paying only the difference through the control panel. Watch these indicators weekly in the first months after launch, because the growth curve differs from one company to another based on how the team expands.
Practical Steps to Start
Begin by counting your concurrent users at peak, not your total staff, then pick the plan from the table above. If you fall between two sizes, choose the smaller and add RAM when needed, because scaling with us is instant by paying the difference. Enable daily backup with 30-day retention before your first monthly close, and tune PostgreSQL with the values above. For larger systems or government integration, start from the Cloud Server page and request a technical guidance meeting for your developer, because Cloud does not migrate your system but supports your team on tuning and integration. The bottom line: calculate, pick Growth or Business or Enterprise by concurrency, and raise RAM before cores.
