When people evaluate WordPress hosting, they look at RAM, CPU cores, and bandwidth. Storage type rarely comes up. That is a mistake, because the drive your hosting runs on has a direct impact on how fast your site loads, how quickly your database responds, and how your site holds up under traffic.
This post explains what NVMe is, how it differs from older storage types, and why it matters specifically for WordPress.
The three storage types you will encounter
HDD (Hard Disk Drive)
Traditional spinning disk. A physical platter rotates and a read/write head moves across it to find data. The mechanical movement creates latency measured in milliseconds. HDDs are cheap and offer large capacities, which is why budget shared hosting still uses them. For a database-driven application like WordPress, the latency adds up fast.
SATA SSD (Solid State Drive)
No moving parts. Data is stored on flash memory chips and accessed electronically. Dramatically faster than HDD for random reads, which is the access pattern WordPress uses constantly. The limitation is the interface – SATA was designed for spinning disks and caps throughput at around 550 MB/s.
NVMe (Non-Volatile Memory Express)
NVMe is also flash memory, but it uses the PCIe bus instead of the SATA interface. PCIe has significantly higher bandwidth and lower latency than SATA. Sequential read speeds reach 3,500 MB/s or higher on modern NVMe drives – roughly 6x faster than SATA SSD. More importantly for hosting workloads, random read IOPS (input/output operations per second) are substantially higher, and latency per operation is lower.
All Hostney servers run NVMe storage.
Why storage type matters for WordPress specifically
WordPress is not a static site. Every page load involves multiple moving parts:
- PHP loads and initializes WordPress core
- WordPress queries the database for posts, options, and metadata
- The database reads data from disk into memory
- PHP assembles the response and sends it to Nginx
- Nginx serves it to the visitor
Steps 2 and 3 are where storage speed matters most. MySQL keeps frequently accessed data in its buffer pool (memory), but the buffer pool has a size limit. Data that does not fit gets read from disk on demand. The faster the disk, the faster that read completes.
On a site that is not fully cached, every uncached page load involves disk reads. On a site under traffic that exceeds its cache hit rate, the database is reading from disk constantly.
Database performance
WordPress sites make a lot of small, random database reads. A typical page load can involve dozens of queries – options table, post meta, user data, plugin settings. These are small reads scattered across the database rather than large sequential reads. Random I/O performance is where NVMe has the largest advantage over SATA SSD and an enormous advantage over HDD.
Lower storage latency means faster query execution for reads that miss the buffer pool. On a shared server with many sites active simultaneously, the cumulative effect is significant.
PHP file loading
WordPress core consists of hundreds of PHP files. When a request comes in, the PHP process loads and compiles the relevant files. PHP’s OPcache stores compiled bytecode in memory to avoid re-reading files on every request, but OPcache has limits and cold starts still hit the disk.
Plugin-heavy WordPress installs load a large number of files per request before OPcache warms up. On NVMe, the file reads that miss OPcache complete faster.
Traffic spikes and concurrent requests
Under normal load, a well-configured server with a full-page cache serves most requests from memory without touching disk at all. The storage advantage becomes most visible when:
- The cache is cold (after a server restart, after clearing cache)
- Traffic exceeds the cache hit rate and the database gets hammered
- A bot or crawler is hitting uncached URLs at high volume
- A WooCommerce store is processing many concurrent transactions
In these scenarios, the disk becomes a bottleneck. NVMe reduces that bottleneck compared to SATA SSD, and eliminates it compared to HDD.
What this means in practice
The storage type alone will not make a slow WordPress site fast. A poorly optimized site with missing indexes, unoptimized images, and no caching will be slow on NVMe just as it would be on SATA SSD. The gains from NVMe are at the infrastructure level – they raise the ceiling on what the server can handle before storage becomes the limiting factor.
For well-optimized sites, the practical difference is most visible in:
- Time to first byte (TTFB) on uncached pages – you can measure this with SiteProbe, a free speed test tool that shows DNS resolution, TLS handshake, TTFB, and total load time
- Database response times during traffic spikes
- Admin panel responsiveness, which bypasses page cache
- WooCommerce checkout and cart operations, which cannot be fully cached
The WordPress admin in particular benefits noticeably from faster storage because admin pages are almost never cached and involve significant database activity.
Checking your current setup
If you are on a hosting plan and want to know what storage type your server uses, ask your provider directly. “What storage type do your servers use?” is a reasonable question. If the answer is HDD or they are vague about it, that is worth factoring into your hosting decision.
Budget shared hosting on HDD is common. Some hosts advertise SSD without specifying whether it is SATA or NVMe. The distinction matters – NVMe is not just a faster SSD, it is a different interface with meaningfully lower latency for the random I/O patterns that WordPress generates.
Summary
Storage type affects WordPress performance at the database layer, the file system layer, and under concurrent load. HDD is the slowest due to mechanical latency. SATA SSD is significantly faster but limited by its interface. NVMe offers the lowest latency and highest IOPS, which benefits WordPress most during uncached requests, traffic spikes, and database-heavy operations like WooCommerce transactions.
The effect is not always visible on a single page load with a warm cache. It becomes visible at the infrastructure level – how many concurrent requests the server handles cleanly, how fast the database responds when the buffer pool misses, and how quickly the site recovers after cache is cleared.