Internal server storage is usually sized by guesswork: a capacity number plucked from the last server, a single drive type for everything, and no thought to how the boot, cache and data layers should differ. That leaves performance on the table and money in the wrong place. This guide is the method our engineers use to size storage inside a single host for UK customers, working from both capacity and the I/O the workload actually demands, then laying out the tiers that follow.
Size both capacity and IOPS, not just gigabytes
Storage has two dimensions and most buyers size only one. Capacity is the obvious one: how much data must the host hold, plus growth across its life. The second is performance: how many I/O operations per second and at what latency the workload needs. A database and a file archive can want the same capacity yet completely different drives, because one is latency-bound and the other is throughput-bound.
Start by separating the two. Write down the usable capacity target with growth, then characterise the workload as read-heavy, write-heavy or mixed, and latency-sensitive or not. Those two answers, capacity and I/O profile, drive every later decision about media and tiering far better than a single headline number ever could.
Boot, cache and data are three different jobs
A well-designed host treats storage as layers, not one pool. The boot tier carries the operating system or hypervisor and should be a small, separate, mirrored device so a boot failure never touches the workload. The data tier holds the application and its data and is sized for capacity and the workload's I/O profile. Where latency matters, a cache or metadata tier of fast NVMe sits in front of bulk capacity to smooth the hot path.
Keeping these separate is what makes a host both fast and serviceable. The classic mistake is booting off the data drives, which couples a trivial boot failure to the workload and makes rebuilds painful. Use a dedicated mirrored boot device and reserve the fast media for the data and cache tiers that benefit from it.
Match media to the tier
Once the tiers are clear, the media choice follows. Boot wants a small mirrored device, not the fastest drive in the box. The data tier is where the workload's I/O profile decides between read-intensive, mixed-use and write-intensive NVMe, balancing endurance against cost. A cache tier wants low-latency, higher-endurance NVMe because it absorbs the busiest writes.
Do not over-buy endurance you will never consume, and do not under-buy it on a write-heavy tier and wear drives out early. Our SSD and NVMe guidance maps endurance classes to write profiles so each tier gets the right drive rather than one compromise drive everywhere.
- •Boot: small, separate, mirrored device - never the data tier
- •Data: sized for capacity and the workload's read/write profile
- •Cache or metadata: low-latency, higher-endurance NVMe for the hot path
- •Match endurance class to write rate; avoid both over- and under-buying
When internal storage is not the answer
Sizing storage inside a host has limits. When capacity outgrows the chassis bays, when several hosts need to share the same data, or when you want independent scaling of compute and capacity, an external array or shared storage is the cleaner design than cramming more drives into one server. That is a different decision from the per-host tiering covered here, and our Dell storage overview is the starting point for it.
For a single host, though, deliberate internal tiering gets you a long way. Size capacity and I/O, lay out boot, data and cache as separate jobs, and match the media to each, and you avoid both the slow-everywhere and the expensive-everywhere outcomes.
Putting it together
When the capacity, I/O profile and tiers are decided, the build is a chassis with the right bay count, a mirrored boot device, data and cache drives chosen by profile, and the controller to suit. You can build an exact specification through our server configuration service, and for the broader build method read how to spec a server in 2026.