IOPS and MB/s measure different parts of SSD performance

IOPS counts completed input/output operations per second. MB/s measures how much data moves per second. The bridge between them is the amount of data in each operation, so an IOPS number without block size is incomplete.

Updated 27 August 2026 · Source-checked against SNIA SSD performance guidance

IOPS counts operations, not bytes

SNIA describes SSD workloads using several separate attributes, including block size, IOPS, throughput, latency, and queue depth. That separation matters because an individual I/O operation can be small or large.

If a benchmark completes 100,000 operations every second, it has measured 100,000 IOPS. But that number alone does not say whether each operation moved 4 KiB, 16 KiB, 128 KiB, or another amount of data. A small-block random workload and a large-block sequential workload can therefore produce very different IOPS and MB/s results even on the same SSD.

MB/s measures a data rate

MB/s is a byte-rate measurement: how many megabytes of data move each second. Storage product pages commonly emphasize sequential read or write MB/s because large sequential transfers can move substantial data with relatively few operations.

For workloads made of many small requests, IOPS and latency often become more useful because the device must complete a large number of individual commands. Neither metric is universally better. They describe different views of the workload.

The basic conversion is IOPS × block size

If every completed operation moves the same amount of data, the arithmetic relationship is straightforward:

For example, a 4 KiB operation contains 4,096 bytes. At 100,000 IOPS:

100,000 × 4,096 = 409,600,000 bytes/s = 409.6 MB/s

This is a mathematical conversion of the workload, not a prediction that a particular SSD will deliver those numbers. The measured IOPS and block size must come from the same test condition for the conversion to mean anything.

Why the block size changes everything

The table deliberately holds IOPS constant to expose the arithmetic. A real drive normally does not preserve one fixed IOPS number across all of these block sizes. At larger transfers, the device or interface can become bandwidth-limited before it can complete the same number of operations per second.

That is why a benchmark chart must attach a block size to an IOPS result. “1,000,000 IOPS” is not a complete workload description by itself.

Small random I/O and large sequential I/O stress different things

SNIA's SSD performance material uses small random requests and large sequential requests as examples of different workloads. A small random test asks the SSD to find and complete many individual operations. A large sequential test gives each operation much more payload and is often used to expose sustained data-rate limits.

That difference explains a common product-sheet pattern: an SSD may advertise a very large sequential read number in MB/s and a separate random 4K read number in IOPS. Those are not two ways of reporting the same test. They are different workload shapes.

Queue depth is another missing condition

Queue depth describes how many commands are outstanding and waiting to be serviced. SNIA includes demand intensity, such as outstanding I/O and queue depth, in its SSD performance methodology because an SSD controller can exploit parallelism when more than one request is available.

A high-queue-depth benchmark can therefore produce much higher aggregate IOPS than a lightly queued interactive workload. That does not make the benchmark false; it means the number belongs to that test condition. When comparing two IOPS claims, check whether the block size, read/write mix, access pattern, thread count, and queue depth are comparable.

Latency answers a different question again

Latency is the time required to service an operation. IOPS describes completed operations over time, while latency describes how long individual operations take. A device can achieve high aggregate IOPS by handling many requests concurrently even though the latency of each request is not the smallest possible.

This is especially important for desktop responsiveness. A benchmark that maximizes throughput with many outstanding requests does not automatically describe how quickly a single lightly queued request will complete. SNIA therefore treats IOPS, throughput, and latency as separate performance measurements rather than collapsing them into one score.

Read and write IOPS are not interchangeable

SSDs can behave differently under reads, writes, and mixed workloads. Writes require flash-management work that reads do not, and sustained writing can interact with spare area, garbage collection, cache behavior, and drive fullness.

SNIA's performance methodology uses read/write mixes for this reason. When a product lists “up to” random IOPS, verify whether the figure is for reads, writes, or a mixed workload. A maximum random-read result should not be treated as a universal IOPS rating for every operation the drive can perform.

Why an interface ceiling still matters

The IOPS × block-size equation can produce a data rate above the transport link's practical capacity. That simply means the hypothetical IOPS and block-size pair cannot both be sustained through that path at the same time.

For a PCIe NVMe SSD, the PCIe generation and lane count establish an encoded link ceiling before protocol overhead and device limitations. See PCIe generations and lane bandwidth for that arithmetic. For an M.2 drive, remember that M.2 is a form factor while NVMe and SATA describe different storage paths.

Do not mix MB/s with Mb/s

Storage performance is commonly written in MB/s with a capital B for bytes. Network and interface marketing often uses Mb/s or Gb/s with a lowercase b for bits. Eight bits make one byte, so the unit case changes the number by a factor of eight before any protocol overhead is considered.

If a storage benchmark and an interface specification appear to disagree wildly, first make sure the units match. The MB/s versus Mb/s guide shows that conversion separately.

Decimal MB and binary KiB can coexist in the same calculation

SNIA's SSD performance material notes that I/O block sizes are commonly expressed in KiB, where 1 KiB equals 1,024 bytes. Storage data rates, however, are frequently reported as MB/s. That creates a small but important unit-conversion step.

A 4 KiB I/O is 4,096 bytes, not 4,000 bytes. That is why 100,000 operations of 4 KiB each produce 409.6 decimal MB/s rather than exactly 400 MB/s. If a benchmark tool reports MiB/s instead, the numerical result will differ again even though the underlying byte rate is the same.

Drive fullness and cache state can change the result

SNIA emphasizes that SSD performance is workload-dependent and that results can change with drive state, free space, caching algorithms, and test preparation. Consumer benchmark results captured on a fresh or lightly used drive may not match long sustained workloads after caches are exhausted or the device is fuller.

That is another reason not to treat one peak IOPS or MB/s figure as a permanent speed property. A useful comparison asks what was measured, under what workload, and for how long.

A practical benchmark-reading checklist

1. Identify the metric. Is the claim IOPS, MB/s, or latency?
2. Find the block size. An IOPS number without bytes per operation cannot be translated into a data rate.
3. Check random versus sequential access. These workloads exercise the drive differently.
4. Check read, write, or mixed traffic. Do not compare a maximum read result with a sustained write workload.
5. Check queue depth and thread count. More outstanding work can increase aggregate parallelism.
6. Check the interface ceiling. A theoretical IOPS × block-size result cannot bypass the actual storage path.
7. Check test duration and drive state. Peak cached behavior and steady sustained behavior can be very different.
8. Compare like with like. Two benchmark numbers are meaningful together only when their workload conditions are sufficiently similar.

Worked comparison: two claims that look contradictory

Imagine an SSD product sheet lists 1,000,000 random-read IOPS at 4 KiB and 7,000 MB/s sequential read. The two claims are not inherently contradictory.

The 4 KiB IOPS figure corresponds to a theoretical payload rate of:

1,000,000 × 4,096 ÷ 1,000,000 = 4,096 MB/s

The 7,000 MB/s figure can come from a different sequential workload with much larger operations. The SSD completes fewer individual operations, but each operation carries far more data. The correct conclusion is not that one benchmark is wrong; it is that IOPS and MB/s belong to different test shapes.

IOPS is not an endurance rating

A high IOPS specification says nothing by itself about how much cumulative writing an SSD is rated to tolerate. Performance and write endurance are separate dimensions. For write-life ratings, see TBW versus DWPD.

Primary sources

• SNIA — What is an SSD?, for workload attributes including block size, IOPS, throughput, latency, queue depth, and the relationship between block size and throughput.
• SNIA — Solid State Storage Performance Test Specification, for the vendor-neutral SSD performance methodology and the separate IOPS, throughput, and latency test framework.
• SNIA — Understanding SSD Performance Using the SNIA SSS Performance Test Specification, for the workload matrix, KiB block-size convention, queue-depth context, and comparative-testing method.

Bottom line

IOPS tells you how many storage operations finish each second. MB/s tells you how much data moves each second. Block size connects the two, while access pattern, read/write mix, queue depth, latency, interface limits, cache state, and drive condition determine whether a benchmark result resembles your workload. Read the metric together with its test conditions instead of treating one headline number as the SSD's universal speed.