An ERP system is the server that runs the business, and it has a distinctive profile: it is memory-bound, intolerant of downtime, and almost never a single tier. SAP, Microsoft Dynamics 365 and Sage all share these traits even though they differ enormously in scale. Spec an ERP host like a generic application server and you will hit a memory wall and a resilience gap at the worst possible moment. Here is how we spec ERP infrastructure for UK customers.
ERP is a tiered application, not one box
Almost every ERP deployment splits into tiers: a database tier holding the transactional data, an application tier running the business logic, and a presentation or web tier serving users. SAP formalises this most explicitly, but Dynamics and even larger Sage 200/X3 deployments follow the same shape. You can collapse the tiers onto fewer hosts for a small deployment, but the moment you scale or need availability, the tiers want separating - and each has a different hardware appetite.
Designing the tiers first tells you where to spend. The database tier is the precious, memory-and-latency-sensitive layer; the application tier scales horizontally; the web tier is cheap and stateless. Sizing the whole thing as one undifferentiated lump is how ERP projects end up both over- and under-specified at once.
Memory is the defining constraint
ERP workloads are memory-bound. The database tier wants to hold the working set - and increasingly the entire dataset - in RAM, because that is what keeps transaction response times low. SAP HANA is the extreme case: it is an in-memory database that sizes RAM to a multiple of the compressed dataset, landing real-world deployments at hundreds of gigabytes to multiple terabytes. Dynamics and Sage are less hungry but still reward generous memory on the database tier.
Practically this means specifying large, balanced DDR5 configurations and choosing platforms with the memory capacity and channel count to match. Populate every channel evenly for full bandwidth - on an in-memory ERP database, memory bandwidth is throughput - and leave headroom for dataset growth, because you cannot easily add RAM to a running production ERP without an outage. Plan the population with our server memory guidance.
Availability is a business requirement, not a nicety
When ERP is down, the business stops invoicing, shipping and trading. That makes high availability a hard requirement rather than an option, and it shapes the hardware. The database tier needs a defined HA model - clustering, log shipping or database-native replication - which dictates whether you buy shared storage and how many database hosts you need. The application tier achieves availability by running multiple instances behind a load balancer.
At the component level, every ERP host wants dual power supplies on separate feeds, ECC memory with the platform's RAS features, redundant networking and out-of-band management as standard. These are not where you economise on the server that runs the business. Decide the HA model early, because it changes the host count and the storage design.
- •Database tier: memory-rich, low-latency NVMe, defined HA (cluster/replication), shared storage if clustered
- •Application tier: multiple instances behind a load balancer, scales horizontally
- •Web/presentation tier: modest, stateless, easy to scale out
- •Every tier: dual PSU, ECC RAS, redundant NICs, out-of-band management
Storage and CPU: latency and licensing
The database tier needs low-latency NVMe for data and logs - ERP transactions are latency-sensitive, so storage latency, not raw capacity, is what users feel. The application tier is far less demanding. For CPU, the database tier benefits from fewer, faster cores (and many ERP databases are licensed per core, so core count is also a recurring cost), while the application tier can scale across more, cheaper cores.
Match the platform to the deployment scale: a mid-market Dynamics or Sage estate often consolidates onto a couple of well-specified two-socket hosts, while a large SAP HANA database moves up to a high-memory scale-up server certified for HANA. Build the memory-rich database host and the application hosts in our configurator.
Putting the ERP build together
In summary: design the tiers, then spend on memory and availability where the database lives. ERP is memory-bound and downtime-intolerant, so the database tier gets generous balanced RAM, low-latency NVMe and a real HA model, while the application and web tiers stay lean and scale out. Size the memory with our memory guidance, sanity-check the whole design with our server configuration service, and build the hosts in our configurator.