Rust vs Node.js: backend benchmark and latency

Sharkbench is an independent community project that measures three things: a framework's ability to handle concurrent HTTP requests, I/O operations, and JSON serialization. The test runs under Docker/Linux on a Ryzen 7 7800X3D, with a last public update on August 24, 2025 (sharkbench.dev/web, accessed August 24, 2026).

Source: Sharkbench, August 24, 2025 — Docker/Linux, Ryzen 7 7800X3D.

Axum — the framework Aurabase uses for its Rust core, verified in Cargo.toml — processes 21,030 requests per second on this bench. Express, the Node.js framework most used in production, processes 5,766 on the same hardware: a factor of 3.6. This is not an isolated case. The four Rust frameworks tested all fall within a narrow range of 18,000 to 22,000 req/s, while the three Node.js frameworks tested cap out between 5,766 and 9,340.

In practice, “req/s” measures throughput under sustained concurrent load — not the speed of an isolated request on a low-traffic site. For an endpoint called once every few seconds, the difference is never seen. It becomes decisive on a hot endpoint — a real-time flow, a public API with heavy traffic, a job that strings together thousands of calls — where the number of requests processed per CPU core, for equal hardware, directly sets the infrastructure bill.

The average latency follows the same hierarchy on this bench: 1.4 to 1.7 ms for the Rust frameworks tested, compared to 3.4 to 5.5 ms for the Node.js frameworks tested.

Source: Sharkbench, August 24, 2025 — medium latency, not p99.

This figure is an average, not a p99. Garbage pauses in a managed runtime mostly affect the dispatch queue — the slowest requests, not the median. This is the subject of a dedicated article in this series: why the absence of garbage collector changes p99 latency.

Rust manages memory by ownership, checked at compile time — no garbage collector running in the background and interrupting execution. The official Rust Book summarizes it as follows: “None of the features of ownership will slow down your program while it's running” (The Rust Programming Language, doc.rust-lang.org, accessed August 24, 2026). Memory is freed as soon as the variable that owns it goes out of scope — a known time at compile time, not an unpredictable pause at runtime.

fn main() {
    let data = String::from("réponse API"); // `data` owns the string
    process(data); // possession leaves here
    // `data` is no longer valid here — no dangling pointer, no double free
} // `data` is released here, deterministically

fn process(s: String) {
    println!("{s}");
} // `s` goes out of scope here: immediate release, without garbage collection pass

Node.js, conversely, runs on a single JavaScript thread and delegates I/O operations to the kernel via a multi-phase event loop (timers, deferred callbacks, poll, check...) — but any synchronous computation on that thread, including a garbage collection pass from the V8 engine, blocks execution while it runs (official Node.js documentation, nodejs.org, accessed August 24, 2026). This is a memory model difference, not an implementation detail.

The most counterintuitive result from the same bench does not concern Rust: it concerns Node.js itself. Express — one and the same code, one and the same API — goes from 5,766 req/s on Node.js to 18,917 req/s on Bun, a factor of ×3.3, without changing a line of application code (Sharkbench, August 24, 2025).

Source: Sharkbench, August 24, 2025 — same Express code, three JavaScript runtimes.

On Deno, this same Express code caps at 6,088 req/s — close to Node.js, far from Bun. The JavaScript language is identical in all three cases; It’s the runtime — its JS engine, its event loop implementation, its garbage collection — that changes the game. Comparing “Rust” to “Node.js” without specifying the runtime, version and framework is like comparing configurations, not languages.

TechEmpower Framework Benchmarks illustrates the same idea on a larger scale. Its open source repository was updated on March 24, 2026, and its most recent round (round 23) was the subject of a post dated March 16, 2026 (TechEmpower, accessed August 24, 2026). This project runs many types of tests on hundreds of implementations, precisely because a single test never represents a framework, let alone a language.

Convex, a player in the database market, has formulated the clearest position on the subject: refusing to participate in the marketing “bar chart war” between competing databases, deemed misleading. “It's scaling theater, not scaling”, writes the team (Convex, accessed August 24, 2026). We share this reading: a bare figure, without a published methodology, proves nothing — neither for a competitor, nor for us.

What it changes in concrete terms: hardware (CPU, RAM), exact version of the framework and runtime, size of the JSON payload, level of competition and duration of the test all vary the ranking — sometimes more than the choice of language itself. A bench that does not publish these parameters does not reproduce, therefore does not verify itself — see our complete and reproducible methodology for benchmarking abackend.

The core backend of Aurabase is written in Rust, on axum and tokio — checked in the Cargo.toml of the monorepo: ten services (aura-gateway, aura-auth, aura-db…) share the same workspace dependency axum (0.8) and the same runtime tokio, in 2021 edition. The gateway which routes data plane and management plane traffic relies on hyper in addition to axum — the full details are in our article on the data plane / management plane architecture of the gateway. The structure of the Cargo workspace that supports these ten services is documented in our article on the Cargo workspace.

What we don't have yet is a published Aurabase throughput or latency figure with documented methodology and hardware. This is deliberate: we prefer to publish the methodology before the figure rather than the other way around — this is the subject of a future article in this series.

For the complete architecture comparison — unified Rust core at Aurabase versus heterogeneous stack Elixir/Go/TypeScript/Node documented at a direct competitor — see our detailed comparison Aurabase vs Supabase. If you are already migrating a project, the Supabase to Aurabase migration guide covers the schema, RLS policies and SDK.

All lines cited in this article, as published by Sharkbench on August 24, 2025 (Docker/Linux, Ryzen 7 7800X3D).

Cite this data: Sharkbench, “Web Framework Benchmarks,” sharkbench.dev/web, last updated August 24, 2025.

On the bench cited here, the Rust frameworks all run in a narrow range — 18,000 to 22,000 req/s, 1.4-1.7 ms — far ahead of the Node.js frameworks on Node.js itself (5,766-9,340 req/s, 3.4-5.5 ms). But the runtime changes the situation as much as the language: Express on Bun almost catches up with Axum on Rust.

If you evaluate a backend on raw performance alone, require the methodology before the number: hardware, version, payload size, level of competition. Aurabase has not yet released its own figures; when it does, the methodology will come first.