IOPS (input/output operations per second) is the number of read and write operations a storage device or system completes each second. In server storage, IOPS is the key performance metric for workloads made of many small, random requests, such as databases, virtual machines and mail servers, where the speed of individual operations matters more than raw transfer rate.
An IOPS figure is meaningless without its conditions. The result depends on block size, the ratio of reads to writes, random versus sequential access and the queue depth, the number of requests waiting at once. Two devices rated at the same IOPS can behave very differently under a real workload.
How IOPS relates to throughput and latency
IOPS is one of three linked storage metrics. Throughput, measured in MB/s, equals IOPS multiplied by block size, so 10,000 IOPS at 4 KB is about 40 MB/s, while the same IOPS at 128 KB is about 1.3 GB/s. Latency is the time to complete a single operation, usually in microseconds or milliseconds.
Latency and queue depth together determine IOPS. By Little’s law, IOPS is roughly the number of outstanding requests divided by average latency: a device with 0.1 ms latency at queue depth 1 completes about 10,000 IOPS, and it can reach far more only if it processes many requests in parallel. Applications that issue one request at a time never see the headline IOPS printed on a datasheet.
| Metric | What it measures | Unit | Dominant for |
|---|---|---|---|
| IOPS | Operations completed per second | Operations per second | Databases, virtual machines, small files |
| Throughput | Data moved per second | MB/s or GB/s | Backups, video, large sequential files |
| Latency | Time per operation | µs or ms | Transactional and interactive workloads |
| Queue depth | Requests outstanding at once | Count | How much parallelism a workload offers |
Typical IOPS by storage type
The gap between storage technologies is several orders of magnitude. Spinning disks are limited by mechanical seek time and rotation, while flash devices are limited by controller design, interface and parallelism. The ranges below refer to random 4 KB operations; exact values vary widely between models.
| Device | Approximate random IOPS | Typical latency | Limiting factor |
|---|---|---|---|
| 7,200 rpm HDD | About 75-100 | Several ms | Seek time and rotation |
| 15,000 rpm HDD | About 175-210 | Few ms | Seek time and rotation |
| SATA SSD | Tens of thousands | Around 0.1 ms | SATA interface and AHCI single queue |
| NVMe SSD | Hundreds of thousands or more | Tens of µs | Controller and flash parallelism |
| Cloud block volume | Set by the volume tier or size | Sub-ms to few ms | Provider limits and network |
Datasheet values are measured at high queue depths and often on an empty drive. Sustained write IOPS on consumer SSDs can drop sharply once the SLC cache is full or garbage collection runs, which is why enterprise drives specify steady-state performance.
How RAID and storage layers change IOPS
Storage layers such as RAID, LVM and ZFS change the IOPS a server actually delivers. Reads usually scale with the number of disks, but writes carry a RAID write penalty: each logical write causes several physical operations to keep redundancy consistent.
| RAID level | Physical operations per write | Read IOPS scaling | Write IOPS impact |
|---|---|---|---|
| RAID 0 | 1 | All disks | No penalty, no redundancy |
| RAID 1 and RAID 10 | 2 | All disks | Half of raw write IOPS |
| RAID 5 | 4 | All disks | A quarter of raw write IOPS |
| RAID 6 | 6 | All disks | A sixth of raw write IOPS |
Caching changes the picture again. A battery- or flash-backed controller cache absorbs bursts of writes, and the ZFS ARC cache serves repeated reads from RAM. Such caches raise measured IOPS until the working set exceeds cache size, after which performance falls to the speed of the underlying disks. Network storage such as NAS or block storage over iSCSI adds network latency to every operation.
Measuring and sizing IOPS
Sizing starts with measuring the real workload, not with datasheets. Tools such as iostat show current operations per second, average request size and latency per device, and a benchmark tool such as fio reproduces a defined pattern under controlled conditions.
| Workload | Block size | Access pattern | Read and write mix |
|---|---|---|---|
| OLTP database | 8-16 KB | Random | About 70 percent reads |
| Virtual machine host | 4-64 KB | Mostly random | Mixed, write-heavy at boot |
| Mail server | 4-16 KB | Random | Write-heavy |
| Backup target | 256 KB-1 MB | Sequential | Mostly writes |
| Log ingestion | 4-64 KB | Sequential append | Mostly writes |
When sizing, add the RAID write penalty to the measured write rate, plan for peak hours rather than averages, and keep headroom of 20-30 percent. Always report IOPS together with the latency at that load; a system that reaches its IOPS target only at 50 ms latency is already saturated.
Common misconceptions about IOPS
IOPS figures are easy to compare and easy to misread. The most frequent errors are:
- Comparing IOPS across different block sizes, which compares unrelated numbers.
- Ignoring queue depth, although single-threaded applications run near queue depth 1.
- Trusting burst figures on cloud volumes and consumer SSDs that cannot be sustained.
- Forgetting the RAID write penalty when converting disk counts into usable write IOPS.
- Treating high IOPS as low latency, although a busy device can deliver both high IOPS and slow responses.
Put simply
IOPS counts how many small jobs a storage drive can finish every second. Each job is reading or writing one small piece of data. A spinning hard drive manages around a hundred of these per second, while a modern flash drive can handle hundreds of thousands.
Think of a checkout at a shop. Throughput is how many items pass through in total, while IOPS is how many separate customers are served. A database with thousands of small requests needs many fast checkouts, not one very wide conveyor belt.
In practice
A company runs its accounting database on a server with eight 10,000 rpm disks in RAID 5. At month-end, users report that reports and postings take minutes. Monitoring with iostat shows about 600 IOPS at a 75 percent read mix, with average latency above 40 ms.
The administrator calculates the load: about 450 reads plus 150 writes, which RAID 5 turns into 600 physical write operations, about 1,050 physical operations in total. The eight disks deliver roughly 1,100-1,200 IOPS together, so the array runs at its limit and requests queue up.
The team moves the database to four NVMe SSDs in RAID 10. Month-end processing now runs at the same IOPS with latency below 1 ms, and the remaining headroom covers several years of growth.