UpCloud and MaxIOPS: When Storage Performance Is the Bottleneck

When an application feels slow, the instinct is to add cores. Often the real constraint is storage latency — the time a database spends waiting for a disk to answer, multiplied across every query.

UpCloud built its platform around that observation, and its storage architecture is the reason to consider it.

What MaxIOPS actually is

MaxIOPS is UpCloud's block storage tier. Rather than attaching network storage over a conventional path, it uses a distributed architecture designed to keep latency low and consistent, with data held redundantly across multiple backend nodes.

Two properties matter in practice:

• Consistency. Throughput does not collapse under sustained load the way burst-credit storage does on some platforms.
• Independence from instance size. You are not forced up into a larger, more expensive instance purely to obtain acceptable disk performance — a coupling that exists on several competing platforms.

For a database with a working set larger than RAM, that second point alone can change the cost of the deployment.

Plans and sizing

UpCloud's server plans are straightforward:

The Custom option gives some of the flexibility that Kamatera makes its central proposition, while keeping the simpler fixed plans available as defaults.

Networking

• Private networks (SDN) — proper software-defined networking between servers, including across zones within a region.
• Floating IPs — static addresses remappable between servers for failover.
• Load Balancer — managed, with health checks and TLS.
• Gateways and NAT — for controlled egress from private-only servers.

Inbound traffic is free and each server includes a monthly outbound transfer allowance. As elsewhere, the highest-value single change is to put datastores on private addresses only and reach them from the application tier internally.

Credit and account state

UpCloud environments are commonly described by a credit balance. As with every platform, credit is a spending balance, not a capability: it offsets charges and does not by itself raise limits or open restricted ports.

The questions that determine usefulness are the remaining balance, its expiry, the account's resource limits, and the available zones. A UpCloud account with a healthy balance but a low server ceiling will constrain you before the money runs out.

Where storage performance genuinely matters

It is worth being specific, because "fast storage" is often sold where it is not needed:

• Relational databases with working sets exceeding RAM. Every cache miss becomes a disk read, and latency compounds per query.
• Write-heavy workloads — event ingestion, time-series, audit logs. Commit latency is the throughput ceiling.
• Search indexes — Elasticsearch and OpenSearch segment merges are I/O-bound.
• CI with large dependency trees — checkout and install phases are disk-bound far more than CPU-bound.
• Container registries and artefact stores — many small file operations.

Where it matters much less: static sites, cached read-mostly applications, stateless API tiers and anything whose working set fits comfortably in memory. Paying a storage premium for those is waste. The database workloads guide goes further into how to tell which case you are in.

Where UpCloud fits

It fits database-backed applications, European businesses wanting a European operator, and teams that have diagnosed a storage bottleneck and want it gone without moving to a hyperscaler's premium storage tiers.

It fits less well where you need a broad managed-service catalogue or the lowest possible price per core — for that, Hetzner remains the value benchmark. The UpCloud and Kamatera comparison sets the two against each other directly.

Measuring storage before you commit

Storage claims are easy to make and easy to test, so test them. The useful measurement is not a headline throughput number but the latency your own workload sees under its own access pattern.

• Measure the current system first. Without a baseline from the server you are leaving, any new number is decoration.
• Test the access pattern you actually run. Databases issue small random reads and writes; media serving issues large sequential ones. A sequential benchmark tells you almost nothing about database behaviour.
• Read the tail, not the average. The 95th and 99th percentile latencies are what users experience as an application that intermittently stalls. A good average can hide them entirely.
• Size the test beyond memory. If the test data fits in RAM you are benchmarking the page cache, not the disk.
• Test on the instance you intend to buy. Storage performance interacts with instance size and network allocation on most platforms.

Tools such as fio for raw device behaviour, and your database engine own benchmarking utilities for query-level behaviour, cover both layers. If the measured gap is small, the bottleneck is somewhere else and faster storage will not fix it.

Frequently asked questions

How do I know if storage is my bottleneck? Look at I/O wait in top or vmstat, and at your database's disk read latency metrics. If CPU sits idle while requests queue, the disk is the constraint.

Is MaxIOPS worth it for a stateless web server? Generally no. Stateless tiers read little from disk after boot.

Does credit expire? Promotional balances typically carry an expiry. Confirm the date on the specific environment rather than assuming.

Can I resize a server later? Yes, with a reboot. Storage can be grown; shrinking is not supported, so size deliberately.

Current balances and configurations are on the Buy UpCloud Account listing.