Rust roughly doubles Node.js throughput in Cloud Run JSON-from-Redis benchmark

The setup

A developer has published a head-to-head benchmark on dev.to comparing Node.js and Rust on Google Cloud Run, and the outcome is one-sided: serving a cached 100 KB JSON document, the Rust service handled about twice the traffic at roughly half the latency on identical infrastructure.

The test was designed to be as I/O-bound as possible, on the theory that if most of a request's time goes to waiting on the network, the language should barely matter. Each service exposes a single GET /data endpoint that connects to Redis, reads one string and returns it as JSON — nothing else.

The stacks under comparison: the Node.js service ran Node 22 on Alpine with Fastify 5 and ioredis, while the Rust service used the Poem 3 framework on tokio with the redis-rs client in a distroless image. Both were deployed to Cloud Run with identical settings — 1 vCPU, 512 MiB of memory, exactly one instance (minimum = maximum = 1) and a concurrency limit of 20 — in the southamerica-east1 region around São Paulo. Pinning a single instance per service was deliberate, since it stops autoscaling from masking differences in per-instance capacity.

Redis itself ran on an e2-micro VM in the same zone, reachable over its internal IP via Direct VPC egress, with persistence disabled and a 512 MB memory cap. Pulumi provisioned the infrastructure, and a separate e2-micro VM generated load with wrk — 2 threads and 20 connections, matching the Cloud Run concurrency — after a 5-second warm-up and a 30-second measured run. The payload was a randomly generated JSON document of exactly 102,400 bytes.

The results

According to the dev.to post, Node.js sustained 237.72 requests per second while Rust reached 467.93, a 1.97x advantage. Transfer rates came out at 23.26 MB/s and 45.79 MB/s respectively. Average latency was 83.80 ms for Node.js versus 42.59 ms for Rust, and the gap held at every percentile: p50 was 81.34 ms against 42.16 ms, p90 was 95.26 ms against 48.79 ms, and p99 was 112.70 ms against 58.97 ms. Over the measured 30 seconds, that amounted to 7,139 requests served by Node.js and 14,051 by Rust.

The author points out that the two headline figures are mechanically linked: with a fixed pool of 20 connections, cutting per-request latency roughly in half doubles requests per second.

Caveats

The post is careful about what the numbers prove. This was a single test on one machine configuration, so the author frames it as a comparison of these two specific stacks rather than a general verdict on Node.js versus Rust. Both the Redis server and the load generator were e2-micro instances — a shared-core machine type — so either could be the real bottleneck; the author suspects this may be holding Rust back and did not test whether larger VMs push it further.

Each service also ran on a single Cloud Run instance with one vCPU, so under autoscaling the relevant figure is the per-instance throughput gap, which is what would eventually show up in cost. Finally, the author's explanation for the result — that reading 100 KB from Redis and writing it to the socket on every request burns more CPU than intuition suggests — is explicitly labeled a hypothesis, since no profiling was done. Everything needed to rerun the experiment, including both APIs, the Pulumi infrastructure and the benchmark script, is in the open-source repository andersondanilo/cloudrun-benchmark.

Why it matters

Serverless platforms bill by instance time, so throughput per instance converts directly into cost: a service that handles twice the requests on the same 1 vCPU allocation needs roughly half the instance-hours for the same traffic. The benchmark also chips at the common assumption that I/O-bound workloads make language choice irrelevant — even with a single Redis read as the only operation, the runtime accounted for a 2x difference once payloads reached 100 KB. For teams serving sizable cached responses on Cloud Run, a rewrite is not automatically justified, but the per-instance efficiency gap is large enough to put Rust on the shortlist for hot paths — and the reproducible setup makes it cheap to test the same scenario against your own workload before committing.