NVMe Queue Depth Calculator
This NVMe Queue Depth Calculator applies Little's Law to tell you exactly how deep your I/O queue needs to be to saturate your drive. Enter your drive's Rated Peak IOPS, Latency at Queue Depth 1, Target IOPS, and Number of Application Threads, then click Calculate to see the total queue depth needed, per-thread depth, saturation queue depth, and a full IOPS vs Queue Depth scaling table from QD1 through QD256.
NVMe Drive Class, Queue Depth and Random vs Sequential Workload
Projected IOPS, Latency and Throughput by Queue Depth
Total QD Required
QD per Thread
Saturation QD
QD1 Throughput
| Little's Law Metric | Value | Notes |
|---|---|---|
| Latency at QD1 (λ) | — | Service time per I/O at low depth |
| IOPS at QD1 | — | 1,000,000 µs ÷ latency_µs |
| Target IOPS (λ) | — | Your application requirement |
| Total QD needed — Little's Law (N = λ × W) | — | target_IOPS × latency_µs / 1,000,000 |
| Per-thread QD needed | — | Total QD ÷ number of threads |
| Saturation queue depth (peak IOPS) | — | QD at which drive reaches rated peak IOPS |
| Throughput at target IOPS + block size | — | target_IOPS × block_size |
| Can your threads saturate the drive? | — | threads × per-thread QD ≥ saturation QD? |
Estimated IOPS vs Queue Depth Scaling
| Queue Depth | Estimated IOPS | % of Peak | Throughput (MB/s) | Est. Latency (µs) | Status |
|---|
NVMe vs SATA vs SAS Queue Architecture
| Interface | Protocol | Max Queues | Depth per Queue | Max Outstanding I/Os | Multi-core Scaling |
|---|---|---|---|---|---|
| SATA SSD / HDD | AHCI | 1 | 32 | 32 | Poor — single shared queue |
| SAS HDD / SSD | SCSI | 1 per initiator | 254 | 254 | Limited — one queue per HBA port |
| NVMe SSD (PCIe) | NVMe 1.x | 65,535 | 65,535 | 4.29 billion | Excellent — one queue per CPU core |
| NVMe-oF (RDMA) | NVMe 1.x | 65,535 | 65,535 | 4.29 billion | Excellent + network fabric latency |
In practice, NVMe drives support 2–128 queues depending on firmware implementation. The spec allows 65,535 but real devices expose fewer queues tuned to their internal parallelism. Linux NVMe driver maps one submission queue per CPU core by default.
Typical NVMe Latency & IOPS by Device Class
| Drive Class | QD1 Latency (µs) | Peak IOPS (4K random) | Saturation QD | Interface |
|---|---|---|---|---|
| Consumer NVMe (Gen 3) | 70–120 | 350K–550K | ~32–64 | PCIe 3.0 x4 |
| High-end Consumer (Gen 4) | 50–80 | 700K–1,000K | ~64–128 | PCIe 4.0 x4 |
| Enterprise Read-Int. (Gen 4) | 80–120 | 800K–1,500K | ~128–256 | PCIe 4.0 x4 |
| Enterprise Write-Int. (Gen 4) | 70–100 | 500K–800K | ~64–128 | PCIe 4.0 x4 |
| Consumer NVMe (Gen 5) | 40–70 | 1,500K–2,000K | ~128–256 | PCIe 5.0 x4 |
| Intel Optane P5800X | 6–10 | 1,500K | ~16–32 | PCIe 4.0 x4 |
| SATA SSD (reference) | 70–100 | 90K–100K | ~32 | SATA 6Gb/s |
Why Queue Depth Multiplies NVMe IOPS and Reduces Latency
NVMe queue depth is the number of I/O commands simultaneously outstanding to a storage device. NVMe's defining architectural advantage over SATA AHCI is its multi-queue design: NVMe supports up to 65,535 submission queues, each holding up to 65,535 commands — nearly 4.3 billion concurrent I/Os. SATA AHCI is limited to a single queue with 32 commands. This is not a marketing distinction; it is the fundamental reason why NVMe drives deliver an order of magnitude more IOPS than SATA SSDs when driven by multi-threaded workloads such as databases, virtualisation platforms, and object storage systems. Understanding required queue depth for your specific IOPS target lets you verify whether your application is actually saturating the NVMe drive or leaving most of its capacity idle. Learn more: check PCIe bandwidth ceiling before tuning queue depth.
Little's Law is the queueing theory formula used to calculate required queue depth: N = λ × W, where N is the mean number of outstanding I/Os (queue depth), λ is the throughput in operations per second (IOPS), and W is the mean service time per I/O (latency in seconds). For an NVMe drive with 0.1 ms average latency and a target of 500,000 IOPS, the required queue depth is N = 500,000 × 0.0001 = 50 concurrent I/Os. If your application uses 4 threads each with QD=16, it can issue 64 concurrent I/Os — enough to reach that target. If it uses a single-threaded synchronous I/O model at QD=1, it is physically incapable of exceeding 10,000 IOPS on a 0.1 ms drive regardless of how fast the NVMe SSD is. Queue depth is not just a tuning parameter — it is the access path that unlocks NVMe performance. Check out our calculate total IOPS from queue depth and latency.
The relationship between queue depth and IOPS follows a characteristic curve for NVMe SSDs. At queue depth 1, IOPS is determined purely by latency: IOPS = 1000 / latency_ms. As queue depth increases, the NVMe controller can pipeline and parallelise I/O across its internal flash channels, delivering disproportionately higher IOPS per unit of added depth. This scales until the drive reaches its rated peak IOPS — typically at QD32 to QD256 depending on the device — after which adding more queue depth only increases latency without improving throughput. The NVMe queue depth planner on this page maps out this entire curve for your specific drive, showing exactly where the saturation point is and what application-level queue depth is needed to reach it without over-queuing and introducing unnecessary latency. Related: Convert NVMe throughput between MB/s and GB/day.
NVMe Completion Queues, Submission Queues and Parallelism Explained
Little's Law (N = λ × W): The fundamental queueing relationship. N = average queue depth, λ = throughput (IOPS), W = average service time (latency). Rearranged: required QD = target_IOPS × latency_in_seconds. This is exact for stable queues in equilibrium.
Saturation Queue Depth: The minimum queue depth at which the drive reaches its rated peak IOPS. Below this depth, the drive is under-utilised. Above it, latency grows but IOPS does not improve. For NVMe SSDs, saturation typically occurs between QD32 and QD256.
Per-CPU Queue Mapping: Linux maps one NVMe submission queue per CPU core. A 16-core server with QD=4 per core issues 64 concurrent I/Os — enough to saturate most NVMe SSDs. On Windows, applications control queue depth directly via async I/O or storage driver parameters.
Why SATA Cannot Scale: With a single queue of 32, SATA AHCI serialises I/O at the queue boundary. Even with multiple threads, only 32 I/Os are ever in flight. NVMe's per-core queues eliminate this serialisation point, allowing every CPU core to issue I/O independently and concurrently.
Latency vs Throughput Trade-off: At low queue depths, NVMe delivers minimum latency (best for interactive workloads). At high queue depths, it delivers maximum IOPS and throughput (best for batch and streaming workloads). Never optimise for both simultaneously — choose based on your application's latency SLA vs throughput requirement.
NVMe Namespaces: NVMe supports multiple logical namespaces on a single physical drive, each with its own queue set. Enterprise NVMe drives can isolate workloads across namespaces — useful for multi-tenant environments where I/O prioritisation is needed.