Storage, Measured
NVMe vs SSD hosting — the gap lives in queue depth, not on the spec sheet
Both are flash, both get called SSD in marketing, and one of them answers a database query roughly an order of magnitude sooner. This page shows where that actually surfaces on a real site.
The short answer
NVMe is the right default, and the honest reason is narrower than the adverts suggest: the measurable gap between NVMe and SATA SSD hosting appears under concurrent random reads — database queries, uncached page builds, busy admin areas — where NVMe's PCIe path and deeper command queues typically cut storage latency from around a hundred microseconds to tens.
A fully cached page will not show the difference, because it never touches the disk. The moments that are already the slow ones — logged-in users, carts, search, imports, backups — are precisely the moments that do. Buying NVMe is buying down your worst case, not your best.
By the HostingFast team · Reviewed 25 August 2026
~10×
Lower access latency than SATA, typically
64K
Command queues NVMe exposes; AHCI has one
4K
The random read size databases live on
6 Gbps
The SATA ceiling NVMe simply bypasses
Every host says SSD. The word has stopped carrying information, because it describes the flash memory and stays silent about the interface in front of it. A SATA SSD talks through a protocol designed for spinning disks, with a single command queue 32 entries deep. An NVMe drive talks straight to PCIe with tens of thousands of queues.
That difference is invisible in a sequential file copy and decisive under the workload a shared server actually runs: hundreds of tenants issuing small random reads at once. This page maps where the gap shows on a WordPress or WooCommerce site, where it does not, and how to measure it before you commit.
The interface is the bottleneck, not the flash
SATA tops out at 6 Gbps — roughly 550 MB/s after overhead — and its AHCI protocol offers one queue of 32 commands, a design inherited from mechanical drives that could only do one thing at a time anyway. The flash behind it is usually capable of far more than the pipe allows.
NVMe removes the pipe. The drive sits on PCIe lanes, speaks a protocol built for parallel flash, and exposes up to 65,536 queues of 65,536 commands each. Sequential throughput headlines aside, the number that matters for hosting is access latency: around 100 microseconds for a SATA SSD, tens of microseconds for NVMe.
Where a real site actually touches the disk
A WordPress request that misses the cache is a burst of small random reads: MySQL pulling rows for options, posts and meta, PHP files being located, sessions checked. Each read is tiny; a page assembles dozens of them, partly in sequence, so per-read latency multiplies straight into time to first byte.
Concurrency is the multiplier. On a shared machine, hundreds of accounts queue for the same storage. A single 32-slot SATA queue turns busy periods into a waiting line; NVMe's parallelism keeps per-request latency flat far deeper into the load curve. The same applies to the unglamorous jobs — backup runs, cache purges, product imports — that are pure small-file I/O.
Where you will not see the difference
A page served from LiteSpeed's cache comes out of memory; the disk is not consulted, so the storage under it is irrelevant to that request. Static assets behind a CDN are the same story. If your whole audience hits cached pages, NVMe changes little that you can measure at the browser.
That is not an argument against it — it is a map of where to look. The uncached minority of requests is where slow sites are actually slow: logged-in users, admin work, search, checkout. Judge storage by those paths, not by the homepage.
How to measure it yourself
On anything with shell access, fio or ioping will give you 4K random read latency directly; the difference between the two drive classes is not subtle. On shared hosting, measure by proxy: time an uncached page — a logged-in view or a search result — with curl's time_starttransfer, three runs, take the middle value.
Then time the admin dashboard and a plugin update. Those are the workloads with no cache to hide behind, and they are the ones you will feel every working day.
Every HostingFast plan sits on NVMe, including the smallest
We do not tier storage. Database latency sets a floor under every uncached request on the account, so putting the entry plans on slower disks would mean selling the worst latency to the people least equipped to diagnose it.
NVMe underneath, LiteSpeed in front: cached pages skip the disk entirely, and the requests that must touch it wait microseconds rather than milliseconds. That pairing is the whole speed argument, and both halves are on every tier.
- NVMe storage on every plan, not reserved for the top tier
- LiteSpeed serving cached pages before the disk is ever asked
- London platform, so UK round trips do not drown the disk gains
- 30-day money-back window — long enough to measure it under your own traffic
Why HostingFast
Standard on every plan
Latency where it compounds
Database reads answered in microseconds, which multiplies through every uncached page build rather than showing up once.
Flat under concurrency
Deep command queues keep per-request storage latency stable when the machine is busy — which is when visitors are actually watching.
Faster boring jobs
Backups, restores, imports and cache purges are small-file I/O. On NVMe they stop being something you schedule around.
Test it on our account, not our word
Migration is free and the money-back window is 30 days. Run your own uncached-TTFB numbers before and after.
Quick Start
From order to online
- 1
Find your uncached paths
Logged-in pages, search, checkout, admin. These are the requests that reach the disk, and the only fair test bench for storage.
- 2
Benchmark where you are now
curl with time_starttransfer against an uncached URL, three runs, middle value. Note the admin dashboard feel while you are there.
- 3
Migrate free and re-run the same test
Same URLs, same tool, same time of day. If the numbers do not move, the money-back window means the experiment cost you nothing.
Built In
Loaded onto every plan
- NVMe on every tier — confirm it in writing, since 'SSD' alone tells you nothing about the interface
- LiteSpeed cache in front, so the disk only answers the requests that genuinely need it
- Uncached TTFB measured, not assumed: three runs, middle value, on a logged-in or search URL
- 4K random read latency is the figure that predicts database feel — not sequential MB/s
- Admin dashboard and plugin updates timed before you judge — they are pure uncached I/O
- Daily backups included, and quick to restore, because backup speed is a storage property too
Frequently Asked
What people ask us most often
Will NVMe make my cached pages faster?
Barely. A cached page is served from memory and never consults the disk, so storage class is irrelevant to that request. NVMe pays off on the requests the cache cannot answer — logged-in users, search, checkout, admin — which are usually the slowest paths on the site already.
How much faster is NVMe in practice?
Per-read access latency is typically around ten times lower than a SATA SSD — tens of microseconds against roughly a hundred. An uncached page assembles dozens of reads, partly in sequence, so the saving compounds into a visibly quicker time to first byte on database-heavy pages, especially when the server is busy.
Does NVMe matter on shared hosting, where I share the drive anyway?
More there than anywhere. Shared storage means shared queues, and SATA's single 32-command queue is exactly what backs up at peak times. NVMe's parallelism is what keeps one tenant's import from becoming everyone else's slow afternoon.
How can I check what storage a host really uses?
Ask directly and get it in writing — 'SSD' in marketing can lawfully mean SATA. With shell access, cat /sys/block/*/queue/rotational and the device names (nvme0n1 against sda) settle it. Without shell access, an uncached-page TTFB comparison at a busy hour is the honest proxy.
Does NVMe help a WooCommerce store specifically?
Yes, disproportionately. Carts, checkouts and stock lookups are uncacheable by nature, so a store lives on exactly the random-read path where NVMe is strongest. It is the difference between checkout latency you notice and checkout latency you do not.
Keep reading
Web hosting on NVMe
Every plan on NVMe with LiteSpeed in front — the pairing this page argues for.
WordPress hosting
Where uncached database reads decide how the admin side of your day feels.
Server cache vs plugin cache
The other half of the request path: what answers before the disk is asked.
Hosting glossary
IOPS, TTFB, queue depth and the rest of the vocabulary, defined without spin.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Put your database on NVMe and time the difference
Free migration, LiteSpeed in front, NVMe underneath every plan — and a 30-day window to measure it under your own traffic before the decision is final.
View Web hosting on NVMe plans