About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
Storage offers are described with a handful of figures: so many IOPS, so many megabytes per second, sometimes a latency. Two offers with the same headline IOPS can perform very differently for a business application, because the figures depend on each other and on how the test that produced them was run.
This article explains what each figure means, how they relate, and how to work out which one your application needs.
Why it matters
Paying for storage performance you do not use costs money every month. Buying too little makes the application slow in a way that more processors or memory will not fix. A specification is only useful if you can compare it with your own measurements.
How it works
The four figures
Microsoft's guidance on storage performance defines them:
- IOPS is the number of input/output requests per second. Microsoft describes it as the number of requests that your application is sending to storage disks in one second. Requests can be reads or writes, sequential or random.
- Throughput (or bandwidth) is the amount of data moved per second.
- Latency is the time one request takes to complete. Microsoft calls it a critical measure of an application's performance in addition to IOPS and throughput.
- I/O size (called block size in some specifications) is the size of each request.
How they relate
The four are linked. Microsoft's page gives a formula relating them: throughput equals IOPS multiplied by I/O size. Microsoft summarises the effect: Smaller I/O size yields higher IOPS. Larger I/O sizes give higher throughput.
A worked example: 5,000 IOPS at 8 KiB per request is about 39 MiB per second. The same storage moving 1 MiB requests might manage a few hundred IOPS yet several hundred MiB per second. A headline IOPS figure without the I/O size behind it cannot be compared with another.
Queue depth, the number of requests waiting at once, links IOPS and latency. Microsoft notes that larger queue depth gives higher IOPS and throughput, while Smaller queue depth yields lower latencies. A specification measured at a very deep queue can show high IOPS at a latency an interactive application would not tolerate.
Limits at more than one level
In cloud and hosted platforms, a disk and the virtual machine can each have their own limit. Microsoft's Azure page shows an example where a VM allows far more IOPS than its attached disks, so the application is capped at the disks' total. The reverse also happens: fast disks attached to a small VM are capped by the VM. Ask the provider which limits apply to the VM, to each disk and to the storage behind them.
Which figure an application needs
Microsoft's guidance contrasts workload types: transaction processing (a business application's database) sends many small, random requests and needs IOPS and low latency; reporting and data warehouses read large amounts and need throughput. SQL Server, Microsoft notes, chooses its own I/O size and queue depth; they cannot be set.
For a line-of-business application with interactive users, latency under its normal load is the figure users feel. Microsoft's Windows troubleshooting guidance treats average disk latency under 15 ms as healthy, with sustained periods above 25 ms as a warning. These are broad troubleshooting reference values, not a storage purchasing target or an application response-time promise. A database log or interactive workload may need tighter latency; choose its target from application requirements and measurements.
Measuring what you need
Windows Performance Monitor's LogicalDisk counters give each figure for your current server: Disk Reads/sec and Disk Writes/sec for IOPS, Disk Read and Write Bytes/sec for throughput, Avg. Disk sec/Read and sec/Write for latency, Avg. Disk Bytes/Read and Bytes/Write for I/O size, and Current Disk Queue Length. Record them over a full business cycle and work from the busy periods, not the average.
To test a candidate platform, Microsoft's DiskSpd tool generates a synthetic workload with a chosen I/O size, queue depth, read and write mix and duration. Microsoft describes it as having a difficult time emulating complex workloads, and recommends tests of at least 60 seconds. Set its parameters from your own measured I/O size and queue depth, not the provider's.
What to choose and why
Questions to ask a provider about any storage figure:
- At what I/O size, queue depth and read/write mix was it measured?
- What latency goes with that IOPS figure?
- Is it a limit, a typical value or a burst? Some platforms allow short bursts above the sustained figure.
- Which limit applies first: the VM, the disk, or shared storage?
- Is the figure per disk or per server, and does adding disks add performance?
Then compare the answers with your measured busy-period IOPS, throughput and latency.
A hypothetical comparison
Suppose measurements show the database volume's busy periods at 1,500 IOPS of mostly 8 KiB requests, about 12 MiB per second, at a queue length around 4. Offer A quotes 20,000 IOPS measured with 4 KiB requests at a queue depth of 64, with no latency given. Offer B quotes 5,000 IOPS at 8 KiB, with latency under 5 ms at a queue depth of 4.
Offer A's headline is larger, but it says nothing about latency at the queue depth this application uses. Offer B answers the questions that matter here. The figures are invented for illustration; the point is to compare offers at your own I/O size and queue depth.
Risks and limits
- Synthetic tests are not the application. Confirm with the real application on isolated test servers with synthetic data.
- Never run write tests on a volume holding live data. Use a test file on a test volume.
- Caching changes results. A test that fits in a cache measures the cache.
- Shared storage varies. Results at one time of day may not hold at another; see the companion article on noisy neighbours.
- No commands are given here. Microsoft's DiskSpd page explains the parameters.
Sources
Opened 14 November 2026.
- Microsoft Learn: Azure premium storage: design for high performance; displayed Last updated: 2024-08-22.
- Microsoft Learn: Virtual machine and disk performance; displayed Last updated: 2026-09-16.
- Microsoft Learn: Use DISKSPD to test workload storage performance; displayed Last updated: 2024-10-03.
- Microsoft Learn: Troubleshoot performance problems in Windows; displayed Last updated: 2026-02-12.
Related service: Cloud hosting.
Related future topics
- Sizing a business application server from measurements.
- Noisy neighbours in a shared cloud.
- Why the provider's dashboard and your server disagree.
Learning notes
- Throughput equals IOPS multiplied by I/O size; an IOPS figure without an I/O size cannot be compared.
- Deeper queues raise IOPS and latency together.
- Business application databases depend on IOPS and latency for small random requests.
- Measure your own figures with Performance Monitor before comparing offers.
- Ask which limit applies first: VM, disk or shared storage.
This article was originally published on .