Table of Contents
- What this page is and is not
- What each provider states about its disk
- The figures vendors publish: UpCloud, Azure and Google Cloud
- What NVMe, SSD and RAID-10 tell you, and what they do not
- When disk performance decides
- Measuring your own server with fio
- Configuration that reduces disk dependence
- What this page could not verify
- FAQ
- Sources
What this page is and is not
An earlier version of this page presented fio results for thirteen providers, with IOPS per dollar, consistency percentages and a workload ranking, framed as this site's own testing. None of it could be sourced and it has been removed. What replaces it is narrower and checkable: the storage wording from each provider's page or API at the 2 GB tier (or the nearest plan), read in September 2026 and quoted; the disk performance figures that Azure and Google Cloud publish in their documentation; and a procedure for testing your own server, which is the only way to get a number that applies to you. Providers are listed in price order, not performance order, because there is no sourced performance order to give.
What each provider states about its disk
| Provider | Plan (2 GB or nearest) | Disk | Storage as stated on its page or API | Monthly |
|---|---|---|---|---|
| InterServer | 1 slice | 40 GB | "SSD storage and Raid-10" | $3 |
| BuyVM | Slice 2048 | 40 GB | "SSD Storage" | $7 |
| OVHcloud | VPS-1 (4 GB) | 40 GB | "SSD NVMe" | $5.35 |
| Contabo | Cloud VPS 4 (8 GB) | 100 GB | "100 GB SSD"; copy says "NVMe storage" | $6.60 |
| Hostwinds | Unmanaged Linux 2 GB | 50 GB | SSD (Solid State Drives) | $9.99 |
| Vultr | vc2-1c-2gb | 55 GB | API label "SSD"; vhf/vhp lines at $12 | $10 |
| Linode | Linode 2GB | 50 GB | Types API gives size only | $12 |
| DigitalOcean | Basic 2 GiB | 50 GB | SSD; Premium CPU Droplets "use NVMe SSDs" | $12 |
| Kamatera | Standard sample: 2 vCPU Type B, 2 GB | 20 GB | "NVMe SSD Storage" | $25 |
| Hostinger | KVM 1 (4 GB) | 50 GB | "NVMe disk space" | $6.49 (24-month) |
| RackNerd | 2 GB KVM | 75 GB | "RAID-10 SSD"; Ryzen line "NVMe" | $20.59 list |
| UpCloud | Starter 2 GB | 20 GB | "Standard performance SSD storage"; Premium plans carry MaxIOPS, "over 100k IOPS read" at 4k | EUR 6 |
| Hetzner | CPX11 (US) | 40 GB | "NVMe" | $20.49 |
Readings, in the providers' own words where they use any. InterServer: "SSD storage and Raid-10". BuyVM: "SSD Storage" on its KVM slices. OVHcloud: "SSD NVMe" on every VPS tier of its US page. Contabo: Cloud VPS 4 lists "100 GB SSD" and the page copy says "NVMe storage". Hostinger: "NVMe disk space" on each KVM plan. Kamatera: "NVMe SSD Storage" on its configurations. RackNerd: "RAID-10 SSD" on the standard KVM line and "NVMe" on the Ryzen line. Hetzner: "NVMe" against each CPX size. CloudCone: "Pure SSD Disk On RAID-10 Configuration". DigitalOcean: Droplets with Premium CPUs "use NVMe SSDs and have higher network throughput speed", which implies the Basic line does not. Vultr's plans API labels disk type per plan: SSD on vc2, HIGHFREQUENCY on vhf, AMDHIGHPERF or INTELHIGHPERF on vhp. Linode's types API returns disk size only. Hostwinds's unmanaged Linux page lists "Solid State Drives" on the feature row for every plan. UpCloud's own pages state "Standard performance SSD storage" for the Starter family and MaxIOPS for Premium. Of all of those statements, only UpCloud's carries a number.
The figures vendors publish: UpCloud, Azure and Google Cloud
UpCloud is the one plan-priced provider on this site that publishes storage performance figures, and it does so per tier rather than per plan: over 100,000 read IOPS at 4k block size for MaxIOPS, which its Premium family uses, and up to 10,000 IOPS for standard storage, which the Starter family uses. Both are stated with a block size and an "up to", and neither is a measurement by this site; the UpCloud specs page carries them in full.
The hyperscalers publish differently, because they sell disk as a separate product with its own specification: the figures apply to the disk tier and to the VM size you attach it to, and the lower of the two limits governs.
Azure managed disks (from the disk types documentation)
| Tier (32 GiB size) | Base IOPS | Base throughput | Burst | Price, East US |
|---|---|---|---|---|
| Standard HDD S4 | Up to 500 | Up to 60 MB/s | not listed at this size | $1.54 a month |
| Standard SSD E4 | Up to 500 | Up to 100 MB/s | not listed at this size | $2.40 a month |
| Premium SSD P4 | 120 provisioned | 25 MB/s | 3,500 IOPS max burst | $5.28 a month |
The VM adds its own ceiling. Azure's Basv2 size page lists, for a B2ats v2 or B2als v2 (the sizes on the Azure alternatives page), uncached Premium SSD limits of 3,750 IOPS and 85 MBps, with burst to 10,000 IOPS and 960 MBps. A P4 disk on that VM is therefore limited by the disk (120 IOPS provisioned, 3,500 burst), not the VM. Prices are from the Azure Retail Prices API for East US in September 2026.
Google Cloud Persistent Disk (from the performance documentation)
| Zonal disk type | Read IOPS per GiB | Write IOPS per GiB | Read IOPS per instance (max) | Write IOPS per instance (max) |
|---|---|---|---|---|
| Standard PD | 0.75 | 1.5 | 7,500 | 15,000 |
| Balanced PD | 6 | 6 | 80,000 | 80,000 |
| SSD PD | 30 | 30 | 100,000 | 100,000 |
| Extreme PD | provisioned | provisioned | 120,000 | 120,000 |
So a 30 GB Balanced disk, the typical boot disk on a small Compute Engine VM, is rated at 180 read IOPS from its size, and the documentation adds that small VMs are further limited by vCPU count (its worked example caps a 4-vCPU instance's reads at 15,000 IOPS regardless of disk size). Google also sells Hyperdisk tiers with separately provisioned IOPS; they are outside a small-VM comparison.
Two things follow for the VPS comparison. First, the published hyperscaler entry tiers are modest: a 32 GiB Azure Standard SSD at up to 500 IOPS or a 30 GB Google Balanced disk at 180 IOPS are not figures a plan-priced NVMe VPS would advertise if it published any. Second, the absence of a figure at Vultr or Hetzner does not mean their disks are slower; it means they do not sell a specification, and the only way to know is to measure.
What NVMe, SSD and RAID-10 tell you, and what they do not
NVMe names the interface (PCI Express) between the drive and the host, and NVMe drives have far higher IOPS and throughput ceilings than SATA flash. It tells you the ceiling of the hardware, not your share of it: a VPS is one of many on the host, and the provider decides how many share an array and whether each is capped. SSD without qualification usually means SATA or SAS flash, sometimes NVMe that the page did not bother to name (Contabo's and DigitalOcean's wording shows both cases exist). RAID-10 mirrors and stripes the host's drives; it protects the host's data against a drive failure and lets reads come from either mirror. It is not a performance number, and it is not your backup. What no label tells you: the queue depth and IOPS cap the hypervisor applies to your virtual disk, the current load from neighbours, and whether the array is local to the host or over a network. Those three decide what fio reports, and they change over time.
When disk performance decides
- Database larger than memory. When the working set does not fit in RAM, every query that misses cache is a disk read, and random 4K read IOPS become the limiting resource. This is the case where a fio result should be part of the buying decision.
- Write-heavy workloads. Logging at volume, message queues, bulk imports, and any database with many small commits; fsync latency shows up directly.
- Many small files at once. Package installation, container image builds, static site generators over thousands of files, and search indexing.
- Where it rarely decides: a cached website. With a page cache in front and an object cache behind, a WordPress or Node site on a 2 GB server reads mostly from memory, and disk speed shows up at cold start and during updates. Memory and a working cache usually buy more than a faster disk.
Measuring your own server with fio
fio is the standard Linux I/O tester. Run it on the server you bought, on the filesystem you will use, with direct I/O so the page cache is bypassed, and with a test file larger than RAM so cache cannot help. Each test here runs 30 seconds; the whole block takes about two minutes and writes a 4 GB file that it deletes afterwards.
apt install -y fio # Debian/Ubuntu; dnf install fio on RHEL-family
cd /var/tmp
# 4K random read, queue depth 32 (database-style reads)
fio --name=randread --filename=fio.test --size=4G --rw=randread --bs=4k --ioengine=libaio --iodepth=32 --direct=1 --runtime=30 --time_based --group_reporting
# 4K random write with fsync (database-style commits)
fio --name=randwrite --filename=fio.test --size=4G --rw=randwrite --bs=4k --ioengine=libaio --iodepth=32 --direct=1 --fsync=1 --runtime=30 --time_based --group_reporting
# 1M sequential read (backups, large files)
fio --name=seqread --filename=fio.test --size=4G --rw=read --bs=1M --ioengine=libaio --iodepth=8 --direct=1 --runtime=30 --time_based --group_reporting
rm -f fio.testRead the IOPS line for the 4K tests and the bandwidth line for the 1M test, and note the completion latency percentiles (the clat lines), which say more about a shared disk than the average does. Run the block three times at different hours of the day and different days of the week; the spread between runs is your measure of contention. Compare against what your application needs, not against a leaderboard: a small site that does a few hundred IOPS at peak gains nothing from a disk that can do fifty thousand. On hourly-billed providers (Vultr, Linode, DigitalOcean) you can run this on two plan lines for a few cents and keep the one that measured better; on monthly providers, run it in the first day and use the result to decide whether to keep the server.
Caveats that make most published fio numbers, including the ones this page used to carry, unreliable: a test file smaller than RAM measures cache; a single run measures one moment on a shared host; a test on a fresh, empty server measures a lighter host than the one you will have in a year; and a test on a provider's own benchmark instance is not a test of your plan.
Configuration that reduces disk dependence
On a 2 GB server the cheapest disk upgrade is not to need the disk. Give the database enough memory to hold its working set (MySQL's innodb_buffer_pool_size, PostgreSQL's shared_buffers and the OS page cache), put an object cache (Redis or Memcached) between the application and the database, and put a page cache (nginx fastcgi_cache or the application's own) in front of the application. Mount with noatime so reads do not cause writes. Put temporary files on tmpfs if memory allows. Add swap on small servers, sized so a memory spike goes to disk rather than to the OOM killer; swap is slow, but it is slower to restart the database. None of this is specific to a provider, and all of it is in the hardening guide and the WordPress guide.
What this page could not verify
- Any IOPS, throughput or latency figure for Vultr, Linode, DigitalOcean, Hetzner, OVHcloud, Contabo, InterServer, Hostwinds, RackNerd, Kamatera, BuyVM or CloudCone: none published, none measured here.
- Whether "SSD" on the pages that say only that (BuyVM, Contabo's Cloud VPS line, Vultr vc2, DigitalOcean Basic, Hostwinds "Solid State Drives") is SATA, SAS or unlabelled NVMe.
- Per-server IOPS caps or throttles at any provider: not stated on the pages read.
- Oracle Cloud's block volume figures: its documentation sets performance by "Volume Performance Units" per GB with a Balanced default; the per-level IOPS tables are on separate pages not read for this version.