Not in a real application. In a bare HTTP test on one CPU core, Bun 1.3.14 served 122,170 requests per second and Node.js 24.18 served 47,734, which is about 2.6 times as many. But a service with routing, validation and a database measured 12,000 requests per second on Bun, Node.js and Deno alike, because the database set the pace. "3× faster" is a benchmark result. It is not a promise about your site.
What the fast numbers actually measure
A benchmark published in July 2026 ran pinned versions (Node 24.18.0, Bun 1.3.14, Deno 2.9.1) on a 12-core Linux desktop. Absolute numbers depend on that machine, so read the ratios:
- Empty JSON endpoint, one core: Bun 122,170 requests per second, Node.js 47,734. Deno 2.9.1 led with 133,093.
- Cold start of a hello-world script: Bun 11 ms, Node.js 21 ms.
JSON.stringifyon a 3.3 MB payload: Bun 5.5 ms, Node.js 13.6 ms.- Installing 585 packages with a cold cache:
bun install5.8 seconds, npm 11.8 seconds. - Idle memory: Bun 36 MB, Node.js 49 MB.
BullMQ ran a queue benchmark of its own on Bun 1.3.3 and Node.js 24.13. CPU-bound work was 33% faster on Bun. Job processing, which waits on Redis, was only 12% faster. The more a task waits on something outside the process, the less the runtime matters.
Where the gap disappears
An independent test of a URL shortener with routing, validation and a database gave 12,000 requests per second on all three runtimes. The same author found a second problem: the popular load tool autocannon is itself written in Node.js and tops out near 65,000 requests per second on a 12-core machine. Any comparison made with it cannot tell two fast runtimes apart, and many articles that repeat "Bun is always first" were measured that way.
A 2025 peer-reviewed study of I/O-bound HTTP found 27,500 requests per second for Bun and 28,200 for Node.js, as summarised by Strapi. A Bun GitHub investigation, also cited there, measured Bun behind Node.js (11,800 against 16,200) on an allocation-heavy workload before a fix narrowed the gap. Bun can lose when a hot path creates many short-lived objects.
When Bun is worth it
- The service does a lot of JSON or other CPU work per request.
- Start-up time matters, for example short-lived jobs or scale-to-zero containers.
- Your CI spends minutes on
npm install. You can usebun installand keep running Node.js. - You want a built-in test runner and bundler without extra packages.
When Node.js is the safer choice
- You depend on native add-ons or a monitoring agent that supports Node.js first.
- Your hot path is allocation-heavy or your app is framework-heavy, where reports show Bun using more memory.
- You want a long-term-support release that every hosting guide and hiring pool assumes.
Test it on your own workload in 20 minutes
- Run the real application with its real database on the machine you will deploy to, not on a laptop.
- Use a load tool that is not written in Node.js, such as
oha:oha -z 15s -c 200 http://127.0.0.1:3000/health-or-real-route. - Run each runtime three times and take the median. Watch memory as well as requests per second.
- Switch only if the difference survives with the database in the loop.
You choose the runtime yourself on a cloud server, where you have root. A Cloud VPS Mini (1 vCPU, 1 GB RAM, from €14.99 per month) is enough for a trial API. With 1 GB of RAM, watch the memory column before you decide.
Questions
Is Bun faster than Node.js for a normal website?
Usually not enough to notice. If each request waits on a database or an external API, the runtime is a small part of the response time.
Can I use Bun only as a package manager?
Yes. bun install works on a project that keeps running on Node.js, and installs are the one place where the speed gain is clear and low risk.
Why do older articles show a bigger gap?
Many compared old Node.js versions, used a load tool that capped out, or tested an empty endpoint. Runtime benchmarks age fast, so check the versions in any article, including this one.
