Server Sizing for ERP: How to Get It Right

Server sizing for ERP is one of those decisions that feels technical but has significant business consequences. Under-size your server and you get performance complaints from day one — slow page loads, timeouts during peak usage, and database deadlocks under concurrent load. Over-size it and you spend significantly more than necessary on infrastructure that sits mostly idle.

Most ERP implementations get server sizing wrong in one of two directions: over-confident IT teams that size based on "it's just a web app" intuition without accounting for ERP's database intensity, or vendor recommendations that are calibrated for maximum performance at any cost rather than appropriate performance at reasonable cost.

This guide gives you a structured approach to server sizing for ERP deployments: the key variables that drive resource requirements, the specific sizing guidelines for major ERP platforms at different user counts, and how to use ECOSIRE's free Server Sizing Calculator to model your specific situation.

Key Takeaways

• ERP is significantly more database-intensive than typical web applications — standard web server sizing rules do not apply
• CPU is rarely the constraint; RAM and disk I/O are almost always the bottleneck in ERP workloads
• Odoo requires 2–4 GB RAM per concurrent worker process; at least 16 GB for production instances with 50+ users
• Database storage IOPS requirements are dramatically underestimated in most server sizing exercises
• Cloud instances that look equivalent on paper (same vCPU, same RAM) can have vastly different I/O performance
• Always size for peak concurrent load (not average load) with 30–40% headroom
• Use ECOSIRE's free Server Sizing Calculator to generate a specification for your specific user count and ERP platform

---

Why ERP Server Sizing Is Different

Before diving into specific recommendations, it is worth understanding why ERP server sizing requires more careful analysis than sizing for a typical web application.

Database intensity: ERP systems are fundamentally transaction-processing systems. Every user action — creating a purchase order, posting an invoice, moving inventory — generates multiple database writes that must be committed atomically. The database layer handles complex relational queries across large, normalized schemas, often with multiple table joins and aggregate calculations. This is very different from a content management system or a marketing website, which might read from a few denormalized tables per page view.

Concurrent user load patterns: ERP user behavior is more concurrent than typical web applications. In a consumer website, users browse independently with infrequent interactions. In an ERP system, multiple users in the same department may simultaneously process orders during peak hours (month-end, end-of-day, shift close). This concurrent write pattern creates database lock contention that a typical web application never encounters.

Report generation workload: ERP reports — particularly financial reports, inventory aging, and demand forecasting — execute complex, multi-table queries that can run for 30–120 seconds and consume significant CPU and I/O during execution. When three finance staff members all run the month-end close reports simultaneously, the resulting load spike can be severe.

Session state and worker processes: Odoo specifically runs Python worker processes that maintain session state for each active user connection. Each worker process consumes approximately 200–400 MB of RAM at steady state and up to 1 GB during heavy report execution. The server needs enough RAM to run all active workers simultaneously without swapping to disk — swapping in an ERP database server causes catastrophic performance degradation.

---

Key Variables in ERP Server Sizing

Four variables drive ERP server resource requirements more than any others:

1. Concurrent user count (not total user count)

Total user count is a poor predictor of resource requirements. The right metric is peak concurrent users: the number of users who are actively making requests to the system at the same time during the busiest period of the day.

Estimating peak concurrent users from total user count:

• Office-based ERP with normal business hours: 15–25% of total users are concurrent at peak
• Manufacturing with multiple shifts: 25–35% of total users concurrent (shift-change peaks)
• Distributed operations across time zones: lower peak concurrency but longer peak duration
• Finance-heavy usage during month-end: temporary spike to 40–50% concurrent during close periods

For a 100-user Odoo deployment with normal office-based usage, plan for 15–25 concurrent users at typical peak, with provision for 40–50 concurrent during month-end. This should drive your sizing calculation, not the total of 100 users.

2. Transaction volume and transaction complexity

High transaction volumes drive database write load independently of concurrent users. A distribution company that processes 2,000 purchase orders per day generates significantly more database write I/O than a professional services firm with 100 users but low transaction volume. Similarly, complex transactions (manufacturing work orders that update BOM consumption, inventory, cost accounting, and quality records simultaneously) generate more I/O than simple transactions (a journal entry posting that updates two G/L accounts).

Estimate your transaction complexity by thinking about the modules in use: manufacturing and multi-warehouse inventory generate the most complex transactions; simple accounting and HR modules generate the simplest.

3. Database size and growth rate

Database size affects query performance in two ways: directly (larger tables take longer to scan) and indirectly (working sets that exceed available RAM lead to cache misses and increased I/O).

ERP databases grow faster than most IT teams expect. A starting database of 20 GB can reach 100 GB in two to three years with normal growth from transaction history, document attachments, and audit logs. Size your storage for three years of expected growth, not just current needs.

4. Integration and API workload

If your ERP connects to external systems via API (eCommerce platform, 3PL system, bank APIs, marketplace connectors), these integrations generate additional server load that is not reflected in user counts. Each API call goes through the ERP's application layer and database — a high-volume integration (processing 1,000 order sync requests per hour) can match the load of 10–20 concurrent users.

---

Sizing Guidelines by Platform and User Count

Odoo 19 Enterprise

Odoo's architecture uses worker processes (Odoo workers) that each serve user requests. The number of workers and the server resources required scale with concurrent user count.

Odoo worker calculation:

• Recommended workers = (concurrent users / 6) + 1, rounded up
• Each worker requires approximately 300–500 MB RAM at steady state, up to 1 GB during heavy reports
• Cron workers (for background processes) add 2–4 additional workers

Minimum recommended specifications by user count:

Important notes on Odoo sizing:

• The database (PostgreSQL) and the application (Odoo worker processes) ideally run on separate servers above 100 users. Combined on a single server, the database and application compete for RAM.
• PostgreSQL shared memory (effective_cache_size) should be set to 50–75% of database server RAM.
• SSD storage is mandatory for the PostgreSQL data directory — spinning disk causes catastrophic performance on any ERP database.
• A separate Redis server for Odoo session storage is recommended for deployments above 50 users.

Microsoft Dynamics 365 Business Central

Business Central is cloud-hosted on Microsoft Azure infrastructure when using the SaaS deployment model — in this case, server sizing is managed by Microsoft. For on-premises deployments:

Business Central on-premises uses SQL Server as the database, which has a separate memory management model from PostgreSQL. Allocate dedicated RAM to SQL Server's buffer pool (via max server memory setting) — approximately 75% of database server RAM.

SAP Business One

SAP Business One is deployed on-premises (Windows or HANA) or on SAP Business One Cloud:

SAP HANA (the in-memory database used with SAP Business One HANA edition) has much higher RAM requirements than traditional disk-based databases because the working set must fit in memory. The RAM requirements for HANA are non-negotiable — HANA that runs out of memory crashes, not degrades.

---

Cloud Instance Recommendations

When self-hosting ERP on AWS, Azure, or GCP, selecting the right instance type matters significantly. Not all instances with the same vCPU and RAM counts perform equivalently for database workloads.

AWS recommendations for Odoo (combined app+db, under 100 users):

• t3.xlarge (4 vCPU, 16 GB): Development and small production (under 25 users)
• r6i.xlarge (4 vCPU, 32 GB): Small-medium production (25–50 users)
• r6i.2xlarge (8 vCPU, 64 GB): Medium production (50–100 users)
• r6i.4xlarge (16 vCPU, 128 GB): Large production (100–200 users, combined)

AWS recommendations for Odoo (split app/db, 100+ users):

• Application server: c6i.2xlarge (8 vCPU, 16 GB) — compute-optimized
• Database server: r6i.4xlarge (16 vCPU, 128 GB) — memory-optimized
• Database storage: io2 EBS volumes (provisioned IOPS) — 3,000–6,000 IOPS provisioned

Azure equivalents:

• Application server: Standard_F8s_v2 (8 vCPU, 16 GB)
• Database server: Standard_E16s_v5 (16 vCPU, 128 GB)

GCP equivalents:

• Application server: c2-standard-8 (8 vCPU, 32 GB)
• Database server: n2-highmem-16 (16 vCPU, 128 GB)

The I/O performance trap: Standard EBS gp3 volumes on AWS provide 3,000 IOPS by default. For a production ERP database with 50+ concurrent users, this is often insufficient — particularly during month-end close when multiple complex reports run simultaneously. Use io2 provisioned IOPS volumes for the database storage, with a minimum of 3,000 IOPS provisioned. The cost difference is significant ($0.065/GB/month for gp3 vs $0.125/GB/month for io2 plus $0.065/IOPS/month for provisioned IOPS), but the performance difference is also significant.

---

High Availability Architecture

For production ERP systems where downtime has significant business impact, consider a high-availability architecture that provides resilience against single-server failures.

Minimum HA architecture for Odoo (100+ users):

• Two application servers behind a load balancer (round-robin or sticky sessions)
• PostgreSQL primary database with a standby replica (using streaming replication or AWS RDS Multi-AZ)
• Redis cluster (two nodes) for session storage
• Shared file storage (AWS EFS or equivalent) for Odoo's file attachment data

This architecture provides resilience against any single server failure without requiring manual intervention. Failover from the primary PostgreSQL to the standby is automatic (using Patroni or AWS RDS) and typically completes in 30–60 seconds.

RPO and RTO targets for typical ERP:

• Recovery Point Objective (maximum data loss): 5 minutes (with synchronous replication) to 30 minutes (with async replication)
• Recovery Time Objective (maximum downtime): 30–60 seconds for automatic failover, 15–30 minutes for manual recovery

---

Using the ECOSIRE Server Sizing Calculator

ECOSIRE's free Server Sizing Calculator at /tools/server-sizing-calculator automates the calculation process described above. Inputs:

1. ERP platform selection
2. Total user count
3. Peak concurrent user percentage (or automatic estimate based on use case)
4. Transaction volume (low, medium, high, very high)
5. Integration count and volume (none, basic, moderate, intensive)
6. Availability requirements (single server, HA, disaster recovery)
7. Cloud provider preference (AWS, Azure, GCP, or on-premises)

Outputs:

• Recommended server specifications for application and database tiers
• Specific cloud instance recommendations for your preferred provider
• Monthly infrastructure cost estimate
• Three-year growth projection showing when you will need to upgrade
• Storage IOPS requirements and recommended storage tier

The calculator is calibrated against ECOSIRE's own production deployment data across dozens of client implementations, making the estimates more reliable than vendor documentation alone.

---

Frequently Asked Questions

How do I estimate peak concurrent users if we have never used ERP before?

For greenfield implementations with no historical data, use 20% of total users as a starting estimate for a normal office-based deployment. If you have multiple shifts or work across multiple time zones, use 25–30%. Then add 50% headroom for growth over the first two years. For a 100-user ERP with normal office hours, plan for 20 concurrent users at typical peak, provision for 30, and build in capacity to reach 40 without infrastructure changes. This headroom approach avoids performance problems as adoption improves in the months after go-live.

Should we run the Odoo application and database on the same server or separate servers?

For deployments under 50 users, a single combined server is usually fine — the application and database workloads at that scale do not typically conflict. For 50–100 users, the decision depends on usage patterns: if the user base is evenly distributed throughout the day with no significant peak periods, a combined server may still work. If there are sharp peaks (month-end, shift-close), separate application and database servers provide better isolation. Above 100 users, separate servers are strongly recommended.

What storage type should we use for the Odoo database?

SSD storage is mandatory for the PostgreSQL data directory — spinning disk (HDD) produces unacceptable performance on any production ERP database. On cloud platforms, use provisioned IOPS SSD (AWS io2, Azure Premium SSD v2, GCP Extreme Persistent Disk) for the database storage if you have more than 50 concurrent users. General-purpose SSD (AWS gp3, Azure Standard SSD) is acceptable for development and small production deployments under 25 concurrent users.

How much headroom should we build into our server sizing?

Build in 30–40% headroom above your expected peak load for normal operations, and 100% headroom (effectively double the peak capacity) for exceptional periods like month-end close or peak sales seasons. Cloud deployments can use auto-scaling to handle exceptional periods without paying for that capacity permanently — a significant cost advantage over fixed on-premises infrastructure.

---

Next Steps

Use ECOSIRE's free Server Sizing Calculator at /tools/server-sizing-calculator to generate a specification for your specific deployment. The calculator outputs an AWS/Azure/GCP instance recommendation and a monthly infrastructure cost estimate that you can use for budget planning.

If you are planning an Odoo implementation and want ECOSIRE to handle infrastructure sizing and setup alongside the implementation, the infrastructure planning is included in every ECOSIRE implementation engagement.