NVMe vs SATA: what to choose for a VPS

When NVMe truly helps and when SATA is enough: performance, latency, common workloads, and hands‑on guidance.

4 min read#vps#storage#nvme#sata

Introduction

Storage directly affects application speed. NVMe promises to be “many times faster,” but that speed doesn’t always translate into real‑world gains. Let’s see where NVMe is critical and where SATA remains a sensible, cost‑effective choice.

NVMe vs SATA at a glance

  • Interface:
    • SATA (AHCI) — designed in the HDD era, capped at ~600 MB/s per device.
    • NVMe — modern protocol on PCIe, multiple queues, low latency.
  • Latency (order of magnitude):
    • SATA SSD: ~80–120 µs.
    • NVMe SSD: ~20–40 µs (and lower on top models).
  • Parallelism: NVMe supports thousands of commands across many queues; SATA has a single queue of 32 commands.

Throughput and latency

  • Sequential R/W: NVMe reaches multiple GB/s, SATA caps around ~550 MB/s.
  • 4K random R/W (typical for databases): NVMe delivers multiples more IOPS with lower latency.
  • Stability under load: NVMe holds up better as queue depth rises and under mixed R/W patterns (e.g., 70/30).

Workloads: where each shines

  • OLTP databases (PostgreSQL, MySQL): NVMe almost always pays off — highly latency‑sensitive.
  • Caches & queues (Redis, Kafka, RabbitMQ): NVMe improves p99 latency and throughput.
  • CI/CD, builds, Docker images: NVMe speeds up unpacking, compiling, and heavy small‑file work.
  • Logs & analytics (ELK, ClickHouse): NVMe helps with high concurrency; SATA is fine for “cold” tiers.
  • Static content, simple APIs: SATA is usually enough — the bottleneck is often network/CPU.
  • Backups & cold data: SATA/object storage wins on €/GB.

I/O profiles to watch

  • 4K random R/W — primary indicator for DBs.
  • Queue depth: NVMe scales better with higher QD.
  • p95/p99 latency: averages hide long tails; look at distributions.

Virtualization and containers

  • Over‑subscription on the platform can mask NVMe gains. Prefer plans with guaranteed IOPS/latency where possible.
  • Drivers: on KVM, use virtio‑blk/nvme and current kernels to reduce stack overhead.

Reliability, endurance, and throttling

  • TBW/DWPD: check rated endurance — NVMe models typically last longer under write‑heavy loads.
  • PLP (Power Loss Protection): critical for DB safety.
  • Thermal throttling: under sustained load NVMe may throttle — ensure proper cooling on bare metal.

Economics: €/GB vs €/IOPS

  • SATA wins on cost per GB.
  • NVMe wins on cost per IOPS and “cost per millisecond.” If a 1% speed‑up yields business value, NVMe is often cheaper overall.

Hands‑on: test your workload

Run a minimal benchmark before migrating to NVMe:

# 4K random read, 1 minute
fio --name=randread --filename=/mnt/vol/testfile --size=2G \
    --bs=4k --iodepth=32 --rw=randread --ioengine=libaio --direct=1 --runtime=60 --time_based

# 4K random write, 1 minute (be careful in prod)
fio --name=randwrite --filename=/mnt/vol/testfile --size=2G \
    --bs=4k --iodepth=32 --rw=randwrite --ioengine=libaio --direct=1 --runtime=60 --time_based

Compare IOPS and latency (clat p95/p99) against your real data and patterns.

Linux tuning (short)

  • I/O scheduler: for NVMe use none/mq-deadline, for SATA — mq-deadline/bfq (kernel‑dependent).
  • Mount options: noatime, appropriate commit for ext4/xfs.
  • TRIM: periodic fstrim or discard for long‑term stability.
  • RAID: mdadm RAID10 for write‑heavy mixed loads; RAID0 for max throughput (no redundancy).

Filesystems & DBs

  • ext4 — conservative and predictable.
  • xfs — scales well on big NVMe.
  • For PostgreSQL, review effective_io_concurrency, checkpoint_timeout, WAL sizing and placement.

Monitoring

  • I/O: iostat -x 1, pidstat -d 1.
  • SMART/health: smartctl -a (if available).
  • Spikes: track p95/p99 latency and queue depth at the app level.

Common pitfalls

  • Migrating to NVMe without analysis: real bottleneck could be CPU/network/query plans.
  • No TRIM — performance decay over time.
  • “Everything on one volume”: separate WAL/journals and data across devices/tiers.

Decision checklist

  • Need p99 < 2–3 ms at peak? → NVMe.
  • Lots of small 4K R/W, high concurrency? → NVMe.
  • Mostly large sequential reads, cost sensitivity? → SATA.
  • Backups/archives/static content? → SATA/object storage.

FAQ

Is NVMe always faster? It has higher potential, but outcomes depend on your stack and workload.

Can I mix tiers? Yes: hot data on NVMe, cold on SATA/object storage.

How do I know I’m I/O bound? High iowait, rising queues, and worsening p95/p99 as load increases.

Takeaways

  • NVMe for latency‑ and IOPS‑sensitive workloads.
  • SATA for capacity, savings, and “cold” scenarios. Measure your workload and decide by metrics, not marketing.
NVMe vs SATA: what to choose for a VPS | AlfaHost