Benchmarking the New Edge Functions: Node vs Deno vs WASM

Edge functions are now a fundamental building block for modern applications. But which runtime should you choose? We ran a series of benchmarks focused on cold start, warm request latency, concurrency, and deterministic CPU-bound tasks across three popular runtimes: Node.js, Deno, and WebAssembly (WASM). These tests aim to surface trade-offs relevant to Programa.Space developers.

Benchmark setup

All tests were executed on identical edge nodes with the same resource caps. We used three representative workloads:

1. Echo — simple request/response to measure overhead and routing latency.
2. Computation — CPU-bound SHA-256 hashing loops to measure throughput.
3. IO-bound microservice — simulated DB reads using an in-memory cache to measure latency under concurrency.

Cold start behavior

Cold starts were measured by sequentially invoking functions after idling the runtime for 10 minutes. Results:

• Node: Cold starts were modestly quick (120–220ms) with pre-warmed runtimes available in many cases.
• Deno: Slightly longer cold starts (150–250ms) due to module resolution and type checking cost on some builds.
• WASM: Cold start variance depended on module size. Small WASM modules started in under 80ms, larger ones hit 300–500ms if initialization required heavy linear memory allocation.

Warm latency

Warm requests were tested with 1000 sequential requests after initialization:

• Node: Median 7–12ms for the echo route.
• Deno: Median 9–15ms, slightly higher due to runtime checks.
• WASM: Median 4–8ms for small modules — WASM shines for tight compute loops when compiled with optimizations.

Throughput and concurrency

Under high concurrency (500 simultaneous connections):

• Node: Scales well until event loop saturation; CPU-bound tasks started to queue beyond 200 concurrent operations.
• Deno: Similar profile to Node but with slightly higher CPU overhead.
• WASM: Provided better isolation for CPU-bound tasks — multiple instances could be scheduled with less interference, though memory limits constrained the maximum concurrency.

CPU-bound task results

For hashing loops:

• Node: Good performance using native crypto bindings; non-native JS loops were slower.
• Deno: Comparable to Node when using built-in crypto; raw JS less efficient.
• WASM: Best raw compute performance for optimized Rust modules, often approaching native speeds for tight loops.

Operational considerations

Beyond raw performance, consider:

• Observability: Node and Deno have mature tracing and logging ecosystems. WASM telemetry is improving but requires integration layers.
• Language ecosystem: Use what your team maintains. WASM adds complexity for debugging but offers high performance.
• Binary size and cold start: Optimizing WASM module size reduces cold-start penalties.

Recommendations

Choose a runtime based on workload:

• Low-latency I/O and business logic: Node or Deno — fast developer iteration and rich libraries.
• Compute-heavy kernels: WASM (Rust) — superior raw throughput and safer sandboxing.
• Mixed workloads: Hybrid approach — use edge WASM for heavy transforms and Node/Deno for orchestration.

Conclusion

There is no one-size-fits-all. Our benchmarks show WASM has a clear advantage for CPU-bound tasks while Node/Deno provide an excellent developer experience and broad ecosystem support. For Programa.Space projects, adopting a polyglot strategy that uses each runtime where it excels yields the best results.