IOPS, Throughput & Latency Explained (2026 UK Guide)

The Storage Performance Triad: Three Different Questions

A storage datasheet is really answering three separate questions, and confusing them is the most common mistake buyers make. IOPS answers 'how many operations can this complete per second?' — it counts completed read and write operations, not the amount of data involved. Throughput answers 'how much data can move per second?', typically expressed in bits or bytes per second. Latency answers 'how long does one operation take?' — the time a storage subsystem needs to process a single request or transaction.

These three sit together because storage vendors and independent practitioners consistently treat them as the core measurement set for any storage system — one explainer groups them explicitly as the three core metrics of storage performance. None of the three tells the full story alone; a device can post an excellent IOPS figure and still feel slow if latency under real conditions is poor, or move huge volumes of data per second while completing relatively few operations if those operations are large.

• •IOPS — operations completed per second, independent of data volume
• •Throughput — data volume moved per second, usually in bytes/sec
• •Latency — time taken to process a single request or transaction

The Formula That Ties Them Together — and Why Latency Caps IOPS

The three metrics aren't independent — they're connected by a simple formula: throughput equals IOPS multiplied by block size. This is stated directly by vendor and practitioner sources alike, and it's the single most useful equation in storage sizing. If you know the average I/O size a workload uses and the IOPS a device can sustain at that size, you can derive the throughput it will actually deliver — and vice versa.

This is also why block size matters more than either headline number on its own. A device tested at a small block size (say 4KB) and one tested at a much larger block size (say 64KB) can report identical IOPS but produce throughput figures that differ by an order of magnitude, purely because of the multiplication — not because the underlying hardware changed at all.

Latency is the other half of the constraint. Because IOPS is only meaningful alongside a latency figure, and because each operation physically takes a finite amount of time to complete, latency effectively caps how many operations a device can process per second under a given level of concurrency. Lower latency per operation means more operations can complete in the same second; higher latency drags the achievable IOPS down even if the theoretical maximum on a spec sheet looks impressive.

Matching the Numbers to What Your Application Actually Does

Storage performance metrics are workload-dependent — the same device can look fast in one test and slow in another purely because of how it's exercised. Throughput is especially relevant for large sequential files, while IOPS and latency dominate for small, random operations. That single distinction explains most of the confusion buyers run into when comparing quoted numbers across different product types.

Databases issue frequent small, random reads and writes, so they're IOPS- and latency-bound: a transaction system waiting on individual row lookups cares far more about how quickly each operation completes than about raw megabytes-per-second. Media streaming and backup jobs are the opposite — they move large sequential blocks, so throughput is the metric that actually determines whether a job finishes in time. Virtual desktop infrastructure (VDI) sits awkwardly in between: normal usage is bursty and random, but boot or logon storms create sudden concentrated demand that stresses IOPS and latency simultaneously. File servers are typically mixed, with performance needs shifting depending on whether users are opening many small documents or a handful of large files.

This is also where architecture choices matter: how storage is presented — as a SAN, NAS or DAS, or over NVMe rather than legacy protocols — changes which of the three metrics is easiest to scale. If you're comparing platform types, it's worth reading how to learn about SAN, NAS, and DAS performance differences and how to understand NVMe technology before assuming a faster-sounding protocol solves a latency problem it was never designed to fix.

Decoding the Datasheet: What Vendors Don't Put in Bold

Marketers often quote only the maximum throughput number — the amount a drive can read or write per second under the easiest possible workload. That figure is real, but it's rarely representative of production behaviour, because production I/O is almost never 100% sequential, 100% read, or run at the ideal queue depth the test used.

The same caution applies in reverse to peak IOPS claims: they typically reflect an idealised workload, not general-purpose performance. Treat any 'maximum throughput' or 'peak IOPS' figure as a best-case number, not a guarantee. It's equally important not to mix read IOPS, write IOPS and mixed-workload IOPS as if they were the same measurement — a device's read-only figure tells you nothing reliable about its behaviour under a realistic read/write mix. Latency claims need the same scrutiny: average latency, 95th-percentile (p95) latency, and true end-to-end request time are three distinct measurements, and a vendor quoting the most flattering one won't necessarily say which it is.

For UK buyers, the practical response is to treat every datasheet as a workload contract rather than a universal speed claim. Before comparing SSDs or arrays, ask for the test block size, the read/write mix, the queue depth, and the latency distribution behind the headline figure. This matters beyond simple value-for-money: public-sector and regulated buyers increasingly need evidence that a system will meet application SLAs and security and resilience requirements as part of broader UK cybersecurity expectations, and a datasheet without those parameters can't provide that evidence.

• •What block size was used to generate this IOPS or throughput figure?
• •Is this read-only, write-only, or a specific mixed workload — and what mix?
• •Is the latency figure an average, a p95 tail figure, or end-to-end request time?
• •Was the number measured per drive or across an entire array? This isn't always spelled out on the datasheet itself, but checking it is standard industry practice, since array-level and single-drive figures are not directly comparable.

Worked Examples: Turning the Formula Into a Decision

Example 1 — sizing from a throughput target. Suppose an application team specifies a required sustained data rate rather than an IOPS number. Using the formula IOPS = throughput ÷ block size, the same throughput target translates into very different IOPS requirements depending on the block size the application actually uses. A workload issuing small 4KB operations needs far more IOPS to hit a given throughput than a workload issuing large 64KB operations to reach the same data rate — because each larger operation moves more data per completed I/O. This is precisely why a device's rated IOPS at one block size cannot be assumed to hold at another; run your own workload's expected block size through the formula (you can calculate IOPS and throughput directly) rather than accepting a vendor's single reference point.

Example 2 — interrogating a datasheet. A spec sheet lists one bold IOPS figure and stops there. Step one: check whether a block size is stated anywhere in the small print — if not, the number cannot be compared to anything else. Step two: check whether it's a read, write, or mixed figure, since these are never interchangeable. Step three: find the latency the IOPS figure was measured at, and whether it's an average or a tail (p95) value — a high IOPS number achieved only at unacceptably high latency isn't usable in a latency-sensitive application. Step four: as a matter of general industry practice rather than a formally documented rule, check whether the figure applies to a single drive or an entire array, since multiplying single-drive numbers by drive count rarely reflects real array-level behaviour. Only once all four points are answered is the headline figure actually comparable to a competing product.

Troubleshooting Storage Bottlenecks By Symptom

Because the three metrics are formally linked, performance complaints usually point to a bottleneck in one specific metric — the trick is reading the symptom correctly rather than reacting to whichever number looks lowest.

• •High latency with small random reads and modest data volume — an IOPS-bound problem: the device is struggling to complete individual operations fast enough, not to move data volume; the fix is faster media or reduced contention, not more bandwidth.
• •Stable, low per-operation latency but a hard ceiling on large sequential transfers — a throughput-bound problem: the interconnect or backend path is saturated even though each individual request looks fine in isolation.
• •Latency climbing sharply as concurrent requests increase, without throughput ever reaching its ceiling — a queueing or contention problem: requests are waiting behind each other rather than the media itself being the limit.
• •An impressively large advertised peak IOPS figure that doesn't match real-world feel — a block-size mismatch: production I/O is very likely using a larger, or a mixed read/write, block size than whatever idealised condition the datasheet's peak figure was tested under.

A UK Buyer's Checklist for Storage Performance

The practical lesson for UK IT buyers is to stop comparing headline numbers and start comparing workload conditions. A cheaper device with genuinely lower latency can outperform a pricier one in real mixed workloads, but only a like-for-like comparison — same block size, same read/write mix, same queue depth — reveals that. Pricing quoted in pounds should always be weighed against the same workload profile, not against whichever vendor's headline IOPS figure looks biggest on the page.

This discipline matters most where procurement decisions have to be defensible: public-sector and regulated buyers need evidence that a storage platform will meet application SLAs and security and resilience expectations, not just a favourable benchmark slide. Before signing off any storage purchase, run the shortlisted options through the same set of questions and the same workload assumptions, and use a structured process to find the right storage solution rather than ranking by price-per-terabyte or price-per-IOPS alone.

• •Demand block size, read/write mix, queue depth and latency distribution for every quoted figure
• •Never compare read-only IOPS against a competitor's mixed-workload IOPS
• •Treat 'maximum throughput' and 'peak IOPS' as best-case, not typical
• •Match the dominant metric (IOPS/latency vs throughput) to your actual application type before comparing price
• •Keep evidence of test conditions on file for SLA and compliance sign-off

Sources

Every figure in this article traces to the sources below.

• •Park Place Technologies — IOPS, throughput and latency definitions
• •Klarasystems — vendor maximum-throughput claims and IOPS/throughput/block-size relationship
• •Louwrentius — why IOPS is meaningless without latency, and bandwidth derivation
• •Simply Block — throughput and latency definitions and formula
• •dev.to (AWS Builders) — latency, throughput and workload-dependency definitions
• •Spectra — the three core storage performance metrics
• •Komprise — IOPS definition