NVMe vs SSD VPS: Which one you suppose choose?

NVMe get importance for VPS?

NVMe get importance for VPS if your software dey send plenty small reads and writes and e dey wait for each one to finish. E no dey change anything for site wey dey serve cached pages, or for program wey just dey wait for network. The medium na one factor. The hypervisor wey dey front of the disk, and the other guests wey dey share the same host, na dem dey set the limit wey you go truly get.

Wetin NVMe change, and wetin e no change

NVMe (non-volatile memory express) no bi type of flash memory. Na di protocol and di connection wey dem dey use reach di flash. NVMe device dey sit on top PCIe (peripheral component interconnect express) lanes and e dey speak NVMe. SATA (serial ATA) SSD dey sit on top SATA link and e dey speak AHCI (advanced host controller interface). Di memory chips wey hold your bytes fit bi di same for both of dem.

Two tins differ, and both of dem concern di command path, no bi di storage itself.

Queues. AHCI dey give di kernel one command queue wey fit hold 32 commands. NVMe dey allow thousands of queues, for real life, one per CPU core, and each one deep pass 32. One process wey dey read one block at a time no go see dat difference. Database wey get 64 reads wey dey pending fit see am: for SATA, di 33rd request go wait for queue slot before di device even see am, but NVMe device go accept all of dem and work on top dem together.

Link width. SATA III link dey run at 6 Gbit/s, wey bi about 550 MB/s of real data after protocol overhead. Dat one na fixed ceiling, no matter di flash wey dey behind am. Four PCIe lanes dey carry several gigabytes per second, so di link no dey act as limit again.

Latency na where pipo usually get am wrong. At queue depth 1, wey mean say one request dey fly, SATA SSD dey answer 4k read for about 100 to 150 microseconds. NVMe dey answer for about 80 to 100. Both of dem fast, and nothing wey you run go notice di difference for one request. Di gap dey open when concurrency come in. Queue depth, di number of requests wey dey fly at once, na di setting wey dey decide weda di two media look alike or dem dey very different.

Network block storage na third class wey get different physics. Write dey cross network go storage cluster and dem go acknowledge am only when di cluster don hold am, so dem dey measure im latency for milliseconds instead of microseconds. Wetin you buy for dat latency na durability: di volume go last pass di host wey you attach am to, and you fit snapshot and resize am.

Typical figures wey dem dey publish: NVMe, SATA SSD and network storage

[
  {
    "disk": "Local NVMe SSD",
    "iops_4k_read": "184,000",
    "p99_latency_ms": 0.4,
    "seq_read_mbps": "3,400"
  },
  {
    "disk": "Local SATA SSD",
    "iops_4k_read": "90,000",
    "p99_latency_ms": 1.2,
    "seq_read_mbps": "550"
  },
  {
    "disk": "Network block storage",
    "iops_4k_read": "12,500",
    "p99_latency_ms": 6.5,
    "seq_read_mbps": "250"
  }
]

Dem dey usually talk sey local NVMe device fit do 184,000 random 4k read IOPS (input/output operations per second) wen queue depth na 32. Dat same test for SATA SSD dey near 90,000, becos di single AHCI queue and di 6 Gbit/s link dey limit am. Na di provider dey limit network block storage, no be di hardware, and 12,500 na di limit wey dem usually write down.

Latency dey show di same tin for di way wey your users go feel am. Di p99 read latency, wey mean di 1 percent of requests wey slow pass, dey around 0.4 ms for local NVMe and 1.2 ms for SATA. If you put network for di middle, e go turn to 6.5 ms, wey pass ten times di NVMe figure.

Sequential reads get di biggest gap and na dem no dey too useful: 3,400 MB/s against 550 MB/s. Almost noting for server dey read one big file from start to finish wit full speed. Di random column and di latency column dey explain wetin database, mail queue or package manager dey really do.

Which workloads dey notice di disk

One rule explain all of dem: workload go notice di disk only wen e dey wait for di disk. Linux dey keep file data wey dem just use for RAM, inside di page cache, so di second time wey you read file, e no go reach storage. If di working set, wey be di data wey you dey use, fit enter RAM, reads go turn to memory reads after di first time. Writes dey different. Any write wey application flush wit fsync() must dey for stable storage before di application fit continue.

Work wey dey commit. PostgreSQL, MySQL and SQLite dey call fsync() or fdatasync() wen dem commit, and each commit dey wait for di device to answer. Di commit rate of one connection depend on write latency, no be bandwidth. Device wey dey flush for 0.2 ms go allow more commits per second pass one wey dey take 5 ms, and no amount of throughput go change dat. MySQL dey talk am for di error log wen di flush no fit keep up:

[Note] InnoDB: page_cleaner: 1000ms intended loop took 4589ms. The settings might not be optimal.

PostgreSQL dey report am for im checkpoint lines, wia big sync= value mean say di flush itself slow:

LOG:  checkpoint complete: wrote 8192 buffers (25.0%); write=27.694 s, sync=11.207 s, total=39.001 s

Work wey dey touch many small files. Every file get metadata operations wey one big sequential read no get. npm install, git clone of big repository, unpacking container images, Maildir mail store and backup wey dey walk big tree, all of dem dey spend dia time on small random access. One restic backup job on a VPS dey read and hash every file wey e never see before, so di wall-clock time of backup over one million files dey follow random read latency closely. Di same tin dey happen for du -sh, wey dey read metadata and noting else.

Databases wey don big pass RAM dey fall for dis category too. Once di index no fit enter page cache again, every lookup go turn to random read, and di disk go come back to di critical path.

Which workloads no dey notice di disk

One blog or small company site. Di pages small, page cache dey hold all of dem afta di first request, and di limit na CPU for rendering or bandwidth for assets. One LAMP stack on Ubuntu 24.04 wey dey serve low-traffic site no dey do almost any disk IO once e don warm.

Media streaming. One 4K stream at 40 Mbit/s dey read 5 MB/s. Ten of dem go read 50 MB/s, wey even network block storage fit serve without stress. A Jellyfin media server on a VPS limit na your network egress allowance, and CPU when e dey do transcoding, e no be di storage medium.

Local model inference. Running Ollama on a VPS to self-host an LLM dey read di model file one time, den e dey work inside RAM. NVMe dey cut di load time of one 20 GB model from minutes go seconds. E no dey change tokens per second, because memory bandwidth and CPU dey control dat one.

Anything wey dey wait for external service. One worker wey dey spend 800 ms per job on one HTTP request no go run fast just because you get beta disk.

Why di hypervisor get importance pass di medium

You no dey talk direct to di device. You dey talk to one virtual disk wey di hypervisor show you, mostly through virtio, and plenty decision for dat layer get importance pass NVMe versus SATA.

You no fit see di medium from inside di guest. lsblk -d -o NAME,ROTA,SIZE,MODEL go show vda wit empty model, sake of say virtio no dey pass di drive identity come out. cat /sys/block/vda/queue/rotational dey report wetin di hypervisor advertise, so if you see 0 for dia, e no mean say na flash. nvme list, from di nvme-cli package, no dey list anything for most VPS even if di host full wit NVMe drives, because your disk na virtio device and e no be NVMe device. Any plan wey talk say NVMe, na wetin di host get e dey describe. Your volume fit still dey network attached.

Host cache mode dey change di numbers pass di medium. If writeback caching dey on for di host, one guest fsync() fit return as soon as di host get di data for e own RAM. Dat one go give you benchmark result wey no physical device fit produce. E also mean say if di host crash, you fit lose writes wey your database tink say e safe. Wit cache mode none, di numbers go low but dem go dey honest.

Caps and burst credits. Plenty providers dey cap IOPS per volume or per plan, and plenty network volumes dey use burst allowance. Burst allowance na pool of credits: di volume go run fast as long as credits still dey, den e go drop go low baseline. Di symptom easy to identify. One import or restore go run quick for some minutes, den e go slow down sharp and stay slow, even if you no change anything for your configuration. You don finish your credits.

Neighbours. For one shared host, your disk latency go change based on wetin oda guests dey do. Dis na why you suppose measure pass one time. Run di same test for morning and again for evening, den compare di difference. For one busy host, di difference between two runs on top di same volume often big pass di difference wey dem publish between two media.

How to measure the disk wey your VPS get

Install fio, di standard IO benchmark, come measure am. Three tins to watch: di test go create file, so e go use disk space and e go count against any IOPS limit wey dem bill you for. Make your runs short. No run am for full queue depth against volume wey dey serve live traffic, because you go dey compete wit your own application.

sudo apt update && sudo apt install -y fio ioping sysstat
cd /var/tmp

Random read for queue depth 32, wey be di depth wey vendors dey quote:

fio --name=randread --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 \
  --runtime=30 --time_based --group_reporting

Di line wey concern you start wit read:

  read: IOPS=184k, BW=719MiB/s (754MB/s)(21.1GiB/30001msec)

--direct=1 dey bypass di guest page cache, so di result dey show wetin di device fit do, no be your RAM. If you comot am, na memory you dey measure, and dat one go give you number wey no disk fit reach. Use --size=4G or sometin bigger if you get space, because 1G file fit stay inside di host cache and make di result look beta pass wetin e be.

Queue depth 1 dey show raw latency, na wetin single-threaded process dey feel:

fio --name=lat --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based

Di commit test dey predict how database go behave. E dey write 4k and call fdatasync() after every write, so di rate wey dem report include di flush:

fio --name=commit --filename=fio.test --size=1G --bs=4k --rw=randwrite \
  --ioengine=psync --fdatasync=1 --runtime=30 --time_based
rm -f fio.test

Di IOPS figure from dat run dey close to di highest number of small transactions per second wey one database connection fit commit, because commit dey wait for di same flush.

For quick sample wey no need fio:

ioping -c 20 .

--- . (ext4 /dev/vda1) ioping statistics ---
19 requests completed in 4.13 ms, 76 KiB read, 4.60 k iops, 17.9 MiB/s
min/avg/max/mdev = 174.2 us / 217.6 us / 386.1 us / 51.3 us

Di mdev value, wey be di mean deviation, get value like di average. If you see big deviation for box wey no dey busy, e mean say di storage backend na shared one and e dey busy.

How to read the result

As of July 2026, dis one na beta readings for small VPS. Tens of thousands of 4k random read IOPS for queue depth 32, with queue depth 1 latency wey dey under about 0.3 ms, show say na local flash you dey use. If queue depth 1 latency reach several milliseconds, e mean say network path dey, no matter wetin dem call di plan. Sequential reads wey stop near 550 MB/s na sign say SATA link dey. If di number pass wetin one single device fit do, e mean say caching dey di path, and most times na for di host e dey.

To see wetin your live workload dey do to di disk:

iostat -x 1 3
vmstat 1 5
cat /proc/pressure/io

Inside iostat -x output, check r_await and w_await, wey be di average milliseconds wey request take wait, and aqu-sz, wey be di average queue length. No mind %util if you dey use virtual disk. E dey report di share of time wey at least one request dey outstanding, but dat one no tell you anything about saturation for device wey dey serve many requests at once. So, %util of 100 join with r_await of 0.2 ms mean say di disk dey healthy and e dey work well. Inside vmstat, di wa column na di percentage of CPU time wey dem spend dey wait for IO. If /proc/pressure/io dey for your kernel, e some avg10= value na di share of di last 10 seconds wey at least one task stall on IO. Dis one na di direct answer to weda storage na your bottleneck.

Wetin disk-bound VPS dey look like

If load average high but CPU dey idle, and you see big wa for vmstat, e mean say processes dey queue for disk. The correct signal wey kernel dey give na this message for dmesg -T:

INFO: task jbd2/vda1-8:194 blocked for more than 120 seconds.

That line dey show sake of say one kernel thread wait pass two minutes make storage respond, so the hung task watchdog log am. jbd2 na the ext4 journal thread, e mean say the whole filesystem dey wait, no be just one program wey no behave well. For VPS, this one usually mean say problem dey the storage backend or your IOPS allowance don finish.

The application symptoms dey follow the same pattern. Median response time fit still dey okay, but the slow requests go get long tail, sake of say na only the requests wey touch disk dey pay the price. apt upgrade go sit down for Unpacking for minutes, sake of say dpkg dey flush as e dey write. git status for big repository go take seconds. These ones na metadata and flush costs, so more bandwidth no go help.

Wetin you go do if disk space don full

Buy RAM before you buy IOPS. If your working set fit enter inside page cache, read operations no go reach disk at all. To double your memory dey always better pass make you move go faster storage class, and e dey cost small money.

Reduce the number of flushes, if the data allow am. For PostgreSQL, synchronous_commit = off dey allow commit return before the write reach disk. You fit lose the last small part of transactions if the server crash. The database no go corrupt, because write-ahead log still dey written in order. That trade-off dey okay for analytics copy but e no good for payments. innodb_flush_log_at_trx_commit = 2 for MySQL na the same trade-off.

Batch small files. If you wan transfer or backup one million small files, the cost per file go too much. So, make you archive dem first and move one stream; e dey faster for high-latency storage pass make you copy the tree file by file.

Make sure discard dey work for thin volumes. For thin provisioned storage, the backend no dey know say block dey free until the filesystem talk so. Volume wey you no ever trim go slow down for write performance. Ubuntu get weekly timer for this:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av dey print the bytes wey dem trim per mount point. If you see message say discard operation no dey supported, e mean say virtual disk no dey pass discard go the host, so nothing dey for you to fix.

No waste time dey tune IO scheduler. For virtio disk, cat /sys/block/vda/queue/scheduler usually show none already, and the real scheduling dey happen for host, wey you no get access to. Skip noatime too: Ubuntu dey mount with relatime by default, wey don already avoid almost every atime write.

How to choose plan

Pay for NVMe if database, mail server, CI runner or build wey get plenty package dey run for di box. No pay extra money for website wey dey use cache or app wey dey spend time dey wait for external calls. If you no sure, disk no be your problem, because most small VPS workloads dey finish RAM or bandwidth first.

Measure am for day one, as you dey follow di first ten minutes for new VPS, and keep di output for file. Baseline na wetin you go use prove later say di host don slow, no be say your code get problem. Prefer providers wey write down di storage class and any IOPS cap clearly. If plan talk say NVMe and queue depth 1 read take 4 ms, you dey use network storage for host wey get NVMe. Dat one na fair tin to sell, but e different from wetin you wan buy.

FAQ

NVMe dey always fast pass SATA SSD for VPS?

No. For queue depth 1, di two of dem dey close, e dey around 80 to 150 microseconds for 4k read, and one single-threaded program no go fit know di difference. NVMe dey show power when many requests dey fly at di same time, because AHCI get one queue wey fit hold 32 commands, but NVMe get thousands of queues wey deep pass. For shared host, load from oda guests fit affect your latency pass di storage medium itself, so make you measure your own volume wit fio instead of to dey look di plan name.

How I go take check weda my VPS truly dey use NVMe?

You no fit check am directly, because virtio dey hide di physical device. lsblk go show vda wit no model string, nvme list no go return anything, and /sys/block/vda/queue/rotational go only report wetin di hypervisor show am. Make you measure di behaviour instead. If queue depth 1 random 4k read dey under 0.3 ms, e mean say na local flash. If e reach several milliseconds, e mean say network hop dey di path. Sequential reads wey stop near 550 MB/s show say na SATA link.

NVMe dey make my website load fast?

Most times, no. After di first request, Linux dey serve di files from page cache for RAM, so di disk go just dey idle. Page speed for small VPS usually depend on application CPU time and bandwidth. Di disk go come back to critical path if di site dey write for every request, like database-backed cart wey dey commit often, because every commit must wait for flush to finish.

Wetin be good fio result for VPS?

As of July 2026, small VPS on local flash usually dey return tens of thousands of 4k random read IOPS at queue depth 32, wit queue depth 1 latency wey dey under 0.3 ms. Network block storage usually dey return few thousand IOPS at latency of few milliseconds. Run di test three times for different hours. Wide difference between di runs go tell you pass di average, because e go show you how much oda guests for di host dey affect you.

I suppose put my database for network block storage?

You fit, and many managed services dey do am, but di commit path go pay for am. Every flush must cross di network, so one connection go commit fewer small transactions per second pass wetin e for do for local flash. You go get durability wey go survive even if di host spoil. If you choose network storage for database wey dey write plenty, make you group work into larger transactions so say fewer flushes go carry more rows.