SAS vs SATA Server Drives: What the Interface Actually Buys You

SAS is a full-duplex, dual-ported protocol built for shared storage; SATA is half-duplex and single-ported, built for one host. Dual porting is the difference that matters most in an array: two independent paths reach the same drive, so a dual-controller enclosure can lose a controller, a cable or an expander and keep serving the volume. Multipath software on the host (MPIO on Windows, device-mapper multipath on Linux) then sees one device with two routes instead of two devices. A SATA drive behind a SAS expander is reachable through the SATA Tunneling Protocol, but it is still one port and one initiator at a time — you can put SATA in a shared enclosure, you cannot make it multipathed.

Queue depth is the second difference, and it shows up under exactly the workload servers run. SATA's native command queuing tops out at 32 outstanding commands. SAS drives commonly accept several times that. On a single-threaded copy this is invisible. On a hypervisor host with two dozen guests issuing small random I/O at the same time, the queue is the bottleneck long before the link is, and a deeper queue is what lets the drive reorder work instead of servicing it in arrival order.

Error recovery timing is the difference that causes the most support tickets and gets the least attention. Enterprise drives cap how long they will retry a marginal sector — the feature is called TLER, ERC or CCTL depending on whose firmware you are reading — so that a RAID controller gets an answer inside its own timeout and marks a sector bad instead of marking the whole drive dead. Consumer SATA drives retry far longer by design, because on a desktop with no redundancy a slow read beats a lost file. Put those drives behind a hardware RAID controller and the controller times out first. The array does not report a media error; it reports a dropped drive. That is the single most common cause of the mystery degraded array, and it is a firmware behaviour, not a cable fault.

Two more that only appear in enterprise datasheets. Unrecoverable read error rate is worth reading carefully, because it tracks the drive tier rather than the interface: 10,000 and 15,000 rpm performance drives are commonly published at one sector in 10¹⁶ bits read, nearline models at one in 10¹⁵ — and inside a single nearline family the SAS and SATA variants normally publish the same 10¹⁵ figure, so ordering the SAS variant does not by itself buy the better rate. The number matters most during a rebuild, when the array is reading every sector of every surviving member. And SAS supports non-512-byte sector formats: arrays that use T10 Protection Information format drives at 520 or 528 bytes per sector to carry an integrity field. A drive pulled from one of those arrays will not present usefully to a standard HBA until it is reformatted back to 512 or 4K, which is why a perfectly healthy second-hand SAS drive sometimes appears to be invisible.

Solid-state endurance is published as drive writes per day and as total bytes written, and converting between them — capacity × DWPD × 365 × warranty years — is the arithmetic that decides which endurance class a tier needs. That conversion is worked through end to end in our NVMe form-factor and lane-budget piece, linked at the foot of this article, and it applies identically to a SAS SSD and a SATA one: the interface does not change the endurance class, and neither does the badge on the box.

What the interface decision does change is how much of your write volume actually reaches the drives. Host writes are not drive writes, because parity RAID multiplies them. A small random write to a RAID-5 set costs two reads and two writes, a write penalty of four; RAID-6 costs six. Sizing endurance from application write volume without applying the parity penalty is how a tier that looked like 0.3 DWPD on paper wears out at 1.2 — and the controller's own garbage collection adds write amplification on top of that, which is why buying at exactly your calculated DWPD is buying with no margin.

Hard drives have no DWPD at all, and the figure that replaces it is one almost nobody checks: the annualized workload rate. Nearline enterprise drives are commonly rated for around 550 TB read plus written per year — roughly 1.5 TB a day — and the published reliability figures are stated for operation inside that rate. A backup target that ingests a full copy every night, or a video-surveillance array recording continuously to a small number of spindles, can pass that limit without anyone noticing, and the drive is then running outside the conditions its failure rate was quoted under. Compare it against your actual daily volume before you decide capacity per spindle.

Finally, read MTBF for what it is. A 2.5-million-hour MTBF does not mean a drive lasts 285 years; it is a population statistic that translates to an annualized failure rate — 2.5 million hours corresponds to roughly 0.35% AFR. In a 24-drive shelf that is a drive failing about every twelve years on average, which is a useful planning number, and a completely useless promise about any individual unit. Buy spares on that basis.

One rule covers most of it: a SAS controller will run SATA drives, and a SATA controller will never run SAS drives. Compatibility is one-way. If there is any chance the chassis will hold SAS later, the SAS controller is the cheaper decision now, because the alternative is replacing the controller and possibly the backplane to add one drive type.

Then decide what the controller should do. A host bus adapter presents drives individually and lets the operating system own redundancy — the correct choice for vSAN, Ceph, ZFS and Storage Spaces, all of which want raw devices and are actively degraded by a RAID layer hiding disks from them. A RAID controller with a protected write cache is the correct choice for classic boot-and-volume designs where the OS should see one device. Buying the wrong one is recoverable on some cards through a firmware mode change and on others is not recoverable at all, so treat it as a purchasing decision rather than a configuration detail.

Cabling is where orders go wrong most often, because the connector families look similar and are not interchangeable. SFF-8643 is internal mini-SAS HD, SFF-8644 is the external equivalent, and SFF-8654 (SlimSAS) is the newer internal family used on 12G and 24G designs. A controller with external ports cannot be cabled to an internal backplane with an adapter you improvise on the day. Read the port type on the card, then read the port type on the backplane, then order the cable that names both.

Backplanes add an oversubscription question nobody asks until performance disappoints. A twelve-bay backplane fed by a single x4 wide port shares four 12Gb/s lanes among twelve drives. With spinning media that is fine — twelve nearline drives cannot fill 48Gb/s. With eight SAS SSDs behind the same link it is the ceiling. If the chassis uses an expander rather than direct-attach paths, find out how many wide ports connect it before you size an all-flash tier.

Last, the physical details that stop a delivery from being installable. Carriers are chassis-specific and generation-specific — a 2.5-inch tray from one generation of a vendor's line frequently will not latch in the next. Check 15 mm versus 7 mm drive thickness on 2.5-inch bays. And if you are planning to mix drive types in one set of bays, a U.3 tri-mode backplane on a tri-mode controller accepts SAS, SATA and NVMe in the same slot, while a U.2 backplane is wired per bay for one protocol, so an NVMe bay on it will not later accept a SAS drive. That single distinction decides whether a chassis can change its mind in three years.