A current PCIe 4.0 NVMe drive reads about 12 times faster than a SATA SSD, and a PCIe 5.0 drive about 25 times faster. The gap in random I/O, the thing databases and virtual machines actually live on, runs from roughly 10x to 35x. SATA isn’t slow because the drives are bad. It’s slow because the interface caps it.
For a server, the practical rule is simple: if the box runs a busy database, VMs or builds, get NVMe. If it serves files, holds backups or runs a site whose hot data fits in RAM, SATA is fine and you should spend the difference on memory.
The rest of this post is the numbers behind that rule, all taken from vendor spec sheets.
The interface ceilings
Every SSD talks to the server over an interface, and the interface sets the upper limit no matter how fast the flash behind it is.
| Interface | Link rate | Raw ceiling |
|---|---|---|
| SATA III | 6 Gb/s | 600 MB/s |
| PCIe 4.0 x4 | 64 GT/s | about 8 GB/s |
| PCIe 5.0 x4 | 128 GT/s | about 16 GB/s |
SATA-IO, the group that writes the SATA spec, puts the SATA 6Gb/s interface at 600 MB/s and notes that not all of it reaches you as data, because protocol and handshaking traffic share the link. NVMe drives use four PCIe lanes; KIOXIA’s spec pages list 64 GT/s for a PCIe 4.0 x4 drive and 128 GT/s for PCIe 5.0 x4. Divide by eight bits per byte and you get the rough raw ceilings in the table, before encoding overhead.
What real 2026 drives deliver
Comparing drives from different brands and different test setups invites apples-to-oranges arguments, so here are three data center drives from one vendor, Micron, measured the same way.
| Drive | Seq. read | 4K random read | Read latency |
|---|---|---|---|
| 5400 PRO (SATA) | 540 MB/s | 95K IOPS | 170 µs at 99.9% |
| 7450 PRO (PCIe 4.0) | 6,800 MB/s | 1M IOPS | 80 µs typical |
| 9550 PRO (PCIe 5.0) | 14,000 MB/s | 3.3M IOPS | 60 µs typical |
Sources: the Micron 5400, 7450 and 9550 technical product specifications. IOPS are the best figure across capacities.
Writes tell the same story. The 5400 PRO is rated at 10,500 to 37,000 random write IOPS depending on capacity. The 7450 PRO is rated at 85,000 to 215,000, and the 9550 PRO at 300,000 to 400,000.
One caution on the latency column. Micron measures all three at queue depth 1 with 4 KB transfers, but it publishes a 99.9th-percentile figure for the SATA drive and a median for the NVMe drives. The NVMe drives’ 99th-percentile reads are 90 to 95 µs (7450) and 72 µs (9550), so treat the latency gap as real but closer to 2x than the column suggests.
Other vendors land in the same place. Samsung rates its PM893 SATA drive at 550 MB/s reads and 98,000 random read IOPS, within a whisker of Micron’s SATA part, and Solidigm rates its PCIe 5.0 D7-PS1010 at up to 14,500 MB/s. SATA drives from different makers cluster just under the interface limit. That’s what a ceiling looks like.
Why SATA hits a wall
Bandwidth is only half of it. The other half is how commands reach the drive.
SATA drives use AHCI, a protocol written for spinning disks. According to SATA-IO’s own comparison, AHCI gives you one command queue holding 32 commands, while NVMe allows 64K queues with 64K commands each. With one queue, every thread and every VM waits in the same line. With NVMe, each CPU core can get its own queue, which is why random IOPS scale so far past SATA when a server is busy.
Sequential reads, like copying one huge file, barely touch that advantage. Random 4K reads from 40 database connections at once hit it head-on.
For dedicated servers: when NVMe matters
Here’s where I’d spend the money.
Databases. A busy PostgreSQL or MySQL server does lots of small random reads and a steady stream of small synchronous writes for its log. Both are random I/O at depth, and that’s where the table above shows a 10x to 35x gap. If your database doesn’t fit in RAM, NVMe is the upgrade you’ll feel first.
Virtual machines. Ten VMs on one host means ten operating systems doing their own random I/O at the same time. One AHCI queue of 32 commands is a bottleneck you’ll hit long before the flash is busy.
Build servers and CI runners. Compiles read and write thousands of small files. Faster random I/O shortens every build, and your developers wait on those builds all day.
Check whether storage is your bottleneck first
Before you pay for faster drives, find out whether the disk is what’s slow. On Linux, run iostat -x 5 from the sysstat package and watch it under real load.
The columns that matter are r_await and w_await, the average time in milliseconds a read or write takes, including time spent waiting in the queue. If those climb into double digits while your app feels slow, storage is a suspect; the SATA drive in the table above is rated at 0.17 ms for a 99.9th-percentile read, so waits of 10 ms or more mean requests are piling up in the queue. Don’t lean on %util for SSDs, though. The iostat manual itself says that for devices that serve requests in parallel, such as modern SSDs, it doesn’t show their real limit.
If the waits stay low and the server is still slow, look at CPU, memory or the application. A faster drive won’t fix those.
When SATA is fine
Web servers with a warm cache. If the hot part of your site fits in RAM, the disk mostly sits idle after startup. Buy memory, not NVMe.
Backups, logs and file storage. These are mostly sequential and mostly written once. SATA SSDs, or enterprise hard drives for bulk capacity, do this job at a lower cost per terabyte.
Boot and OS drives. The OS loads once and lives in memory.
A common and sensible layout mixes them: NVMe for the database or VM storage, SATA SSD or HDD for backups and bulk data.
What we offer on GigeNET servers
On our browse servers page, the configuration cards list CPU, cores, RAM and bandwidth but not a drive interface, and the page notes that custom storage configurations and RAID setups are available on request. The order forms behind those builds list enterprise SSDs (240 GB, 1 TB and 2 TB) and enterprise HDDs (1 TB up to 14 TB) by capacity. NVMe isn’t a named option on those forms today.
So if your workload is one of the NVMe cases above, ask for it by name. Put the drive type, capacity and RAID level in a custom quote request and we’ll tell you what’s possible on the build you want. For everything else, the listed dedicated servers with enterprise SSDs cover the job.
Not ready to order yet?
Tell us what you’re after and we’ll email you the build and the price. Need it today? Call (800) 561-2656 and we’ll check what’s in stock.
FAQ
Only if you’ll use the headroom. Micron’s PCIe 5.0 9550 PRO roughly doubles the 7450 PRO’s sequential reads and more than triples its random read IOPS, but few single-server workloads push a PCIe 4.0 drive to its limit. For most databases, a good PCIe 4.0 drive is already far past SATA.
The interface doesn’t decide that; the drive’s endurance rating does. Micron rates both the 7450 PRO and the 9550 PRO at 1 drive write per day, and most 5400 PRO SATA capacities at 1.5. Check the DWPD or TBW figure on the spec sheet, not the interface.
Probably not much, if your pages and database fit in RAM. Once data is cached in memory, the disk barely matters. NVMe helps when the working set is bigger than memory or the site writes a lot.
Yes, and for many workloads it’s the right design. Put latency-sensitive data on NVMe and bulk or backup data on SATA SSDs or hard drives.
Need a server with NVMe, a specific RAID layout or a mix of drive types? Tell us the workload and storage you need and we’ll spec it.