Methodology

How we ran these benchmarks

We would rather publish numbers you can reproduce than numbers that flatter us. This page states the exact setup, what each workload does on both platforms, the full latency detail, and the honest limits of what a loopback comparison can and can't tell you.

Setup

Same box, one core each, over the wire

Hardware: a single 8-core x86-64 Linux host; both platforms pinned with taskset.
DataVec: the DataVec Runtime pinned to one core, terminating HTTP/2 + TLS itself.
Cloudflare-Workers shape: the production deployment shape — a Pingora edge proxy terminating HTTP/2 + TLS and forwarding to the workerd runtime — with both tiers pinned to that same single core. workerd is HTTP/1.1-only and can't terminate TLS or HTTP/2, so the proxy tier is intrinsic to the architecture, not something we added.
Client: the load generator runs on separate cores, so neither server contends with it.
Protocol: HTTP/2 with TLS on every workload.
Load: fortio at 64 concurrent connections, keep-alive, 6-second runs, median of the reported percentiles; server-saturation checked.
Method: a single end-to-end pass so every row shares the same machine state.

Workloads

The same handler on both platforms

Static routing — a 12-byte response; pure dispatch + framing.
JSON transform — parse a JSON body, sum an array, serialize the result.
JWT verify — verify one token per request; RS256 (RSA-2048) and HS256 (HMAC-SHA-256). DataVec uses its native crypto; the Worker uses Web Crypto, key imported once per isolate.
SSE token streaming — stream a 50-event text/event-stream response from a ReadableStream (the AI-gateway shape, minus the model).
Static asset — serve a cached 4 KB / 64 KB body (both platforms serve from a pre-built buffer, no per-request work).
Database query — one indexed SELECT per request over the network, isolating the connection model. DataVec pools its session; the Worker either reconnects per request to shared PostgreSQL (349 req/s, ~180 ms) or uses embedded per-object SQLite (4,960 req/s).

Full single-core detail

Workload	DataVec · 1 core			CF-Workers · 1 core
Workload	qps	p50	p99	qps	p50	p99
Static routing	44,562	1.42	3.00	10,996	5.53	13.03
JSON transform	24,442	2.60	5.80	8,341	6.66	20.92
JWT verify — RS256	14,721	4.32	9.06	7,571	7.32	22.42
JWT verify — HS256	29,916	2.12	4.87	9,544	6.08	19.69
SSE token streaming	21,678	2.92	6.55	4,702	14.06	31.45
Static asset — 4 KB	31,137	2.04	4.75	8,714	6.77	15.51
Static asset — 64 KB	7,893	5.68	29.20	4,106	15.41	24.59
DB query — pooled	19,176	3.41	6.61	4,960	14.01	44.17

qps = requests/second on one core; p50 / p99 = latency in milliseconds. The database row shows DataVec vs. the embedded-SQLite Worker; the reconnect-to-PostgreSQL variant runs at 349 req/s (p50 180 ms).

Honest limits

What a loopback benchmark does and doesn't show

These measure compute efficiency and cost, not geographic latency. Both platforms ran on one machine over loopback, so there is no wide-area network in the numbers. What a user in a specific city feels depends on how close they are to each provider's edge — a different measurement we don't claim here.
We pin both stacks to one core rather than dividing a multi-core run. That is the conservative choice: the two-tier Workers stack is actually slightly faster confined to a single core (its proxy and runtime share a cache instead of talking across cores), so the ratios here are, if anything, generous to it. In production Cloudflare's edge proxy is a shared fleet amortized across many workers — but the two-tier hop is intrinsic to the architecture either way.
One cell's tail favors the Workers shape. On the 64 KB asset, DataVec's HTTP/2 framing of a large body shows a wider p99 tail; DataVec still serves it 1.9× faster overall.
First-connection warm-up. The very first request to a just-started DataVec instance pays a one-time TLS-handshake + instruction-cache warm-up (~100 ms) that a pre-warmed runtime doesn't. It amortizes immediately on a live connection and is distinct from per-request cold starts (of which there are none).
Cost is a ratio. The per-request cost advantage is the single-core throughput ratio; absolute dollars depend on your hosting price, so we quote the ratio rather than a headline dollar figure.

Reproducibility

Every number traces to a committed harness

The workloads, the load driver, and the cloud-comparison scripts are committed to our internal repository, and the full result set — with per-workload latency histograms and the architectural analysis — is documented alongside them. Re-running the harness on comparable hardware reproduces these figures. Measurements on this page were taken in June 2026 on the then-current DataVec Runtime and workerd build.

See the numbers in context

Back to Benchmarks View Pricing