Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I hear lots about SATA being slower than SAS but I've only found 1 decent benchmark.

In this, SAS comes out on top until you read that the SAS drives are 10K and the SATA drives are 7200 RPM.

Has anyone seen any good benchmarks/comparisons with equivalent speed disks? Has anyone seen any real-world loads (DB loads/searches, media streaming, etc?

share|improve this question
Ive talked to a HP guy about his opinion about this. He reasoned that SATA are only 7200 rpm, too. Well - he was wrong. I easily found 10K drives as well. So lets look if the bounty will provide hard evidence. I have my doubts... – Nils Sep 14 '11 at 21:24
SAS comes into play more noticably when you have multiple simultaneous access to a drive. Also it is easy to compare the two if you use nearline SAS and compare with the same base SATA drive. I don't have the benchmarks to hand anymore but in our tests they perform the same under some loads with SAS upto 20% faster under our simulated typical SAN usage. – JamesRyan Sep 16 '11 at 9:18
@JamesRyan: Have you a explanation for this? "Typical" is random access with how many simulated clients? – Nils Sep 16 '11 at 20:54
And don't forget, if speed is what you're after, an SSD trumps anything else regardless of interface. – aroth May 15 '13 at 6:05
up vote 9 down vote accepted

The "SATA = 7.2K RPM, SAS = 10/15K RPM" mind-set is strong, and (in my opinion anyway) where most of the "SAS is faster than SATA" thinking comes from. There are some slight differences between SAS and SATA drives, notably in their on-board caching algorithms (NCQ vs. TCQ). However, the performance difference of equivalently specced hard-drives will be fractional percentage points in most use-cases.

share|improve this answer

IOPs is the difference your looking for in the "speed".

The simple way to explain the difference is that SATA is half duplex and SAS is full duplex. SATA drives are dumb and have to communicate with the controller for operations. SAS drives are smart and only requests and returns use the bus.

Depending on your usage case, spending more may not gain much..

share|improve this answer
So you are saying the SAS controllers essentially perform like the old SCSI controllers? I found when testing those, the thru-put was nearly the same (within 10-20%) but the CPU usage for SCSI was under 5% and for ATA was over 90%. Of course that could have been the controller in use at the time, but still showed me how SCSI beat the pants off ATA. (This was back when the CPUs where single core and less than 1GHz.) – boatcoder Sep 15 '11 at 17:50
I think this is the first answer hitting the mark. So the benchmark has to include multiple short transfers - then you should see the difference - IMHO. – Nils Sep 16 '11 at 20:59
@Mark0978: Yes, but instead of using a parallel bus where all the drives shared the same bandwidth, each drive is serially attached.. – wrmine Sep 18 '11 at 5:53

This is only a single anecdote, but I did some performance comparisons a while back for sequential read/write speeds on Seagate Barracuda ES.2 SATA and SAS disks, and found the SAS disks were significantly (low-double-digit percentages) worse than the SATA disks. These disks were not only the same speed rotational (7200rpm), but the same brand and model, just with a SAS interface instead of SATA (although I believe the SAS drives had smaller cache as well - 16MB vs 32MB for the SATA disks)

I didn't test random-access however, as I didn't care.

Just point anecdote, for a specific use case. YMMV :)

share|improve this answer
Useful, since we are looking at Seagate Barracuda drives in this case... – boatcoder Aug 5 '11 at 2:59
But what about the controller? That's likely the limiting factor. – anastrophe Aug 5 '11 at 4:46
@anastrophe: In the tests I ran, we were using LSI8888 SAS controllers, with either Barracuda ES.2 SATA or Barracuda ES.2 SAS disks, with identical RAID and filesystem settings - the only variable was the SATA/SAS model of disk (and therefore the on-disk cache size as well, however that is moot for sequential disk access). We tested both RAID5 and RAID0, and while with RAID5 the controller is a bottleneck, with RAID0 it is not. Finally, the SATA disks performed better in both cases, even in the RAID5 case. As I said though, YMMV :) – Daniel Lawson Aug 7 '11 at 21:04

Let`s see it from the server perspective. SATA is the successor of ATA which is the successor of IDE. Built for standard PCs. SAS ist the sucessor of SCSI which has the better (i.e. more stable, more standardized) protocol in hard and software. SCSI were the expensive disks used in servers.

Also note that if you buy a Dell-Server (I take that brand as an example) with 5 years support the support will only be 2 years for a SATA drive but you will get the full 5 years for SAS. This is a good hint about reliability.

share|improve this answer
What I'm finding from the drive manufacturers is identical latency, 6Gb/s speeds, * SAS - 3year warranty, SATA - 5year, * SATA cost $, SAS pretty much 3 times more. The longer warranty on the SATA drives surprised me, the identical speed specifications further confused me, so I'm really wanting to see some hard and fast benchmarks, not anecdotal evidence. We descended from apes, but most of us don't swing in trees anymore..... – boatcoder Aug 4 '11 at 21:06
All of the information regarding reliability, maturity, etc. is true; however, none of it addresses the question at hand. Don't get me wrong, I run SAS drives in my db server, for all the reasons you cite. But those reasons aren't relevant here. – anastrophe Aug 4 '11 at 21:06
It's all about costs - mostly. But I think the main point is how commands are queued - so I guess that on DBs with heavy loads the difference should be measurable. Let`s see if someone comes up with real numbers. – Nils Aug 5 '11 at 19:42
@anathrophe if SAS takes off load from your CPUs during massive random access (like SCSI) this might be the point here. – Nils Sep 17 '11 at 20:43

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.