VPS Storage Explained: SSD, NVMe, Space, and IOPS

Check storage capacity and storage performance separately. Enough gigabytes will not prevent a database from waiting on disk operations, and an NVMe label does not describe the limits imposed on your VPS.

Capacity is not speed#

Gigabytes measure capacity: how much data the disk holds. That includes the operating system, your application code, uploaded images, email, and every row in your database. Throughput, measured in megabytes per second, describes how fast large chunks of data move. IOPS, or input/output operations per second, counts how many small reads and writes the storage completes each second. AWS documents all three in its block storage guide because they vary independently: a volume can be large and slow, or small and fast.

For a website, capacity is rarely the constraint. Most sites need a few tens of gigabytes, and a plan with generous space but poor IOPS will still feel sluggish under load.

SATA SSD and NVMe#

Many VPS plans use solid-state storage, but HDD-backed offerings still exist, so verify the storage type. For SSD-backed plans, the interface differs and helps set the performance ceiling. A SATA SSD attaches through a connection originally designed for mechanical hard drives. It is far quicker than a spinning disk, but it inherits that legacy interface's bandwidth limits and its shallow command queue, a short list of operations it can keep in flight at once.

NVMe, by contrast, was designed for flash memory and speaks directly over the PCI Express bus. The NVMe standards body's primer describes the key difference: thousands of parallel command queues rather than one or two. More queues mean more simultaneous operations, lower latency, and much higher IOPS. In practice, an NVMe-backed VPS handles many concurrent small reads and writes with far less waiting.

Why IOPS matter for a website#

Static assets are easy on storage. Images, stylesheets, and scripts are read sequentially and are usually cached in memory after the first request. Your storage barely notices them.

A rough way to picture the difference: throughput is like a motorway with wide lanes, useful for lorries carrying big loads, while IOPS is like the number of toll booths, which decides how many small vehicles get through per minute. A website mostly sends small vehicles.

Relational databases behave differently. MySQL and PostgreSQL constantly perform small, random reads and writes: updating session records, checking indexes, writing rows. Under concurrent traffic these operations stack up, and the time the database spends waiting for storage becomes time your visitor spends waiting for a page. NVMe shortens those wait states, which is why database-heavy sites notice the difference between storage types more than static brochure sites do.

Choosing storage for your project#

Start by separating the two questions. Estimate capacity by adding your operating system, application, uploads, and database size, then add headroom, because a disk that runs nearly full causes problems of its own. Then consider your access pattern. If your site is mostly static pages with light database use, any reputable SSD storage will serve it comfortably. If you run an online shop, a forum, or anything else with frequent database writes, favour providers that specifically advertise NVMe storage.

Ask providers what storage they use when the plan page does not say. It also helps to ask whether storage is network-attached or local to the host, since that affects performance and, in some setups, whether the disk survives a host failure.

Habits that keep storage healthy#

Storage problems usually develop quietly. Rotate or archive logs instead of letting them grow indefinitely. Keep an eye on database size and clean up stale data such as abandoned sessions and old records. Watch your disk usage graph so you can clean up or upgrade before the disk fills rather than after the database fails to write.

Knowing what happens when a disk fills is useful too. Processes that need to write, including database engines and log daemons, begin to fail in confusing ways long before the operating system reports anything obvious. Treating eighty percent full as your action threshold avoids most of that confusion.