Internal server storage is where two opposite mistakes meet: buying a wall of capacity with no thought for how fast it needs to be, or buying expensive flash for data that is read once a quarter. Sizing the storage inside a single host is a different exercise from choosing a shared array; it is about matching capacity and performance tiers to what the workload on that box actually does. This is the method we use with UK customers to size internal storage, the boot, cache and capacity layers and how to split them, so you neither starve the workload nor overpay for idle speed.
Capacity is the easy half; performance is the other half
Every storage conversation starts with capacity, and capacity is the easy half: total the data the server must hold, add realistic growth, and add headroom so the pool never runs permanently full. The harder and more important half is performance, because the same number of terabytes can be delivered slowly on bulk drives or quickly on NVMe, and the right answer depends entirely on what the workload demands of it.
The single most useful question is how the workload reads and writes: a database hammering small random operations needs latency and IOPS, a backup target or archive needs cheap capacity and steady throughput, and a general virtualisation host sits somewhere in between. Size capacity and performance as two separate requirements, because a host that has plenty of space but not enough speed is just as broken as one that ran out of room.
Think in tiers, not one big pool
Modern servers rarely want one uniform pool of storage. They want tiers, each matched to a job. A small, fast tier of NVMe handles the hot, latency-sensitive data and caching; a larger tier handles bulk capacity at lower cost; and a separate, mirrored device handles the operating system. Splitting storage this way means you buy expensive flash only where speed pays for itself and cheap capacity everywhere else, instead of averaging the cost across data that does not need it.
The tiering does not have to be exotic. Even a simple split, NVMe for the working set and database files, larger drives for cold or bulk data, and a dedicated boot pair, captures most of the benefit. The point is to stop treating all the data on a server as if it has the same performance requirement, because it almost never does, and the cost difference between tiers is large enough to be worth the small extra planning.
- •Boot tier: a small, mirrored device, separate from data
- •Cache / hot tier: fast NVMe for the working set and latency-sensitive files
- •Capacity tier: larger, cheaper drives for bulk and cold data
- •Match each tier's endurance and class to how hard it is written
The boot tier: small, mirrored, separate
The operating system or hypervisor should never share drives with the data it serves. A boot-drive failure on a shared pool can take the whole host down and makes rebuilds fiddly, whereas a dedicated, mirrored boot device, a Dell BOSS or an M.2 RAID-1 pair, isolates that risk and makes recovery trivial. It is a small, cheap part of the build that prevents a disproportionate amount of pain.
Keeping boot separate also keeps the data tiers clean: you can rebuild, repurpose or expand the data pool without touching the operating system, and a failed boot device is a swap-and-resync rather than a rebuild-the-server event. This is one of the few storage decisions that is the same on almost every server regardless of workload, which is why it appears in every build guide we write.
Cache and capacity: where the money is decided
The split between fast and bulk storage is where most of the cost is decided. For a database or latency-sensitive application, the hot data belongs on low-latency NVMe, and the capacity tier behind it can be more modest because the workload rarely touches the cold data. For a backup or file role, the opposite is true: a large capacity tier dominates and only a small flash tier is needed to smooth bursts.
Endurance matters as much as speed in this split. Write-heavy data such as database logs or a caching tier wants higher-endurance, mixed-use or write-intensive flash, while read-mostly bulk data is happy on cheaper, denser, read-intensive drives. Matching the drive class to the write profile, rather than buying one endurance grade for everything, is how you avoid both premature wear and wasted spend. Choose the exact drives with our SSD and NVMe guidance.
When internal storage is the wrong answer
Internal storage is right when a single host owns its data and the capacity fits the chassis. It becomes the wrong answer when several servers need to share the same data, when capacity outgrows what the bays can hold, or when you need array-level features such as advanced snapshots, replication and thin provisioning across hosts. At that point the data belongs on a shared array, not inside one server.
Knowing where that line sits saves money in both directions: you avoid cramming a shared workload into one box that becomes a single point of failure, and you avoid buying a full external array for a single host that a few internal NVMe drives would serve perfectly. When the workload crosses into shared, capacity-led territory, our Dell storage options take over from internal disks.
Putting it together
Size capacity and performance as two separate requirements, then build the storage in tiers: a mirrored boot pair, a fast NVMe tier for the hot working set, and a capacity tier matched to the bulk data, each with an endurance class that fits how hard it is written. Keep it internal while one host owns the data and it fits the chassis, and move to a shared array when the workload outgrows the box. Build and price the exact internal layout in our server configuration service.