We ran the same handler on both platforms across a suite of common Web Worker workloads — routing, JSON, JWT verification, SSE streaming, static assets, and a pooled database query. Both stacks are pinned to the same single CPU core— DataVec's runtime, and the Cloudflare-Workers shape's edge proxy plus runtime together (workerd can't terminate TLS or HTTP/2 itself, so its stack needs both). Every number below comes from a single fresh run on the same machine, over HTTP/2 + TLS, and is reproducible from a committed harness.
1.9 – 4.6×
Throughput, same single core
up to 55×
Pooled database queries
~2×
Lower p99 tail latency
0 ms
Cold start (resident)
Throughput · one core each
requests / second · higher is better
HTTP/2 · TLS · fortio -c 64
DataVec also holds a ~2–4× lower p99 tail on nearly every workload. The one exception is the 64 KB asset, where DataVec's HTTP/2 framing of a large body shows a wider tail — it still serves it 1.9× faster.
A request-per-isolate runtime may not carry a database socket from one request into the next, so every request either reconnects (a fresh TCP + auth handshake, ~180 ms under load) or rents a managed pooling tier. DataVec is connection-oriented: it opens the database session once per connection and reuses it for thousands of queries. Against the same query, DataVec is ~4× faster than the embedded-SQLite path and ~55× faster than reconnect-per-request to a shared PostgreSQL — a gap that widens with concurrency.
On DataVec, work lives on the connection: the TLS handshake is paid once and amortized over every request, the database session is pooled, and the compiled handler is always resident. A request-per-isolate runtime re-establishes that state — and pays an edge-proxy hop to reach the runtime at all. The throughput and latency wins above are all corollaries of that one architectural difference.
DataVec translates your handler to native C and runs it as a resident coroutine loop — ahead-of-time compiled (no JIT warmup), no interpreter, no garbage-collection pauses, and no per-invocation isolate to spin up. Because you pay for a running service rather than per request, there is no economic pressure to evict idle handlers, so they never cold-start.
How we measured
Both platforms ran on the same machine over loopback, so these figures isolate compute efficiency and cost per request— not geographic, real-network end-user latency, which depends on where a client sits relative to each provider's edge. DataVec on 1 core is compared against the Cloudflare-Workers deployment shape (edge proxy + runtime) pinned to that same one core. Numbers come from a single fresh pass; each is reproducible from a committed harness. One honest note: the very first request to a just-started DataVec instance pays a one-time TLS-handshake warm-up that a pre-warmed runtime doesn't — it amortizes immediately on a live connection.
Deploy standard Web Workers, Next.js static builds, and Elysia APIs with predictable pricing starting at $10/month.
