Bun 2-3x ahead of Node on RPS. The runtime question is now serious.

Recent benchmarks across the three major JavaScript runtimes show a clearer split than at any point in the last three years [Pockit benchmarks].

── What the numbers say ──

On standard HTTP request-throughput workloads:

• Bun: 30,000–50,000 RPS
• Deno 2: ~22,000 RPS
• Node.js 22: 13,000–20,000 RPS

Bun's lead is built on a JavaScriptCore foundation (Safari's engine, not V8) plus a Zig-written runtime. Deno 2 shipped full Node.js/npm compatibility, removing the previous ecosystem barrier. Node remains the reference but is now slowest across most workloads [Strapi comparison].

── Why it matters ──

Until 2025, runtime choice was effectively forced — Node had npm, the others didn't. With Deno 2 shipping full Node compatibility and Bun shipping a mostly-drop-in Node API, the ecosystem barrier is gone for new projects.

The decision criteria for new services:

• Bun: pick for performance-critical I/O paths and dev tooling. The 2–3x RPS advantage compounds at production scale.
• Deno 2: pick for security-sensitive workloads. The permission model is genuinely innovative and the TypeScript-first defaults reduce build-step complexity.
• Node 22: pick for established teams with deep operational maturity around Node. Performance is no longer the strongest argument.

Migration risk is lower than the marketing implies. APIs are converging, npm compatibility is near-universal, and inter-runtime portability is more straightforward than even six months ago.

── Editor's take ──

The honest position: if you are starting a service today and have no operational dependency on Node-specific tooling, Bun is the default for greenfield. For existing Node services, the migration math depends entirely on whether request throughput is your bottleneck. For most CRUD apps, it isn't. For latency-sensitive APIs and BFFs, it is — and the 2x performance gap is the kind of thing that justifies a migration sprint.