Storage performance isn't just about megabytes per second. If your system is running slowly despite fast connections and modern drives, it's very likely that the culprit is IOPS – Input/Output Operations Per Second. Underappreciated, often overlooked when planning infrastructure, yet they have a critical impact on the speed of databases, virtual machines, and business applications. In this post, you'll find out what IOPS really means, how to measure it, when it matters, and why choosing a drive without this knowledge is just a lottery.
Performance Without IOPS is Just Theory – Check What's Actually Driving Your Data
Too often, we focus solely on megabytes per second or throughput in Gbits, forgetting that in practice, it's IOPS that determine how a system responds to real-world load. Especially in environments where the storage infrastructure supports dozens of VMs, microservices, or database applications, the number of input/output operations per second is the hard currency of performance. Throughput may look good in a benchmark, but if latency increases and IOPS are choking, the user still sees the system "lagging."
It's worth remembering that IOPS isn't just a number from a drive's datasheet. Real performance is influenced by a whole host of factors:
- block size,
- queue depth,
- workload type (random or sequential),
- RAID architecture,
- and even the controller's firmware.
If you don't have IOPS measurements for your resources, you're operating in the dark – and it's then difficult to distinguish a real bottleneck from a simple "user theory." Even the most expensive SSD will do nothing if the application demands I/O in microscopic portions and the file system can't keep up. That's why before you assess storage performance, check how it behaves in terms of IOPS – and whether what you have is really enough.
Random vs. Sequential – Which IOPS is More Important for You?
Before you decide which storage media to implement, you need to know what type of load your environment generates. They are not one and the same. "Random" IOPS is a completely different story from "sequential."
- In the case of databases, virtual machines, ERP, or CRM systems, the load is predominantly random, where data is written and read from different areas of the disk in an unordered manner. Here, the key is the speed of response to a large number of small requests.
- On the other hand, sequential IOPS are important for backups, replication, and large multimedia files, where the system processes data in longer, logical blocks.
If you don't define this, it's easy to make a costly mistake. Because even a very fast drive may not have a sufficiently high rating for the specific type of IOPS your application needs.
RAID = More IOPS? Only If You Understand the Penalty and Cache
Many administrators assume that adding a RAID is an automatic performance boost. And that's partly true – but only if you understand the mechanics of reads and writes in different RAID levels.
- RAID 0 actually allows for maximum IOPS because there is no redundancy and data is spread in parallel. But this is a solution for a test lab, not for production.
- RAID 5 and RAID 6 – although they offer data protection – impose a so-called RAID penalty, which is an additional overhead when writing data (due to the calculation of parity). This means that the actual number of IOPS decreases relative to the nominal capabilities of the drives.
- A much better compromise is RAID 10, which combines mirroring with striping, thus providing not only protection but also reasonable performance – especially for mixed-character workloads.
Cache is also of key importance – both at the RAID controller level and on the storage side, for example, in the form of NVDIMM or NVMe cache. A well-configured cache can significantly increase the number of operations handled, especially for small blocks. And that's why when configuring an array, don't just ask "how many drives do I have," but "how will all this behave under load and do I have a buffering layer."
How Many IOPS Do You Really Need? Don't Guess – Measure and Optimize
The real problem starts when IOPS are "guessed." Because instead of measuring, they are estimated "by eye" – and then either the storage can't handle the load, or you pay for excess power you'll never use. Therefore, before you order a new array or servers with NVMe drives, check how many IOPS your infrastructure really needs. You can do this in several ways – from simple system tools (iostat, perfmon), through APMs, to fio and Iometer, which allow you to replicate any workload and test any type of device.
It's important that the tests are not detached from reality. The recommendation is clear: define the traffic characteristics (random/sequential, read/write), because each of these parameters changes the final result. A drive that delivers 300,000 IOPS on reads can suddenly drop to 50,000 on writes in a RAID 5 setup. Therefore, always compare metrics with the type of load, not just with a table in Excel. Monitor production, correlate data with application behavior, look at latency. Only then do you know how many IOPS you really have and whether it's enough – not just guessing.
