ERP Server Sizing Calculator

1. Understand Concurrent vs. Named Users

The single most important factor in server sizing is concurrent users — not total named users. If you have 100 employees with ERP access, typically only 15-25 will be logged in and actively using the system at any given time during business hours. This ratio varies by industry: manufacturing floors with terminal access may see 40% concurrency, while professional services firms with mixed tool usage average 15%.

Start by analyzing your current system's login patterns. Most ERP systems provide session analytics or you can check your web server access logs. If this is a new deployment, use 20% as a safe starting point and monitor actual usage during the first month.

2. Calculate RAM Requirements

RAM is the primary bottleneck for ERP systems. The formula is: base application RAM + base database RAM + (concurrent users x RAM per user x module weight). For Odoo, the base is roughly 2GB for the application and 1GB for PostgreSQL, with ~150MB per concurrent user. SAP S/4HANA, by contrast, runs the HANA database entirely in-memory, requiring 64GB minimum even for small deployments.

Module complexity matters significantly. A CRM-only deployment uses roughly half the per-user RAM compared to a full-suite deployment with manufacturing, quality, and planning modules. This is because complex modules load more data into memory, run more background schedulers, and maintain larger query caches.

Always provision 20-30% headroom above calculated requirements. Memory pressure causes swapping, which can make an ERP system feel 10-100x slower than normal. It's the single most common performance issue we see in client deployments.

3. CPU Cores: Quality Over Quantity

ERP workloads are a mix of short web request processing and longer-running background jobs (report generation, email queues, scheduled actions). For the web tier, each concurrent user generates approximately 0.1-0.2 CPU cores of sustained load during active use, with spikes during complex operations.

Most ERP systems benefit more from faster cores than more cores. A 4-core machine with high single-thread performance will outperform an 8-core machine with slower cores for typical ERP workloads. This is because web requests are processed sequentially per-user, and database queries benefit from fast single-core speed.

Exception: if you run heavy reports, batch processing, or many integrations, additional cores help by parallelizing these background tasks. Our calculator adds 25% CPU overhead for report-heavy workloads.

4. Storage: Plan for Growth

Storage requirements depend on three factors: database size, attachment volume, and retention period. A typical ERP database grows 1-5GB per year per 10 active users, depending on transaction volume. Attachments (invoices, purchase orders, product images, quality documents) can dwarf the database size.

Always use SSDs for ERP databases. The random I/O pattern of database queries makes HDD performance unacceptable. NVMe SSDs are recommended for dedicated database servers with 50+ users. For storage-intensive workloads (document management, manufacturing quality photos), consider separate object storage (S3, Azure Blob) to keep the primary disk lean.

Plan storage for your growth projection (3-5 years). It's much easier to provision adequate storage upfront than to perform a live disk expansion or migration under pressure.

5. When to Split: App, Database, and Cache Servers

For small deployments (under 30 concurrent users), a single server running both the application and database is perfectly fine. It's simpler to manage, cheaper, and has no network latency between components.

At 30-50 concurrent users, add a Redis cache server. Caching sessions, configuration, and repeated queries can reduce database load by 40-60%. Redis needs only 1-2GB RAM for most ERP deployments.

At 50+ concurrent users, move the database to a dedicated server. This allows independent scaling (add RAM to the DB without touching the app server), eliminates CPU contention between web workers and database queries, and simplifies backup strategies. At this scale, the database is usually the bottleneck, and giving it dedicated resources makes the biggest performance difference.

At 100+ concurrent users, consider multiple application servers behind a load balancer (Nginx, HAProxy). This provides both horizontal scaling and high availability — if one app server goes down, others continue serving requests.