When a server refresh is off the table but storage performance, capacity or resilience still needs attention, the RAID controller becomes one of the more important upgrade decisions. If you are working out how to choose a RAID card, the right answer usually comes down to platform compatibility, drive type, RAID level requirements and whether the controller suits the actual workload rather than the ideal one on paper.
A poor match creates problems that are expensive in different ways. You can end up with a controller that technically fits the chassis but does not support the backplane, a card with the wrong internal connectors, or a low-end controller trying to serve write-heavy virtualisation workloads with no cache protection. The model number matters, but so does the generation, firmware support and storage design behind it.
How to choose a RAID card for your server platform
Start with the server, not the controller. HPE and Dell platforms have their own controller families, firmware ecosystems, riser layouts and cable requirements. On older and current enterprise systems alike, storage controllers are rarely a generic purchase.
If you are specifying for an HPE ProLiant Gen9 or Gen10 server, for example, you need to confirm whether the controller is supported for that generation, whether it is intended for the embedded storage architecture, and whether additional cache modules or battery or capacitor-backed protection are required. The same applies on Dell PowerEdge systems across Gen12, Gen13 and Gen14, where PERC model compatibility, mini mono form factors and backplane cabling can vary by chassis.
Physical fit is only one part of compatibility. You also need to check lane width, connector type, whether the card is PCIe add-in or a dedicated storage slot design, and whether the server BIOS and controller firmware will recognise the card cleanly. Buyers working with refurbished hardware estates already know this, but it is worth stating plainly: a supported controller with the correct cables is usually cheaper than trying to make an incompatible card work.
Match the form factor and connector standard
Before looking at RAID features, confirm the controller form factor and internal connectivity. Some servers use standard PCIe cards with SFF-8087 or SFF-8643 internal connectors. Others use proprietary or semi-proprietary controller layouts, especially in branded enterprise platforms.
The practical question is simple. Does the controller connect correctly to the existing drive cage or backplane without introducing adapters, unsupported cabling or wasted lanes? If the answer is unclear, stop there and verify the exact server model, backplane type and intended drive count.
Check generation-specific support
Controller families often span more than one server generation, but support is not universal. Firmware dependencies, drive qualification and management integration can all differ. A controller that works in one Gen9 configuration may not be the right option for another if the storage plane, drive media or boot method has changed.
Choose the RAID level before the card
One of the more common mistakes is buying a controller first and only then deciding on the storage layout. That can work for a basic mirror, but it is not a reliable approach for production systems.
If the requirement is RAID 1 for OS redundancy across two SSDs, almost any properly supported entry-level hardware controller may be sufficient. If the requirement is RAID 5 or RAID 6 across a larger set of SAS drives for file storage, rebuild performance, cache and write handling become more relevant. If the workload is database, virtualisation or mixed random I/O, controller quality matters much more than headline port count.
There is also the question of whether RAID 10 is a better fit than RAID 5 or 6. On paper, parity RAID can look more capacity-efficient. In practice, many buyers choose RAID 10 for write performance and simpler rebuild behaviour, particularly where uptime matters more than maximising usable terabytes.
The right controller is the one that supports the RAID levels you need without pushing the card beyond its practical performance envelope.
Cache, cache protection and why they matter
Cache is not a box-ticking feature. On a write-heavy workload, controller cache can materially affect performance consistency. A RAID card with dedicated cache memory and proper cache protection is in a different class from an entry controller designed mainly for basic array management.
If the controller uses write-back cache, power-loss protection matters. Depending on platform, that may mean a battery-backed unit or a flash-backed cache with capacitor protection. Without it, you may be forced into write-through behaviour, which can reduce the performance benefit substantially.
This is one of the clearest examples of trade-off. For a light-duty application server or basic boot array, spending more on high-cache controllers may not be necessary. For a virtual host, transactional workload or heavily used file server, it usually is.
Do not confuse onboard SATA support with a true RAID controller
Many servers provide software-assisted or chipset-based RAID for basic SATA configurations. That may be acceptable for low-priority deployments, lab systems or straightforward boot mirrors. It is not the same as a dedicated hardware RAID card with its own processor, cache and enterprise management features.
If you need predictable rebuilds, better queue handling, proper cache behaviour and wider drive support, choose a genuine hardware controller.
Port count, drive type and expansion planning
The next step in how to choose a RAID card is sizing for the drives you have now and the drives you are likely to add later. It is rarely sensible to buy a controller that only just supports the current configuration if the server has spare bays and the storage requirement is likely to grow.
Count the physical drives, then check the backplane design. An 8-port controller may be enough today, but if the chassis supports additional front bays or rear flex bays, you may need either a higher-port controller or an expander-based design. Expansion capability should be deliberate, not accidental.
Drive media also matters. SAS, SATA and SSD support is not something to assume from the card’s connector alone. Some controllers support mixed media well; others are more limited or perform poorly once consumer-style SATA SSDs are introduced into an enterprise workload. Where possible, keep the drive class aligned with the controller’s intended use.
There is also the issue of speed. Older 6Gb/s controllers can still be perfectly serviceable in the right system, especially on legacy platforms with spinning disks. If you are deploying newer SSDs or pushing denser workloads, 12Gb/s SAS controllers are generally the better choice where the platform supports them.
RAID card or HBA - be clear about the storage design
Not every server should use a RAID card. If the operating system or application stack expects direct disk access for software-defined storage, ZFS, Ceph or similar platforms, an HBA in passthrough mode may be the better option. In those cases, a hardware RAID layer can be unnecessary or actively unhelpful.
That distinction matters because buyers sometimes default to RAID controllers out of habit. If the design calls for hardware arrays and straightforward local storage management, use RAID. If the design calls for software-defined storage with controller transparency, use the appropriate HBA instead.
Firmware, monitoring and operational fit
A RAID card is not just a component purchase. It is an operational decision. You need to be able to monitor array health, replace failed drives cleanly, update firmware when needed and source replacement parts without lengthy delays.
This is where established enterprise controller families have an advantage. HPE Smart Array and Dell PERC ecosystems are familiar to most infrastructure teams, and replacement units, cache modules and cables are generally easier to identify correctly than obscure alternatives. For many buyers, especially those maintaining mixed-age estates, standardising on the native controller family reduces support friction.
Refurbished controllers can make strong commercial sense here. For proven server generations, a tested enterprise RAID card often offers better value than trying to source a newer equivalent that adds cost without solving a real requirement. KahnServers supplies this kind of upgrade path for buyers extending the life of HPE and Dell platforms without paying new OEM pricing.
A practical way to narrow the choice
If you need a workable buying sequence, use this one. Confirm the exact server model and generation. Confirm the backplane and connector type. Decide whether the design requires hardware RAID or HBA passthrough. Choose the RAID level based on workload, not just capacity efficiency. Then size the controller for drive count, media type, cache requirement and future expansion.
That process usually removes most unsuitable options quickly. What remains is a smaller set of controllers that are actually appropriate for the platform and use case.
Price still matters, of course. But on enterprise servers, the cheapest compatible RAID card is not always the lowest-cost decision once rebuild times, cache limitations, missing cables or unsupported firmware enter the picture. Buyers maintaining business-critical systems are generally better served by proven controllers with clear platform fit than by chasing nominal savings on the wrong SKU.
If you are deciding between two suitable options, lean towards the card that fits the server natively, supports the intended RAID level cleanly and leaves headroom for one future change, whether that is extra drives, SSD adoption or a move from a basic mirror to a larger array. That tends to be the point where a sensible storage purchase stays sensible six months later.