Bun posts 59,026 HTTP req/s in vendor tests, ahead of Deno’s 25,335 and Node’s 19,039. This deep dive explains when that lead matters. Read now.
What the vendor numbers actually measure
Bun reports 59,026 HTTP requests per second in vendor tests, ahead of Deno at 25,335 and Node.js at 19,039. Those figures describe a specific kind of workload: a tight request loop, usually with a minimal handler, warm process, and controlled client concurrency. They are useful as a ceiling signal—how fast each runtime can move simple traffic when almost nothing else is competing for the event loop—but they are not a ranking of overall product quality.
Real services spend most of their time outside that micro-benchmark. JSON parsing, auth checks, database round-trips, cache misses, and outbound HTTP dominate wall-clock latency long before the runtime’s raw request dispatch becomes the bottleneck. If your p95 is already tens or hundreds of milliseconds because of I/O, shaving microseconds off framework overhead will not move the needle users feel.
When Bun’s HTTP lead matters
The gap matters when your service is CPU-bound on the request path and the payload is small. Edge-style APIs, health checks, feature-flag lookups, lightweight reverse proxies, and high-QPS internal gateways can hit the runtime itself as the constraint. In those cases, higher sustained requests per second under the same hardware budget means fewer instances for the same load, or more headroom before you scale out.
It also matters during load testing and capacity planning. If three stacks host the same thin handler, the one that clears more requests per second gives you a clearer picture of pure runtime cost. That comparison helps you separate “we need a faster database” from “we are leaving performance on the table in process.” Use it as one input alongside memory growth under concurrency, cold-start behavior if you scale to zero, and how your actual framework sits on top of the runtime.
- Prefer the faster runtime when the handler is short-lived, mostly in-memory, and request volume is the primary cost driver.
- Stay focused on Node.js or Deno when ecosystem libraries, deployment defaults, or team familiarity dominate delivery risk.
- Re-measure with your real middleware stack—auth, logging, validation—because vendor handlers rarely match production shape.
Where Deno and Node.js still win the decision
Throughput is only one axis. Node.js remains the default for the largest package ecosystem and the broadest hiring pool. If your roadmap depends on mature integrations, battle-tested ORMs, or internal modules already written for Node, switching runtimes for a benchmark win can cost more than the infra you save. Deno’s strengths sit more in tooling and defaults: a security model that is explicit about permissions, first-class TypeScript ergonomics, and a standard library story that reduces glue code for many greenfield services.
Stability under mixed workloads often matters more than peak requests per second. A service that streams large files, runs CPU-heavy transforms, or juggles many slow downstream calls needs predictable backpressure and debugging tools more than a higher micro-benchmark score. Choose the runtime that matches how you deploy, observe, and staff the system—not only how fast an empty handler can reply.
How to decide without chasing leaderboard scores
Start with a representative path: one authenticated endpoint that hits your real dependencies, instrumented for latency and error rate. Run the same scenario on Node.js, Deno, and Bun with comparable hardware and concurrency. Compare not only peak requests per second but also memory at steady state, failure modes under overload, and how painful local and CI workflows feel for the team that will own the service.
Treat the 59,026 vs 25,335 vs 19,039 numbers as a prompt, not a verdict. If your bottleneck is the network or the database, optimize there first. If profiling shows the runtime and framework on the hot path, Bun’s lead becomes operationally real. Ship the stack you can operate well; re-benchmark when traffic shape or cost constraints change.