NVMe vs SATA SSD

The interface is the difference

Both technologies store data on NAND flash. What separates them is how the drive talks to the computer.

SATA and its command set, AHCI, were designed for spinning disks. AHCI offers one command queue with up to 32 outstanding commands. For a mechanical drive that could only service one seek at a time, that was plenty. For flash that can serve many requests in parallel, it's a bottleneck. The SATA III link also tops out at 6 Gbit/s.

NVMe was written for flash. It connects over PCIe lanes directly to the CPU and supports up to 65,535 queues, each up to 65,536 commands deep. Each CPU core can have its own queue, so there's no lock contention to submit I/O. The protocol path is shorter, too, which cuts latency per operation.

What changes in practice

Those are protocol and device characteristics in general. On a virtual server, the numbers you see also depend on the hypervisor's virtual disk path and on what other guests are doing. Benchmark the server, not the spec sheet.

Workloads that notice

• Databases. PostgreSQL and MySQL issue lots of small random reads when the working set exceeds memory, and frequent small synchronous writes for the write-ahead log or redo log. Commit latency follows fsync latency. See databases.
• CI and builds. Dependency installs and compilers touch thousands of small files. Parallel jobs multiply the concurrency. See CI runners.
• Container hosts. Pulling and extracting image layers is I/O-heavy, and many containers reading at once is exactly the parallel pattern NVMe handles well.
• Search indexes and queues that rely on many small appends and reads.

Workloads that don't

A static site served by nginx from page cache, a small API whose data fits in RAM, a WireGuard endpoint, a Discord bot. Once the hot data sits in memory, disk speed barely matters. Spend the money on RAM instead, or on the cheaper plan.

Measure your own server

Use fio for controlled tests. Run them on a scratch file, not a production database's disk at peak hours.

# Debian/Ubuntu: sudo apt install fio   |   Alma/Rocky: sudo dnf install fio

# 4K random read, moderate concurrency, bypassing page cache
fio --name=randread --filename=/root/fio.test --size=2G \
    --rw=randread --bs=4k --iodepth=32 --numjobs=4 \
    --direct=1 --ioengine=libaio --runtime=60 --time_based --group_reporting

# Small synchronous writes, like a database commit log
fio --name=syncwrite --filename=/root/fio.test --size=1G \
    --rw=write --bs=4k --iodepth=1 --numjobs=1 \
    --fsync=1 --direct=1 --runtime=30 --time_based

rm /root/fio.test

Read the latency percentiles, especially p99, not just the average IOPS. A drive that averages well but spikes at the tail will make your slowest requests slow.

During real load, watch device behaviour with iostat from sysstat:

iostat -x 1
# r_await / w_await: average ms per read/write
# aqu-sz: average queue size
# %util: misleading on NVMe; parallel devices can be 'busy' and still have headroom

Capacity versus speed

Fast storage tempts people to keep everything on the server. Resist it. Logs, old releases, container layers and forgotten database dumps fill a 40 GB volume faster than you'd guess, and a full disk takes a database down harder than a slow one. Rotate logs with logrotate or journald limits, prune images, and alert well before 90 percent usage. Pick a plan for the data you'll hold in a year, not today.

The honest bottom line

NVMe-backed storage removes a common bottleneck for I/O-heavy work and makes concurrent load behave more predictably. It doesn't fix an unindexed query, an N+1 ORM loop or a cache that never hits. Profile first. If iostat shows high await times while CPU sits idle, storage is your problem and faster disks help. If not, look elsewhere.

Every FastNode plan uses NVMe-backed storage; capacity scales from 20 GB to 200 GB across the six plans. Tuning tips for databases on fast storage are in the database tuning guide.