Benchmarks
What we measured, on which machine, and what we have not measured yet
Every number here comes from a run we recorded, with the date, the machine and the load. Where a test has only run in our sandbox or on a different size than the default node, the table says so.
The short answer#
On a Hetzner CX23, node 0.1.22 stored 28,803 of 28,803 events exactly once at 240 events a second for two minutes, p99 146 ms at the client.
Across three power cuts at 50 events a second, node 0.1.23 stored 24,001 of 24,001 events exactly once, with matching issue counts.
On 10 million synthetic events, the 24-hour issue list of one app took 7–9 ms on a CX33.
Under mixed load in our sandbox, errors kept a p99 acknowledgement of 18 ms while 6,000 spans and logs a second went through; this is not yet repeated on a CX23.
Ingest and durability#
| Date | Where | Load | Stored / sent | Latency |
|---|---|---|---|---|
| Oct 20, 2026 | Hetzner CX23, node 0.1.23 | 50 errors/s, power cut ×3 | 24,001 / 24,001 | p50 37 ms · p99 168 ms |
| Oct 20, 2026 | Hetzner CX23, node 0.1.22 | 240 errors/s for 120 s (3 projects × 80) | 28,803 / 28,803 | p50 62 ms · p95 97 ms · p99 146 ms · max 365 ms |
| Oct 25, 2026 | sandbox, node + ClickHouse pinned to 2 CPU | 50 errors/s + 2,000 spans/s + 4,000 logs/s for 120 s | 726,384 / 726,384 | p50 3.8 ms · p95 9.6 ms · p99 18 ms |
Stored / sent counts events the edge answered
200for and the node then stored; duplicates were counted separately and were zero in each run.Latency is measured at the sending client, so it includes the network to Cloudflare's edge.
The power-cut run reset the test node three times while the load ran. Reads came back within one minute after each reset.
Earlier runs of the same tests failed, and the fixes shipped in the node releases above. Node 0.1.18 lost 693 events across power cuts because ClickHouse had not flushed new parts to disk; 0.1.22 kept every event but under-counted 53 issue occurrences after a reset. We publish the passing runs with the version that passed them.
Query times#
| Query on 10 million events | Time |
|---|---|
| Issue list, one app, last 24 h | 7–9 ms |
| Overview of all 20 apps, last 24 h | 29 ms |
| Overview of all 20 apps, full 30-day scan | 118 ms |
| 14-day chart of one issue | 13 ms |
| Latest event of one issue | 33 ms |
| Text search in messages, one app | 25 ms |
| Text search across every stack trace (11 GB raw) | 1,070 ms |
Measured on 13 October 2026 on a CX33 (4 vCPU, 8 GB) in Falkenstein with 10 million synthetic errors across 20 apps, 5,000 issues and 30 days. New nodes use the smaller CX23, so expect these numbers to be slower there. Full-text search across every stack trace (11 GB raw) took about one second.
The same run created a server through the Hetzner API with HTTPS working on its hostname after 87 seconds. Node setup in the app was about 90 seconds in later tests.
How we run them#
Load comes from a script that sends real Sentry envelopes over HTTPS to the production edge, with test keys on a test workspace.
Counting checks that every
event_idthe edge answered200for is stored on the node exactly once, so a lost or duplicated event shows up by id.Power cuts are Hetzner hard resets of the node while the load runs, not clean shutdowns.
Machines are deleted after each run.
Not measured yet#
Mixed errors, traces and logs on a CX23. The sandbox result above is the only one so far.
Throughput above 240 events a second on one node.
Uptime alert latency from real outages at scale, beyond our own test checks.
Questions#
Can I reproduce these?#
The load scripts are not public yet. The method above is enough to run the same test with any Sentry-compatible load generator against your own node.
Why publish failed runs?#
Because the version numbers matter: a result is only true for the node release it ran on.
Try it on your own Hetzner project
Free during the beta. Hetzner bills the server; Belvador never bills per event.