The storage controller is one of the quietest decisions in a server build and one of the easiest to get wrong, because the right answer flipped in the last few years. For decades the reflex was to buy a hardware RAID card and let it own the disks. Modern software-defined storage and all-NVMe designs often want the exact opposite: a plain host bus adapter that hands the raw drives straight to the operating system. Choosing the wrong one does not just cost money, it can undermine the data integrity model of the storage stack you are running on top. This guide explains how hardware RAID, software RAID and HBA passthrough differ, and which to choose for each kind of workload.
Three ways to attach disks
Hardware RAID puts a dedicated controller with its own processor and battery-backed or flash-backed cache between the operating system and the drives. The card assembles the physical disks into logical volumes and presents those to the host, handling parity, rebuilds and caching itself. The operating system never sees the individual drives, only the volume the card hands it.
HBA passthrough does the opposite: the host bus adapter is a simple connector that exposes every physical drive directly to the operating system, with no volume abstraction and no on-card RAID. Software RAID then sits in between conceptually, where the operating system or storage platform assembles the raw drives into protected pools itself. The hardware that enables both passthrough and software RAID is the same plain HBA, covered in our host bus adapters guidance.
- •Hardware RAID: dedicated controller owns the disks, presents volumes, has its own cache and battery/flash backup
- •HBA passthrough: plain adapter exposes raw drives to the OS; no on-card RAID, no volume abstraction
- •Software RAID: the OS or storage platform builds protected pools from the raw drives the HBA exposes
- •Passthrough and software RAID use the same plain HBA hardware; hardware RAID needs a RAID card
Why software-defined storage wants passthrough
The decisive shift is that modern software-defined storage platforms want to own the drives end to end. Systems built on ZFS, Storage Spaces Direct, Ceph and the like manage their own redundancy, checksums and self-healing, and they need to see the bare physical devices and their health to do it. Putting a hardware RAID card in front breaks that model: the card hides the individual drives, can mask SMART data, and its own cache can sit in a place the storage layer assumes does not exist, which undermines the integrity guarantees you adopted the platform for.
For these stacks the correct controller is an HBA in passthrough mode, sometimes called initiator-target or IT mode, so the software gets the raw disks. This is exactly why a hyperconverged or Ceph node is specified with passthrough rather than RAID, the same logic we apply when we build storage hosts described in our SSD and NVMe guidance.
Where hardware RAID still earns its place
Hardware RAID is not obsolete; it is the right choice for traditional volumes. If you are running a single host with conventional file systems, a virtualisation host that wants a simple protected datastore, or a boot and OS volume that needs to survive a drive failure with no operating-system involvement, a hardware RAID card is clean and proven. It offloads parity from the host CPU, its backed cache absorbs writes safely across a power loss, and a failed drive rebuilds without the operating system caring.
The classic pattern in a modern server is to use both: a small hardware-mirrored device for boot, kept entirely separate from the data tier, and the data drives handled by whatever the workload needs. Never boot a host off the same drives that carry its data, regardless of controller choice. That separation keeps rebuilds trivial and is a point we make across our build guidance, including how to spec a server in 2026.
NVMe changes the calculation again
All-NVMe designs push the decision further towards passthrough. NVMe drives connect over PCIe lanes rather than a traditional storage bus, and the performance ceiling of a single RAID processor can become the bottleneck for an array of fast drives. Tri-mode controllers that can drive NVMe, SAS and SATA exist and have their uses, but for an all-flash software-defined pool the common modern answer is to let the platform manage the NVMe devices directly and skip the on-card RAID entirely.
There is also a simplicity argument. With software managing redundancy on raw NVMe, there is no controller cache to fail, no controller firmware in the data path, and the storage platform owns the whole picture including device health. For latency-sensitive all-NVMe workloads that is usually the cleaner and faster design, provided the platform is built to do its own protection.
Choosing the controller for the stack
Match the controller to the storage software, not out of habit. If a software-defined or all-NVMe platform is managing redundancy, buy a plain HBA and pass the drives through so the software gets device health and integrity end to end. If you are running traditional volumes, a simple datastore or a protected boot device, hardware RAID is clean and appropriate, and a mirrored boot pair separate from the data tier is good practice either way. Pick the adapter with our host bus adapters guidance, choose the drives with SSD and NVMe, and we set the controller correctly when we build the host.