SSD vs NVMe: How Disk Type Impacts VPS Performance

SATA SSDs and NVMe drives both use flash, but they reach the CPU by different roads. SATA is capped by a 6 Gb/s interface and a single command queue; NVMe talks to the CPU over PCIe with thousands of parallel queues. In practice that means broadly similar sequential throughput on paper and a very large difference in latency and concurrent IOPS — which is what server workloads actually feel.

The difference in one table

	SATA SSD	NVMe SSD
Interface	SATA III, 6 Gb/s	PCIe lanes direct to CPU
Practical sequential ceiling	~550 MB/s	Several GB/s, PCIe-generation dependent
Command queues	1 queue, 32 commands	Up to 64k queues, 64k commands each
Protocol overhead	AHCI, designed for spinning disks	NVMe, designed for flash
Typical latency	Tens of microseconds	Single-digit to low tens of microseconds
Behaviour under concurrency	Queue depth becomes the bottleneck	Scales with parallel requests

The queue depth row is the one that matters. A single-threaded copy of one large file looks similar on both. Fifty concurrent database queries, each doing small random reads, do not — that is precisely the pattern SATA's single queue was never designed for.

Where the difference is real

• Databases. Random reads and small writes at depth. Query latency tails shorten noticeably, and the tail is what users experience as "sometimes slow".
• Busy web applications. Many small concurrent reads of templates, sessions and assets.
• Container hosts. Image layer extraction, many small files, high parallelism.
• Build servers. Compilation is thousands of small file operations; disk latency is often the hidden constraint, not CPU.
• Mail and log-heavy systems. Constant small synchronous writes with fsync.

Where it honestly is not

• Static sites and low-traffic WordPress. Once the working set is in page cache, disk is barely touched. A CDN and correct cache headers matter far more.
• Anything already CPU-bound. Faster storage does not help a process waiting on a core.
• Sequential bulk transfer over a 1 Gbps network. The link saturates at roughly 125 MB/s, well inside SATA's ceiling. The disk was never the constraint.
• Archival and backup targets. Capacity per euro beats latency for cold data.

This is worth saying plainly because storage type is often sold as a headline feature when the buyer's actual bottleneck is somewhere else entirely. Measure before you pay for it.

How to tell whether disk is your problem

# io wait share of CPU time — above ~10% means look at disk
vmstat 1 5

# per-device utilisation and average wait
iostat -xz 1 5

# which processes are actually doing the I/O
sudo iotop -oPa

In iostat, watch %util and await. High utilisation with low throughput means small random operations — the case NVMe improves most. High throughput at the device's ceiling means you are genuinely bandwidth-bound and a faster interface will help too.

To benchmark rather than guess, measure the pattern you actually run:

# random 4k reads at depth — the database-shaped test
fio --name=randread --rw=randread --bs=4k --iodepth=32 --numjobs=4 \
    --size=1G --runtime=30 --time_based --group_reporting --direct=1

Reading IOPS from a marketing page is not a measurement. Running fio for thirty seconds on the plan you are considering is — and with hourly billing that test costs a few cents.

Configuration that matters as much as the hardware

A poorly configured NVMe device can lose to a well-configured SATA one.

# virtio devices schedule at the host; the guest scheduler only adds latency
echo none | sudo tee /sys/block/vda/queue/scheduler

# stop writing metadata on every read
# add noatime to the mount options in /etc/fstab

Above the block layer, the biggest wins are not storage settings at all: size your database buffer pool correctly so hot data never touches disk, add an object cache, and index the queries doing table scans. A missing index turns a microsecond lookup into a hundred-megabyte read, and no drive fixes that. Our VPS performance guide covers the whole sequence in order of leverage.

What we run, and how to size it

Our KVM VPS plans ship SSD storage sized by plan — 40 GB on the €4 Ion up to 300 GB on the €58 Titan — on 1 Gbps unmetered ports. On the bare-metal side, the dedicated range gives you physical bays and your choice of RAID level, which is the point at which storage layout becomes a decision you make rather than one you accept: six SSD bays on the Xeon E5 machines, configured before handover.

Size disk by taking current data, doubling it, and adding roughly 10 GB for the operating system and logs. Unrotated logs fill a small disk faster than data does — configure logrotate on day one.

Frequently asked questions

Is NVMe always faster than SATA SSD?

For concurrent small random I/O, substantially. For a single sequential stream, the gap is much smaller and often irrelevant behind a 1 Gbps network port.

Will NVMe make my website faster?

Only if disk is the bottleneck. For most sites, caching, a CDN and being physically close to your users produce a far larger improvement — see how hosting affects website speed.

Do SSDs wear out on a busy server?

Modern enterprise flash is rated in petabytes written and outlives most deployment lifetimes. The practical risk on a server is filling the disk, not exhausting its endurance.

Does RAID change the calculation?

On dedicated hardware, yes. RAID 10 improves random read throughput and survives a drive failure; RAID 5 and 6 trade write performance for capacity. On a VPS, redundancy is handled at the host and is not a knob you turn.

The short version

Buy for your access pattern. Concurrent small random I/O — databases, containers, builds — is where faster storage pays for itself. Sequential or cached workloads rarely notice. Measure with fio on a disposable hourly instance before you pay a premium for a number on a spec sheet.