Benchmarks / Hyperscalers and VPS hosts
vs AWS, Azure, Google Cloud, DigitalOcean and Hetzner
The method for this board is published and dated. The board itself is empty, because we have not run it. That order is deliberate: rules written before anyone knows who wins are much harder to argue with than rules written afterwards.
Five providers, in two groups. AWS, Azure and Google Cloud are hyperscalers. DigitalOcean and Hetzner are not, and this page does not file them under a heading that says they are — they sell VPS instances, a narrower product on a different pricing model. They share a board because the spec cohort decides who is comparable, not the size of the company.
No results published
- Methodology published
- Boards published
- 0
- Runs completed
- 0
- Providers compared
- 5
- Spec cohort
- C8
We do not claim a hardware advantage. This board compares purchasable plans, not silicon. Nothing here asserts that Olympia designs, owns or operates the machines behind any plan on it, and nothing here should be read as a claim about proprietary hardware. The unit of comparison is a plan, measured against a fixed spec cohort and normalized by the price you actually pay for it.
Who is on this board
Five providers plus us, printed in the two groups they actually belong to rather than smoothed into one list. Three of these companies run global platforms with hundreds of services; the other three, Olympia included, sell servers. The cohort rule in the methodology below treats every one of them identically.
Included — hyperscale providers
- Amazon Web Services
- Microsoft Azure
- Google Cloud
Included — VPS hosts
- DigitalOcean
- Hetzner
- Olympia
DigitalOcean and Hetzner are not hyperscalers. Calling them one to keep a page title tidy would be the first false statement on a page whose entire argument is that it does not make any. They are in the second group with us, which is the point: the two companies nearest to what Olympia sells are being compared against the three that are nothing like it.
Excluded, and why
- Akamai (Linode). Akamai’s terms prohibit performance testing of the service. Linode therefore cannot appear on any Olympia board. We are not going to breach a provider’s terms to produce a chart.
- Any provider whose current terms forbid benchmarking or publication. We re-read each provider’s terms and record the clause and the date we checked before a board goes live. A provider we cannot test openly is listed as excluded, not tested quietly.
AWS, Azure and Google Cloud all now permit publishing benchmark results provided you publish enough detail for a third party to replicate them. This replaced the older arrangement, under which you needed the provider’s prior written consent. It is not a footnote here — it sets the disclosure bar for the whole page. Every command line, image, instance type, region and raw output file is published because publishing them is the condition under which results may be published at all.
DigitalOcean and Hetzner are a weaker case and we are not going to dress it up as a stronger one. We read DigitalOcean’s Terms of Service and Acceptable Use Policy, and Hetzner’s Terms and Conditions, on and found no clause restricting benchmarking or the publication of results. That is the absence of a restriction, not a written permission, and it is the weaker of the two things a provider can give you. Both are re-read and re-dated before any board carrying them goes live, and if a restricting clause appears they move to the excluded column that day.
The same disclosure bar applies to every row regardless. A lower legal requirement is not a reason to publish less about a run.
Why each of these is on the board
One paragraph on what each provider is genuinely good at, because a comparison that only lists what a competitor lacks is not a comparison. None of this is a measurement. Nothing on this page is, yet.
Hyperscale providers
Amazon Web Services
If you need managed services, global reach, compliance attestations, or the specific primitives that only exist on a hyperscaler, nothing on this page substitutes for that. A flat VPS is a different product, not a cheaper version of the same one.
Microsoft Azure
If you are already a Microsoft shop — identity in Entra, licensing agreements, compliance commitments — the gravity is real and it is not irrational. Those integrations are the product.
Google Cloud
Data and machine-learning workloads that lean on the managed products have no equivalent on a single VPS, and pretending otherwise would waste your time.
VPS hosts
DigitalOcean
Excellent documentation, a large managed-services catalog, and an app platform that does a lot of the work for you. For teams who want to grow into managed databases and Kubernetes without changing provider, that path is real.
Hetzner
Hetzner is a large, long-established host running its own data centers, with a deep product range and a lot of institutional knowledge behind it. If you are comfortable running your own infrastructure and don’t want anybody else involved in it, that is a perfectly reasonable place to be.
Olympia
We sell one of the plans that will appear on this board. That is a conflict of interest, it does not go away by being disclosed, and it is the reason the raw output archive in step 06 is not optional. Read the archive rather than our summary of it.
No figure appears in any of the paragraphs above, on purpose. Prices, specs and capacity claims live on the comparison pages linked from each entry, where a figure is either printed with the provider’s own price page as its source and the date it was checked, or replaced by the reason it could not be verified. For AWS, Azure and Google Cloud that reason is structural: a metered bill has no single monthly number to sit next to a flat price, so those entries work a full example rather than invent one.
Methodology
Version 1, published . Changes are versioned and dated on this page, so you can check whether the method moved after the results came in.
01 — Spec cohort
Cohort C8: 8 vCPU, 16 GB RAM, 320 GB NVMe-class block storage
A cohort is a fixed spec, not a fixed product. Every plan on the board must meet or exceed all three dimensions plus a Linux baseline: Debian 13, stock kernel as shipped by the image, no tuning beyond what a customer gets on first boot. Results are never compared across cohorts, and a cohort’s scores are meaningless outside it.
02 — Tier equivalence
The cheapest plan at each provider that meets or exceeds the cohort
Comparing our tier against a competitor’s premium tier — or against their entry tier — is the single most common way a vendor table gets rigged. So the plan is chosen by rule, not by us: at each provider, the lowest-priced plan that satisfies every dimension of the cohort. If a provider has no such plan, that provider is absent from the board for that cohort. We do not approximate, interpolate, or “adjust for” a mismatched plan.
03 — What we run
Exact tools, exact command lines
Published in full so the run can be reproduced without asking us anything. All of these are open-source and license-clear for publishing results commercially.
# Environment capture (recorded with every run, published with the board)
lscpu; free -g; uname -a; cat /etc/os-release
sudo dmidecode -t system -t processor
lscpu --extended; cat /sys/devices/system/cpu/vulnerabilities/*
# CPU - integer/branch mix
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) --time=60 run
# CPU - compression, mixed integer workload closer to real builds
7z b -mmt$(nproc)
# CPU - crypto paths most web workloads actually hit
openssl speed -evp aes-256-gcm -seconds 10
openssl speed -evp sha256 -seconds 10
# Storage — random and sequential, O_DIRECT, no page-cache flattery
fio --name=randread --rw=randread --bs=4k --iodepth=32 --numjobs=4 \
--ioengine=libaio --direct=1 --size=8G --runtime=120 --time_based \
--group_reporting --output-format=json
fio --name=randwrite --rw=randwrite --bs=4k --iodepth=32 --numjobs=4 \
--ioengine=libaio --direct=1 --size=8G --runtime=120 --time_based \
--group_reporting --output-format=json
fio --name=seqread --rw=read --bs=1M --iodepth=16 --numjobs=1 \
--ioengine=libaio --direct=1 --size=16G --runtime=120 --time_based \
--group_reporting --output-format=json
# Network — to a fixed, independently hosted endpoint, both directions
iperf3 -c $ENDPOINT -t 60 -P 8 --json
iperf3 -c $ENDPOINT -t 60 -P 8 --json -R
# Database — Postgres, dataset sized past RAM so the disk is in the loop
pgbench -i -s 500 benchdb
pgbench -c 32 -j 8 -T 300 -M prepared --progress=30 benchdb
# Key-value — Valkey, not redis-benchmark (see note below)
valkey-benchmark -t get,set -n 1000000 -c 50 -P 16 --csv
# HTTP - the same application image on every plan
oha -z 60s -c 100 --no-tui http://127.0.0.1:8080/
# (wrk -t8 -c100 -d60s http://127.0.0.1:8080/ is run as a cross-check)
We use valkey-benchmark, not redis-benchmark. Redis moved to RSALv2/SSPL, which is why we do not offer Redis hosting at all — running and publishing under that license is a problem we can simply avoid. Valkey is BSD-licensed, is what we actually offer, and measures the same thing.
If a Geekbench 6 figure ever appears here it will be run under a paid Geekbench 6 Pro license (US$99). The free tier is licensed for non-commercial use only, so it cannot be used to produce numbers for a company’s marketing page.
04 — Sampling
Three runs, three separately provisioned instances
Each plan is measured on three instances that are provisioned independently and destroyed between runs, in the same region, started at three different hours of the same UTC day. Three runs on one box measures that box and its neighbors; it does not measure the plan. The first run after provisioning is discarded as warm-up. We report the median of the three instance means, the standard error across instances, and N — always visibly, in the same cell.
05 — Scoring
A cohort composite, then divided by price
Score is the geometric mean of each test’s result normalized against the cohort median, multiplied by 100. The cohort median therefore scores 100 by construction; the number is a position within one cohort, not an absolute capability, and it does not transfer between cohorts or between pages. Points per $10/mo is Score divided by the plan’s monthly price in units of ten dollars. That is the column we care about, because price-normalized value inside a matched cohort is a claim we can defend regardless of whose hardware is underneath.
06 — Disclosure
Raw output ships with the board or the board does not ship
Every board is published with the full JSON and console output of every run, the image and kernel version, the CPU model as reported by lscpu and dmidecode, the mitigation state, the region, and the UTC timestamps. Including our own. If a run embarrasses us it goes in the archive anyway — a selectively published archive is worse than none.
07 — Recency
180 days stale, 270 days gone
A result older than 180 days is marked stale on the board. Older than 270 days and the row is removed rather than left to quietly age. Prices in the $/mo column are re-checked from each provider’s public price page on the day of publication, dated, and archived. Performance ages slowly; pricing does not.
08 — Refusal to rank
When we will not print an ordering
If two plans’ medians fall within two standard errors of each other, they share a rank and the board says so. We do not publish a cohort with fewer than three providers on it, and we do not publish any row with N < 3. A ranking we cannot defend against our own error bars is not a result, and we would rather show a tie than a number that reads better than it is.
Cohort C8 board
This is the table the results will land in, with its real columns, published now so the shape cannot be changed later to suit an outcome. The one row below shows the format of each cell. It contains no data.
| Rank | Provider & plan | Region | Score | ± SE (N) | $/mo | Points per $10/mo | Last run |
|---|---|---|---|---|---|---|---|
| Format example | Provider — plan name | region code | — | ± — (N = —) | $— | — | YYYY‑MM‑DD |
| No rows. Cohort C8 has not been run. | |||||||
Limitations
- We have not run these yet. Every table on this page is empty on purpose. There is no result, no partial result, and no internal number we are holding back.
- A benchmark measures the benchmark. The command lines are published above so you can judge for yourself how much any of them resembles your workload. If none of them do, the board should not persuade you.
- Virtualized capacity varies by host, by neighbor and by hour. Three independently provisioned instances is enough to show that variance exists and to size it roughly. It is not enough to characterize the tail, and we will not present it as if it were.
- One region per cohort, at first. Results do not transfer between regions, and a provider that does well in one region may not in another.
- Two of these five are not hyperscalers. DigitalOcean and Hetzner sell a narrower product on a different pricing model, and a matched-spec score will not tell you whether the managed services, the global footprint or the compliance paperwork you would have got from a hyperscaler were worth the difference. The board answers one narrow question — what a fixed spec costs and does at each provider — and that is narrower than the choice you are actually making.
- Price moves faster than performance. The $/mo column is a dated snapshot of a public list price. It excludes tax, egress overage beyond the included allowance, and support plans unless the board says otherwise.
- We are a party to this comparison. We ran it, we chose the cohort, and we sell one of the plans on it. That is exactly why the raw output is published — read it rather than our summary.
- No hardware claim is being made. Olympia has not decided whether it runs its own hardware or resells upstream capacity, and this board does not depend on the answer. It compares plans at their prices. Read nothing about silicon into it.
Both sides of it
The board above is empty, so it cannot help you decide anything today. This can. We sell the server, so the column on the left is the easy one to write. The column on the right is the one worth reading — if anything in it is a dealbreaker for you, it is a dealbreaker.
The case for
Why you’d pick us
- The price is one number, and you know it in advance. A metered bill is an estimate until the month closes. Our tiers are flat and published on the configurator: the figure you read before you buy is the figure that arrives.
- There is no egress meter running. Each tier carries a published transfer allowance rather than a per-gigabyte charge that only becomes visible after the traffic has already happened. What the allowance is, and what happens at the end of it, is written on the configurator rather than inferred from an invoice.
- You keep root, and you pick the region. Twelve regions across six continents, all offered on the same footing. The machine is yours to configure, and the data sits in a country you chose.
- There is nothing proprietary to become dependent on. A standard operating system on a standard virtual machine. The reason leaving is easy is that there is nothing to unpick — no managed service with no equivalent elsewhere, no runtime you had to adapt your application to.
- The method was published before the results existed. The cohort, the command lines, the instance types, the region and the raw-archive rule were all written down and dated while this board was still empty. You can check later whether any of it moved once the numbers came in.
- We will do the move, and the quote costs nothing. Scoped in a conversation and quoted in writing before you commit to anything.
The case against
Why you wouldn’t
- A VPS is not a smaller hyperscaler. Managed databases, queues, identity, global edge, the compliance attestations and the hundreds of primitives that only exist on a hyperscaler have no equivalent here. If your architecture leans on any of them, this is a different product and not a cheaper version of the same one.
- You are taking on an operations job. We look after the server — patching, backups, uptime. What runs on it is yours: deployments, TLS, outbound mail, storage that grows, and periodically proving a backup actually restores. We do sell managed hosting where we operate the application too, but it is quoted per engagement and there is no published price for it you can read off a page today.
- We hold no compliance certification. No SOC 2, no ISO 27001, no completed third-party penetration test — our own security page says so in those words. Every provider on this board can hand your procurement team paperwork we cannot.
- There is no uptime SLA and no uptime history. We do not run automated uptime monitoring yet, which is why our status page carries no percentage and no incident log. The providers above publish contractual availability terms and service credits. We do not.
- You cannot scale by API, and you cannot scale down at all. Elastic capacity is the reason metered billing exists. A flat monthly tier does not shrink on a quiet weekend and does not grow on its own at 3am. If your load is spiky, that trade may not go your way.
- Provisioning is manual, within 24 hours. Orders are fulfilled by a person, not an API. If you need a machine ninety seconds from now at three in the morning, that is not what we do.
- This board is empty, and an empty board proves nothing. A published method is a commitment, not evidence. Until cohort C8 has actually run, there is no measurement on this page to weigh against anything, and you should not treat the absence of one as a result in our favor.
- We are a party to this comparison. We chose the cohort, and we sell one of the plans that will be on it. Read the raw output archive rather than our summary of it.
What ships first
Cohort C8 across all five providers — AWS, Azure, Google Cloud, DigitalOcean and Hetzner — in a single region, published together with the complete raw output archive. This is the first board we will run, ahead of developer platforms. If a provider turns out to have no plan meeting every dimension of the cohort, it is absent from the board and the board says which one and why, rather than being quietly dropped.
There is no date attached to that, because the runs are not scheduled. A date we invented in order to look organized would be the first unverified number on this page, and the whole point of publishing the method before the results is that we do not do that.