IOPS Calculator

Estimates the disk IOPS a workload actually needs and lines that up against what different storage tiers can deliver, from spinning disks to enterprise NVMe. The point is finding this out before deployment, not after a database grinds to a crawl under a load nobody sized for.

IOPS vs throughput — different question entirely

Throughput (MB/s) matters for large sequential operations — streaming, backups, big file copies. IOPS matters for random-access workloads — databases, virtualisation, mail servers, transaction processing — where thousands of small, scattered reads and writes are happening simultaneously rather than one big continuous stream. A drive can look great on throughput and still be the wrong choice for a database workload if its IOPS numbers don't hold up.

Roughly what each storage class can deliver

• 7200 RPM HDD — 70–150 IOPS, sequential workloads only
• 15K RPM HDD — 250–350 IOPS, the ceiling for spinning disk
• SATA SSD — 20,000–100,000 IOPS, a huge jump over any HDD
• Consumer NVMe — 100,000–500,000 IOPS, plenty for most workloads
• Enterprise NVMe — 500,000–1,000,000+ IOPS, for large databases and high-frequency trading-tier requirements
• All-flash SAN array — 1,000,000+ IOPS, hyperscale database and virtualisation territory

Before you spend money on storage, spend it on RAM

Database IOPS demand tracks concurrent users, query complexity, and — the big one — how much of the working set actually fits in memory. A well-tuned database with enough RAM cache serves most reads straight from memory, which cuts real IOPS demand dramatically compared to what the raw numbers suggest. Right-size memory first; it's consistently cheaper than the storage upgrade you'd otherwise reach for. And before assuming you need more IOPS at all, check what you're actually using with iostat or iotop — plenty of "we need faster storage" tickets turn out to be a missing index or an unbounded query, not a hardware limitation.