MaxIOPS explained: what UpCloud’s storage actually does

UpCloud markets its block storage as MaxIOPS, and the claim is about a specific characteristic: consistently high input and output operations per second with low latency, rather than a headline peak figure that degrades under sustained use.

Whether that matters to you depends entirely on whether storage is actually your bottleneck, and most people assume it is when it is not.

The three numbers that describe storage

IOPS is operations per second. It matters for workloads doing many small reads and writes: databases, message queues, anything with a busy transaction log. It is the number storage marketing usually leads with.

Throughput is bytes per second. It matters for workloads moving large contiguous blocks: backups, media processing, log shipping, bulk loading.

Latency is how long a single operation takes. It matters more than either of the others for interactive workloads, because a database query waiting on a slow read blocks a user, and a thousand such waits per second becomes a visibly slow application.

These are related but not interchangeable. Storage can deliver excellent throughput and poor latency, which feels fast when copying a large file and slow when running an application.

Why consistency matters more than peak

Many cloud storage products deliver high performance in bursts and then throttle to a lower sustained rate once a credit balance is exhausted. This produces a characteristic and confusing pattern: a benchmark run right after provisioning looks excellent, and production performance an hour into a busy period looks poor.

The practical consequence is that benchmarking storage for thirty seconds tells you very little. If you are evaluating storage, run the test for long enough to exhaust any burst allowance, which usually means tens of minutes rather than seconds.

Storage products that advertise consistent performance are making a claim about the sustained figure rather than the peak, and for production databases that is the number that governs how the application feels.

Diagnosing whether storage is your problem

Before paying for faster storage, establish that storage is the constraint. The signals are specific.

High I/O wait. If CPU time is dominated by waiting on I/O rather than doing work, storage or the network is the bottleneck. This is the clearest single indicator.

Queue depth climbing. Operations queuing up faster than the device retires them means the device is saturated.

Latency rising with load while throughput plateaus. A device at its limit accepts more requests but takes longer to serve each.

If instead CPU is saturated, or memory pressure is causing swapping, or the application is blocked on a network call, faster storage will change nothing at all. Swapping in particular is often misread as a storage problem when it is a memory problem wearing a disguise.

The things that reduce storage load for free

Before buying faster storage, several changes frequently remove the problem entirely.

Give the database more memory. Databases cache aggressively. A working set that fits in the page cache generates almost no read I/O. Adding memory is often cheaper than adding storage performance and helps more.

Fix the queries. A missing index turns a single indexed read into a full table scan. This is the most common cause of unexpected disk load, and adding an index is free.

Move logs off the data volume. Application logging competing with database writes on the same device is a self-inflicted wound and trivial to separate.

Batch small writes. Many small synchronous writes are the worst case for any storage system. Batching them into fewer, larger operations can improve throughput by an order of magnitude.

Check the filesystem and mount options are sensible for the workload, and that the device is aligned properly. Misconfiguration here is rare but expensive when present.

When faster storage genuinely is the answer

After all of that, some workloads are legitimately storage-bound: write-heavy databases with a working set that will not fit in memory at any reasonable price, high-volume event ingestion, search indexing, and anything doing sustained random access over a large dataset.

For these, low-latency local or high-performance network storage is the correct purchase, and the difference is dramatic rather than marginal.

A sane evaluation procedure

If you want to compare storage between providers or plans honestly:

1. Test with your workload’s access pattern, not a generic sequential benchmark. Random reads at your typical block size behave nothing like a large sequential copy.
2. Run for long enough to exhaust burst credits, which means tens of minutes.
3. Record latency percentiles, not averages. The ninety-ninth percentile is what your users experience as slowness.
4. Test while the machine is doing its normal work, because storage contention with the application’s own CPU and network use is part of the real picture.
5. Compare the sustained figure, because that is what production sees.

For the vendor’s own reference on the services involved here, see the UpCloud documentation.

Questions people ask