# ERP Server Sizing Calculator for On-Premise and Private Cloud

> Source: https://netray.co/tools/erp-server-sizing-calculator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Rough-size application and database servers for an ERP from named users, concurrency, database size and growth, with headroom.

## Category

erp-operations

## Audience

- IT manager
- ERP administrator
- Infrastructure engineer

## Tool

**Kind:** calculator

**Inputs:**

#### Named users

**Key:** users

**Type:** number

**Default:** 250

**Min:** 1

**Step:** 10

**Unit:** users

**Help:** Total licensed or active ERP users.

#### Peak concurrency

**Key:** conc_pct

**Type:** slider

**Default:** 40

**Min:** 5

**Max:** 100

**Step:** 5

**Unit:** %

**Help:** Share of named users active at the busiest hour. Office ERP is often 30 to 50%, shop floor terminals can be higher.

#### Concurrent users per application core

**Key:** users_per_core

**Type:** number

**Default:** 12

**Min:** 1

**Step:** 1

**Unit:** users

**Help:** Take this from your ERP vendor sizing guide or from measured load. Heavy reporting lowers it.

#### Concurrent users per database core

**Key:** users_per_db_core

**Type:** number

**Default:** 30

**Min:** 1

**Step:** 1

**Unit:** users

**Help:** Database CPU demand depends on queries and batch jobs. Use vendor guidance or measurement.

#### Application RAM per concurrent user

**Key:** ram_per_user

**Type:** number

**Default:** 0.5

**Min:** 0.1

**Step:** 0.1

**Unit:** GB

**Help:** Session and process memory per active user.

#### Base OS and services RAM

**Key:** base_ram

**Type:** number

**Default:** 8

**Min:** 2

**Step:** 1

**Unit:** GB

**Help:** Operating system, agents and ERP services that run regardless of load.

#### Current database size

**Key:** db_gb

**Type:** number

**Default:** 400

**Min:** 1

**Step:** 10

**Unit:** GB

#### Annual database growth

**Key:** growth

**Type:** number

**Default:** 20

**Min:** 0

**Step:** 1

**Unit:** %

#### Planning horizon

**Key:** years

**Type:** slider

**Default:** 3

**Min:** 1

**Max:** 7

**Step:** 1

**Unit:** years

#### Database memory as share of data

**Key:** buffer_pct

**Type:** number

**Default:** 20

**Min:** 5

**Step:** 1

**Unit:** %

**Help:** How much of the database you want cached in RAM. 10 to 30% is a common range for transactional ERP.

#### Storage multiplier

**Key:** overhead

**Type:** number

**Default:** 3

**Min:** 1

**Step:** 0.5

**Unit:** x

**Help:** Covers transaction logs, tempdb, indexes and local backup staging on top of data size.

#### Headroom

**Key:** headroom

**Type:** slider

**Default:** 30

**Min:** 0

**Max:** 100

**Step:** 5

**Unit:** %

**Outputs:**

#### Peak concurrent users

**Key:** conc

**Expr:** users * conc_pct / 100

**Format:** integer

#### Application server cores

**Key:** app_cores

**Expr:** ceil(conc / users_per_core * (1 + headroom / 100))

**Format:** integer

**Primary:** true

**Description:** Total across all application servers, before splitting for redundancy.

#### Application server RAM (GB)

**Key:** app_ram

**Expr:** ceil((conc * ram_per_user + base_ram) * (1 + headroom / 100))

**Format:** integer

**Description:** Total across all application servers.

#### Database size at horizon (GB)

**Key:** db_future

**Expr:** db_gb * pow(1 + growth / 100, years)

**Format:** integer

#### Database server cores

**Key:** db_cores

**Expr:** max(4, ceil(conc / users_per_db_core * (1 + headroom / 100)))

**Format:** integer

**Primary:** true

**Description:** Floor of 4 cores. Check licensing rules, since database cores may drive license cost.

#### Database server RAM (GB)

**Key:** db_ram

**Expr:** max(32, ceil(db_future * buffer_pct / 100 * (1 + headroom / 100)))

**Format:** integer

**Description:** Floor of 32 GB.

#### Database storage needed (TB)

**Key:** storage_tb

**Expr:** db_future * overhead / 1000

**Format:** decimal

**Chart:**

#### Cores needed vs named users

**Type:** line

**X:** users

**From:** 50

**To:** 2000

**Steps:** 20

**Series:**

- app_cores
- db_cores

**Disclaimer:** This is a planning estimate based on ratios you supply. Always validate against the ERP vendor's sizing guide and a load test before buying hardware or committing to licenses.

## Content

**Intro:** Sizing an ERP server is an exercise in ratios: how many people use it at once, how much CPU and memory each session needs, how large the database will become and how much headroom you want. This calculator makes those assumptions explicit so you can discuss them with the ERP vendor and your infrastructure team.

**Sections:**

#### How to use the calculator

**Body:** Start with named users and your realistic peak concurrency. Replace the default users-per-core figures with numbers from your ERP vendor's sizing guide or from monitoring on the current system. If you are migrating, use the current peak CPU and memory, not the average. Then set database size, annual growth and a planning horizon of three to five years. Headroom covers month-end close, payroll runs and MRP. Export the result as the first page of an infrastructure request.

**Bullets:**

- Use measured peaks from the existing system when you have them
- Size month-end, not a quiet Tuesday
- Keep the assumptions with the result so they can be challenged

#### The method behind the numbers

**Body:** Application cores equal peak concurrent users divided by users per core, multiplied by one plus headroom. Memory is concurrent users times memory per session plus a fixed base. Database size grows compound: current size times one plus the growth rate, raised to the number of years. Database memory is a fraction of data size to keep hot pages cached, with a floor of 32 GB. Storage multiplies data size to allow for logs, temporary space, indexes and local backup staging. These are rules of thumb, not vendor formulas.

#### Reading the result

**Body:** The application figure is a total for the tier. Split it across at least two servers or virtual machines if you need resilience, and remember that a single failed node must not push the survivors past their limit. The database figures usually go to a primary and a standby. If the calculator shows a very large database core count, check licensing first, since database cores often drive software cost more than hardware. The chart shows how quickly cores grow with users, which helps when you plan for acquisitions or new plants.

#### Common mistakes

**Body:** Sizing on named users instead of concurrency inflates cost. Sizing on average load misses month-end spikes. Forgetting reporting, BI extracts and integration jobs, which often compete with users, is another trap. Teams also size storage on data only and forget transaction logs and backups. Finally, a cloud or virtualised ERP still needs CPU and memory reservations: overcommitted hosts can make a correctly sized virtual machine perform badly.

**Cta:** If you are planning an ERP move or want AI reporting to run next to your ERP without hurting performance, Netray can help size read replicas and on-premise AI servers.

**Faq:**

#### How many users per core is typical for an ERP?

**Answer:** There is no universal figure. Vendor guides vary by product, version and workload, and reporting or batch jobs change the picture. The defaults here are placeholders to replace with your vendor's guidance or measured data.

#### Should I size for named users or concurrent users?

**Answer:** Use concurrent users for CPU and memory, because idle sessions cost little. Use named users for licensing and for estimating how many concurrent users to expect. Observe the real peak ratio on your current system if one exists.

#### How much headroom is reasonable?

**Answer:** Many teams plan 30 to 50% above measured peak at purchase time, then expect to grow into it. The right figure depends on how predictable your load is and how easy it is to add capacity later, for example in a virtual environment.

#### Does this work for cloud ERP?

**Answer:** Only partly. SaaS ERP is sized by the vendor. It applies to on-premise, private cloud and IaaS deployments, for example SyteLine, Epicor, Infor LN, SAP or Oracle systems that you host yourself.

## Search terms

erp server sizing calculator, erp hardware requirements calculator, erp server specification, database server sizing erp, how many cores for erp server, erp infrastructure sizing, erp virtual machine sizing, erp capacity planning calculator

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json