Block Storage

Every disk on ServersCamp is a network disk: a volume on a distributed, replicated NVMe storage fabric, independent of the hypervisor your VM happens to run on. There are no local disks here, and that is a deliberate engineering position, not a cost cut. A local disk ties your data to one machine: when that machine's disk or controller dies, the data dies with it, and nobody can live-migrate you off a sick host. A network disk survives the node, follows the VM, and still has to win on one thing to be worth it: latency.

That is the part we obsessed over. Our storage fabric answers a 4k random read in about 160 microseconds, measured from inside an ordinary customer VM, not from a lab. That is local-NVMe territory, an order of magnitude ahead of typical cloud network volumes. This page explains the four disk classes built on that fabric, what each is good and bad at, and shows the raw numbers so you can re-run every one of them yourself.

At a glance

Latency: the number that actually matters

Benchmark marketing is usually about IOPS, because IOPS numbers are big and impressive. But most real applications are not IOPS-bound, they are latency-bound. A web request is a chain of small dependent reads: index, row, another row, a config file. Each read has to finish before the next one starts. What determines how fast that chain completes is not how many operations per second the disk could theoretically do in parallel: it is how long one operation takes. That is QD1 latency (queue depth 1: one operation at a time, no queue to hide behind).

Here is ours, measured with fio inside a production customer VM, on a replicated disk, with the platform under normal load:

$ fio -rw=randread -bs=4k -iodepth=1 -direct=1 -ioengine=libaio -runtime=30 -time_based

  read: IOPS=6068, BW=23.7MiB/s
    clat (usec): min=104, max=2564, avg=157.62, stdev=31.22
    clat percentiles (usec):
     | 50.00th=[  155], 99.00th=[  180], 99.90th=[  334]

$ fio -rw=randwrite -bs=4k -iodepth=1 -direct=1 -ioengine=libaio -runtime=30 -time_based

  write: IOPS=6480, BW=25.3MiB/s
    clat (usec): min=94, max=1292, avg=146.81, stdev=40.94
    clat percentiles (usec):
     | 50.00th=[  141], 99.00th=[  229], 99.90th=[  799]

Read that carefully: the average 4k read is 157 microseconds and the 99th percentile is 180. Writes average 147 microseconds including replication. The distribution is tight: no long tail hiding behind a pretty average.

For context, here is where that sits in the world:

In plain words: our network disk is within striking distance of a disk physically inside the server, and 10 to 20 times faster to answer than the network volumes most clouds attach to their VMs. For a database doing dependent point reads, or a web app assembling a page from many small files, that gap is the difference you feel.

We put this claim through a head-to-head: the same fio battery on the local NVMe of premium Hetzner and DigitalOcean instances against these disks, premium and budget tiers, raw JSON kept. The replicated network disk posted the lowest read latency in both tiers and out-committed both local disks under parallel fsync load. Full tables and charts: Replicated network storage vs local NVMe.

Where the microseconds come from: RDMA

The storage fabric talks RDMA (Remote Direct Memory Access) end to end. With RDMA, the network card moves data directly between the memory of the hypervisor and the memory of the storage nodes: no kernel network stack in the hot path, no per-packet interrupts, no intermediate copies, no syscalls per operation. The card on one machine literally writes into the RAM of another.

That matters because on a conventional network volume, most of the latency is not the wire: the wire crossing a datacenter takes single-digit microseconds. The other 99% of a millisecond-class volume is software: TCP, the kernel on both ends, context switches, interrupt handling, buffer copies. RDMA deletes that entire column of the bill. What is left is the wire, the NVMe, and the storage engine, which is how a 4k read comes back in ~157 microseconds and a replicated write is acknowledged in ~147.

The cost of the path: why IOPS are hard

A 4k random read looks like a trivial operation. Count what actually happens between your application and the flash, in a virtual machine:

1. The application issues a read: a syscall into the guest kernel.
2. The guest block layer builds a request and queues it on a virtio queue.
3. The guest "kicks" the virtqueue to notify the host: that is a vmexit, a hardware trap that suspends the vCPU, saves its state, and hands control to the hypervisor.
4. The host side dequeues the request, translates it, and submits it to real storage: its own queueing, its own submission path.
5. The data comes back; the host signals completion by injecting an interrupt into the guest: more vmexit-class work on the way in.
6. The guest kernel handles the interrupt, completes the request, wakes the application.

Almost none of that is moving data. It is bookkeeping: traps, context saves, queue manipulation, interrupt delivery, cache lines bouncing between cores. And it is a fixed cost per operation: at 1 MB blocks it disappears into the transfer time, at 4k blocks it is the operation. Small-block IOPS is not a storage benchmark, it is a CPU benchmark of the entire path.

The arithmetic is unforgiving. At 100,000 IOPS a vCPU has 10 microseconds of budget per operation, total, for all six steps above. A single vmexit costs on the order of a microsecond or two before the hypervisor does anything useful; a naive path takes several per operation. Spend 3-4 microseconds on overhead per I/O and one core saturates near 60-70k IOPS no matter how fast the flash underneath is.

Queue depth can hide device latency, but it cannot hide path cost: every operation still pays the toll, deep queue or not. And for the dependent-read chains that real applications produce, queue depth does not help at all, which brings you back to the QD1 latency section above.

Our engineering budget went into making that path short: RDMA on the fabric side is the part we have described, and a good deal of per-operation cost removal on the hypervisor side is the part we keep to ourselves. The practical takeaway for you as a buyer is simpler: the IOPS ceiling you will actually see is set by your VM's hardware generation, which is exactly why disk limits clamp per hardware class instead of pretending otherwise.

Basic (R1-R5): the default

Basic disks live on the replicated fast-NVMe pool. This is the class the wizard preselects, the class that carries the free 25 GB root-disk allowance, and the right answer for sites, applications, dev machines, and most production services.

* Effective limits are capped by the VM's hardware generation: see hardware caps below.

Strong: replicated, cheap, fast, and the latency shown above. The 25 GB free allowance means a typical VM root disk costs exactly nothing.
Weak: the pool favors throughput over synchronous-write guarantees. If your workload lives and dies by fsync (a busy transactional database), the Database class exists precisely for you.

Database (W1-W5): unlimited fsync

Database disks live on a separate pool of enterprise NVMe with power-loss protection (PLP): the drives have capacitor-backed caches, so a write acknowledged is a write that survives the power going out. That single hardware property changes the economics of one very specific operation: fsync.

For the non-DBAs: every time a database commits a transaction, it calls fsync to force the data to durable media before telling the client "done". On ordinary consumer NVMe, actually flushing to media is slow, which is why cheap disks are fast at everything except the one operation a database does thousands of times per second. On PLP drives, the capacitor-backed cache is durable media, so fsync completes at full device speed. That is what "unlimited fsyncs" means on our cards: not a marketing cap raised, a hardware property bought.

Strong: replicated, PLP, commit-heavy workloads run at full speed with real durability. Postgres, MySQL, message queues, anything with a write-ahead log belongs here.
Weak: the price. If your workload does not fsync in anger, Basic gives you the same tier speeds for a third less.

Solo (E1): as fast as the node goes

Solo is what a "local disk" claims to be, built on the network fabric: a single-copy volume with no replication and, deliberately, no meaningful throttle. The configured limits (500k IOPS, 8 GB/s) sit far above what any guest can push: in practice the ceiling is the hardware your VM runs on.

Those are "up to" numbers and the speed is shared, best effort: Solo volumes have no QoS guarantee and neighbors on the same pool can make you dip. Measured on a small High Frequency VM with a standard mixed 50/50 yabs run:

Block Size | 4k            (IOPS) | 64k           (IOPS)
Read       | 415.22 MB/s (101.3k) | 2.42 GB/s    (36.9k)
Write      | 416.32 MB/s (101.6k) | 2.43 GB/s    (37.1k)
Total      | 831.55 MB/s (203.0k) | 4.85 GB/s    (74.0k)

203,000 mixed IOPS and ~5 GB/s from an ordinary guest, and a pure read run goes higher still.

Strong: the fastest disk class we sell, at 100 EUR/TB-mo: no other disk here, and no volume at any typical VPS provider (their caps sit at 5-10k IOPS), reaches this territory.
Weak: one copy. If the hardware under the pool fails, the data is gone: no rebuild, no apology that helps. Put things on Solo that you can regenerate: caches, build workspaces, CI scratch, temp processing. Treat it like RAM that happens to be big and persistent-ish.

Storage (S1): terabytes over speed

Storage disks are the opposite trade: replicated, durable bulk space with an HDD-like speed profile, at 30 EUR/TB-mo. The limits (400 IOPS, 200 MB/s) are shaped so that large sequential work - copying media, writing archives, restoring dumps - runs at full 200 MB/s, while random-access workloads are firmly discouraged: this is not the place for a database, and the numbers make sure you find that out in testing rather than production.

Strong: the cheapest replicated terabyte on the platform, on the same fabric with the same durability as Basic. Up to 10 TB per volume.
Weak: 400 IOPS is a deliberate wall. Anything latency-sensitive or random-access-heavy will feel it immediately.

Hardware caps and exact throttles

Two policies define what a tier limit actually means here.

First: we clamp tiers to what your VM's hardware can actually push. A tier-3 disk advertises 75k IOPS, but a Basic-generation guest tops out near 62k on the vCPU/virtio path long before the storage does. We measured it:

$ fio -rw=randread -bs=4k -iodepth=64 -numjobs=4 -direct=1 -ioengine=libaio -runtime=60 -time_based -group_reporting
  read: IOPS=62.2k, BW=243MiB/s    # Basic guest, tier-3 disk, 75k tier limit: the guest is the ceiling

So on Basic hardware, tier-3 disks are sold as what they really deliver there: 50k IOPS, 1 GB/s, and tiers 4-5 are not offered at all. On High Frequency the same disk classes run their full published numbers (guests verified beyond 300k IOPS). The wizard shows you the clamped figures for whichever hardware you picked: the number on the card is the number you get.

Second: the throttles are exact. A tier limit is not a vague ceiling that congestion eats into. On a 5,000 IOPS tier, fio at queue depth 128 measures:

  read: IOPS=5016, BW=19.6MiB/s
    clat (usec): avg=25502    # = 128 in flight / 5000 per second: textbook shaping

5,016 delivered on a 5,000 limit, with latency locked to exactly what queueing theory predicts. Your neighbor cannot spend your IOPS budget, and you cannot spend theirs: this is also why noisy neighbors are a structural impossibility here rather than a promise.

Reproduce everything

Every number on this page came from commands you can run on your own VM in five minutes:

# QD1 latency: the number that matters
fio -name=lat -filename=./fiotest -size=8G -direct=1 -ioengine=libaio -rw=randread -bs=4k -iodepth=1 -runtime=30 -time_based

# Sustained IOPS
fio -name=iops -filename=./fiotest -size=8G -direct=1 -ioengine=libaio -rw=randread -bs=4k -iodepth=64 -numjobs=4 -group_reporting -runtime=60 -time_based

# Sequential throughput
fio -name=bw -filename=./fiotest -size=8G -direct=1 -ioengine=libaio -rw=read -bs=1M -iodepth=16 -runtime=30 -time_based

Independent confirmation: a third-party vpsbenchmarks.com run of a 2 vCPU / 4 GB High Frequency VM measured 434+435 MB/s mixed 4k (~212k IOPS combined) on a replicated Basic-class disk: roughly double the closest same-size plans in their database, on their tooling, not ours.

Which disk for what

Disks are billed hourly on provisioned size, volumes can be resized upward live, and speed tiers within the same class family can be changed in place with no data migration. Whatever you pick, you can change your mind later: that is rather the point of network disks.