Cloud Disk Types: NVMe, SSD, Network Volumes and Why It Matters

Two servers with the same CPU and RAM can differ by an order of magnitude in database performance. The disk is usually why.

15 June 2026 3 min read

Disk is the least discussed and most performance-relevant part of a server specification. It is also where two superficially identical plans diverge most.

Local versus network storage

	Local NVMe / SSD	Network block storage
Latency	Tens of microseconds	Hundreds of microseconds to milliseconds
Throughput	Very high	Capped by plan and network
Survives instance loss	No	Yes
Resizable	Rarely	Yes
Snapshots	Limited	Built in
Detach and reattach	No	Yes
Typical use	Databases, caches, scratch	Everything else

The trade is durability against speed. Local storage lives on the physical host, so it is fast and it disappears if the instance does. Network storage survives independently, at the cost of a network hop on every operation.

The correct pattern for a database on local NVMe is not to avoid it — it is to use it and replicate, so speed comes from local disk and durability comes from a second copy.

IOPS, throughput and the difference

IOPS — operations per second. Databases doing many small reads and writes are limited by this.
Throughput — megabytes per second. Backups, large file serving and analytics scans are limited by this.
Latency — how long one operation takes. This is what makes a system feel fast or slow.

A volume can have high throughput and poor IOPS, or the reverse. A database that feels slow despite low CPU is almost always IOPS-limited or latency-limited, not throughput-limited.

The size-linked performance trap

On several platforms, volume performance scales with volume size. A 20 GB general-purpose volume gets a small IOPS allocation regardless of the instance it is attached to.

The result is a fast instance bottlenecked on a small disk, which looks like an application problem and is not. Where this model applies, either over-provision the volume size for the performance, or pay for provisioned IOPS explicitly.

Some volume types also use a burst credit system, which produces the same surprise as burstable CPU: fine in testing, throttled under sustained load.

How the providers differ

AWS — several EBS types, with gp3 offering baseline performance independent of size and io2 for provisioned IOPS. Instance store is local NVMe on selected families.
Google Cloud — persistent disk performance scales with size; local SSD is available separately.
Azure — managed disk tiers from standard HDD to premium and ultra SSD, with defined IOPS per tier.
UpCloud — MaxIOPS storage is a headline feature and consistently fast.
Hetzner — local NVMe on cloud instances, plus separately billed network volumes.
DigitalOcean and Linode — local SSD or NVMe included in the plan, plus attachable block storage.

VPS providers generally include fast local storage in the plan price. Hyperscalers unbundle it, which gives more control and makes the total harder to compare.

Measure before you conclude

Check queue depth and wait time with iostat -x 1. High %util with high await means the disk is the bottleneck.
Benchmark with fio using a pattern resembling your workload — random 4K reads for a database, sequential for file serving.
Run it long enough to exhaust any burst credits, or you will measure the burst rather than the baseline.
Compare against the plan’s published limits to see whether you are hitting a cap or a hardware limit.

Reducing disk pressure without buying more

Give the database more RAM. Data served from the buffer pool never touches disk at all.
Add indexes so queries read fewer pages.
Move logs to a separate volume so they do not compete with data.
Cache computed results in Redis or Memcached.
Put static files behind a CDN so the origin disk is not serving them repeatedly.

More memory is very often cheaper than faster disk, and it addresses the cause rather than the symptom.

Common questions

Is local NVMe safe for a database?

With replication and off-instance backups, yes, and it is a common high-performance pattern. Alone, on a single instance, no — you are one host failure from data loss.

Why is my disk slow when the instance is large?

Usually a small volume on a platform where IOPS scale with size, or exhausted burst credits. Check the volume’s published performance rather than the instance specification.

Do I need provisioned IOPS?

Only for demanding databases with known requirements. Modern general-purpose volumes with a sensible size cover most workloads and cost far less.

Should logs live on a separate volume?

On busy systems, yes. It prevents log writes from competing with data, and stops runaway logging from filling the disk the application depends on.

Where to go next

See storage types explained and how to size a cloud server.

AWS Hetzner UpCloud