What is the IOPS metric, and how does it affect performance?

Definition#

IOPS, input/output operations per second, counts how many individual read or write operations a storage device completes each second, regardless of their size. It is one of the three numbers that jointly describe storage performance, and they measure different things:

• IOPS: how many operations per second (the count).
• Throughput (MB/s): how much data per second (the volume).
• Latency (ms or µs): how long one operation takes (the wait).

They're related, throughput ≈ IOPS × operation size, but they diverge hard in practice, and knowing which one your workload needs is the entire skill.

Why the same disk gives wildly different numbers#

Copying one large file is sequential I/O: few, large operations. A busy database is random I/O: thousands of tiny reads and writes scattered across the disk. The same storage that streams hundreds of MB/s sequentially may deliver a small fraction of that volume under random load, not because it's slow, but because the cost per operation dominates when operations are small and scattered.

This is why the two classic workload families feel storage so differently:

• Throughput-bound: file copies, backups, video serving, streaming logs. They want MB/s; IOPS barely matters.
• IOPS-bound: databases, mail servers, busy CMSes, anything doing many small reads/writes, the workloads that feel "slow" while CPU and RAM sit idle. They want operations per second and low latency; headline MB/s is nearly irrelevant to them.

Latency: the third leg that explains the feel#

Every operation takes time, and for synchronous operations, a database committing a transaction, a filesystem journal write, the application waits for each one. At 1 ms per operation, a single thread caps at ~1,000 sequential operations per second no matter how much parallel capacity the device has. This is why storage latency shapes how fast a single query feels, while IOPS capacity shapes how many queries can run at once, and why high %wa (I/O wait) in top with idle CPU is the signature of a storage-bound workload.

What NVMe changed#

Spinning disks managed ~100-200 IOPS (a physical head had to move); SATA SSDs brought tens of thousands; NVMe (which our plans run on) delivers hundreds of thousands with far lower latency. The practical consequence: on NVMe, storage stopped being the default bottleneck for typical workloads, when a modern VPS is slow, the cause is usually elsewhere, and an actually IOPS-bound service on NVMe usually indicates something amplifying its I/O (a missing index forcing full-table scans is the classic, the slow-query section covers it).

Reading your own numbers#

• Your VPS's Graphs plot Disk IOPS (read/write) and Disk Throughput separately, high IOPS with modest MB/s = random/small-operation load (database-shaped); the reverse = bulk transfer.
• Live, per-process: iostat -x 2 (the %util and await columns: how busy, how long each operation waits) and iotop for the culprit process.
• Benchmarking honestly requires matching the test to the question: fio can measure sequential throughput or random 4K IOPS, and the two results will differ by orders of magnitude on the same disk, a benchmark that doesn't state its operation size and randomness measures nothing in particular.

Still need help?#

You can open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP,
• what the Graphs' IOPS and throughput charts show, and the workload behind them.

Related questions#

• "What's the difference between IOPS and MB/s?"
• "Why is my database slow when disk throughput looks fine?"
• "What does high iowait mean?"
• "What are good IOPS numbers on NVMe?"
• "How do I see my VPS's IOPS usage?"