Performance

Benchmarks

We are finalizing an independent, reproducible benchmark suite that compares DataVec to the major serverless platforms across common Web Worker workloads — routing, JSON, JWT verification, SSE streaming, static assets, and a pooled database query. Rather than publish numbers before that suite is complete and reproducible from a committed harness, this page explains the architecture behind DataVec's performance and the methodology we hold ourselves to. Measured results will be published here.

Independent benchmarks in progress

Performance comparisons deserve real, reproducible measurements — not marketing figures. We are running the op suite below on DataVec and on the major serverless platforms and will publish the full result set, with per-workload latency histograms and a committed harness, when it is ready. In the meantime, the sections below describe why the architecture is fast and how we intend to measure it.

Connection-oriented, not request-oriented

On DataVec, work lives on the connection: the TLS handshake is paid once and amortized over every request, the database session is pooled and reused across queries, and the compiled handler is always resident. A request-per-isolate runtime re-establishes that state per invocation — and a worker that can't carry a socket forward must reconnect to its database or rent a managed pooling tier. Connection-oriented execution is the root of the throughput and latency difference.

Compiled C, always resident

DataVec translates your handler to native C and runs it as a resident coroutine loop — ahead-of-time compiled (no JIT warm-up), 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.

The workloads

The same handler on every platform

Static routing — pure dispatch + framing on a tiny response.
JSON transform — parse a body, sum an array, serialize the result.
JWT verify — verify one token per request, both RS256 (RSA-2048) and HS256 (HMAC-SHA-256).
SSE token streaming — a chunked text/event-stream response (the AI-gateway shape, minus the model).
Static asset — serve a cached body at small and large sizes.
Database query — one indexed SELECT per request, isolating the connection model.

How we will measure

Same handler on each platform, a committed load driver and harness, and results that are reproducible on comparable hardware. We will state exactly what each workload does, publish the full latency detail (not just headline throughput), and call out the honest limits of what each comparison can and can't tell you.

Our methodology

Deploy JavaScript that compiles to native C

Standard Web Workers, Next.js static builds, and Elysia APIs with predictable pricing starting at $10/month.

Start Deploying Back to Homepage