Bun vs Node.js in 2026: Bun 1.4 vs Node 24 and 26, Benchmarked

I ran these benchmarks myself on one machine, and every number below comes from those runs. The original, with any updates, lives on fabwaseem.com.

Bun vs Node in 2026 comes down to this: Bun is a JavaScript runtime, package manager, bundler and test runner in one binary, built on JavaScriptCore and now written in Rust. Node.js is the V8-based runtime almost every server, library and hosting platform targets. Bun 1.4 reports Node.js 26 compatibility, so for many apps switching is now a runtime swap rather than a rewrite.

I benchmarked Bun 1.4.3 against Node.js 24.22 (the current LTS) and Node.js 26.12 (LTS from October 28) on one machine. I measured HTTP throughput with Hono, Express and plain node:http, a real Postgres-backed API, a large in-memory heap, startup, TypeScript execution, npm install vs bun install, next build, and native addons like sharp and bcrypt. Every number below comes from those runs.

TL;DR: should I switch from Node to Bun?

Use Bun as your package manager and script runner today: bun install was 13 to 29 times faster than npm in my tests and changes nothing at runtime. Consider Bun as your production runtime for new or dependency-light APIs, CLIs and serverless functions, where it was 1.4 to 1.8 times faster and used 25-70% less memory under load. Stay on Node.js for large existing services that depend on Node-specific APM, long-running stability or exotic native addons, and move to Node 26, which was 8-16% faster than Node 24 on most of my HTTP tests.

What is Bun, and how is it different from Node.js?

Bun is an all-in-one toolkit: a JavaScript and TypeScript runtime, an npm-compatible package manager, a bundler and a Jest-style test runner in one executable. Node.js is just the runtime and leans on npm, tsc or a loader, a bundler and a test framework from the ecosystem. Bun runs on Apple's JavaScriptCore engine; Node runs on Google's V8.

Bun aims to be a drop-in replacement. It implements Node's built-in modules (node:http, node:fs, node:crypto and the rest), reads package.json and node_modules the same way, and runs N-API native addons. It also adds its own faster APIs such as Bun.serve, Bun.sql and bun:sqlite.

What's new in Bun 1.4?

Bun 1.4 shipped on August 20, 2026, and it is the first Bun written in Rust instead of Zig. Per the Bun 1.4 release post, it adds "+1,517 tests from the Node.js test suite", fixes "over 2,900 issues", cuts idle CPU by 5x and memory by up to 35%, and "starts 50% faster on Linux." Bun now reports itself as Node.js 26 (process.versions.modules is 147).

It also absorbs common dependencies into the runtime: Bun.Image (image processing), Bun.WebView (headless browser), Bun.markdown, Bun.cron(), Bun.Terminal, plus bun run --parallel and bun test --parallel. Upgrading from 1.3 isn't free: the breaking changes list includes stricter TLS verification, YAML 1.2 parsing and no .env auto-loading when Bun is invoked as node. Vercel made 1.4 an explicit opt-in on its platform for the same reason.

How I benchmarked Bun vs Node.js

1. Machine. An 8 vCPU Intel Xeon VM with 15 GB RAM. Each server was pinned to 2 cores with taskset. The load generator, oha 1.16.0, ran on the other 6 cores with 64 connections.
2. Runtimes. Node.js 24.22.0, Node.js 26.12.0 and Bun 1.4.3, all official Linux x64 builds.
3. Apps. The same files ran on every runtime: a node:http hello server, a Bun.serve hello server (Bun only), a Hono 4.13 app, an Express 5.3 app, and a Hono route that reads one row from PostgreSQL 18 through pg 8.23 (or Bun.sql on Bun) with a 10-connection pool, across 10,000 users at random IDs.
4. Method. For every configuration: start the server, warm up for 4 seconds, measure for 10 seconds, read RSS from /proc. Each configuration ran 3 times and I report the median. Every request returned 200.
5. CLI timings used hyperfine 2.0.0 (40 runs for startup, 3 to 5 for installs and builds).

Postgres ran on the same machine without pinning, so the database test also measures a shared CPU. That's closer to a small VPS than to a tuned cluster.

Is Bun faster than Node.js?

For HTTP servers, yes, clearly. On the Hono JSON route Bun served 98,145 requests per second against 53,408 on Node 24 and 60,431 on Node 26: 1.84 times Node 24 and 1.62 times Node 26. Bun's advantage held on Express (1.55x Node 24) and on the plain node:http module (1.42x), and Bun.serve reached 128,461 requests per second.

Latency followed throughput. On the Hono JSON route p99 was 2.10 ms on Node 24, 1.95 ms on Node 26 and 1.17 ms on Bun. On the Postgres route p99 was 4.75 ms, 6.95 ms and 3.98 ms, and 3.50 ms with Bun.sql.

Two results surprised me. First, Bun stayed about 1.5 times faster even with a real database query in every request, which is where many "it's all the database anyway" arguments end. My database was local and fast, though. Over a real network, round trips will shrink that gap. Second, Node 26 alone was 8-16% faster than Node 24 on four of the five HTTP tests (the Postgres route was a tie), so upgrading Node is the cheapest speedup available.

Does Bun use less memory than Node.js?

Yes. Idle, a node:http server used 58 MB RSS on Node 24 and 23 MB on Bun, while Bun.serve used 16 MB. Under load the Hono app held 105 MB on both Node versions and 36 MB on Bun. On the Postgres route Node 24 grew to 206 MB against 61 MB for Bun with pg and 56 MB with Bun.sql.

The cache test is the exception worth reading. Bun started with less memory but briefly peaked higher (491 MB) than Node (455 MB). Bun's garbage collector is a known weak spot under large, long-lived heaps. A Bun pull request from this year described a GC "storm" that made allocation-heavy handlers run "at roughly half of Node.js" with a 150 MB live set. That PR #35431 was closed without merging. In my 1.4.3 run with a bigger heap Bun was still 28% faster than Node 24, but test your own workload, not a hello world.

How fast does Bun start compared to Node.js?

Bun starts about 8 times faster. An empty script took a median 3.3 ms on Bun against 28.5 ms on Node 24 and 26.3 ms on Node 26. Running a TypeScript file took 3.8 ms on Bun against 62.6 ms on Node 24. Node's built-in type stripping uses a WebAssembly-based parser, and here it added about 34 ms over an empty script. bun run launched a package.json script in 3.1 ms against 95.1 ms for npm run.

Startup matters for CLIs, cron jobs, serverless cold starts and test watchers. It barely matters for a long-running API server. Both runtimes run TypeScript directly now: Node's type stripping has been stable since v24.12.0 but only removes erasable syntax and ignores tsconfig.json, while Bun transpiles full TypeScript, including enums.

Is bun install faster than npm?

Much faster. On a Next.js 16.4.2 app with Tailwind, ESLint and TypeScript (458 packages), a cold install with empty caches and no lockfile took 15.4 seconds with npm and 1.15 seconds with Bun, 13 times faster. A CI-style install from a lockfile with a warm cache took 4.6 seconds with npm ci and 0.16 seconds with bun install --frozen-lockfile, 29 times faster.

This is the safest win in the whole comparison. bun install writes a normal node_modules, so you can keep running the app on Node. The cold number includes downloads over my server's network, so yours will vary.

# use Bun only as the package manager and script runner
bun install            # writes bun.lock and a normal node_modules
bun run build          # runs your package.json script with Node, as before
node server.js         # production stays on Node.js

Does Next.js work with Bun?

Yes. A Next.js 16.4.2 production build ran fine with bun --bun next build, in a median 3.03 seconds against 3.22 seconds on Node 24, about 6% faster. Turbopack does the heavy lifting in Rust either way, so the runtime matters less for builds than for serving requests. Without --bun, bun run build launches the Next.js CLI with Node because of its shebang.

bun install
bun --bun next build   # build with the Bun runtime
bun --bun next start   # serve with the Bun runtime

If you deploy with Docker, the base image changes from node:24-slim to oven/bun, and the rest of a production Next.js Dockerfile stays the same.

Do native modules work in Bun?

The common ones do. On Bun 1.4.3, sharp (image resize), better-sqlite3, bcrypt, argon2 and pg all installed from npm and passed the same smoke test as on Node 24. Bun runs N-API addons, which covers most popular native packages. Packages that pick a prebuilt binary by NODE_MODULE_VERSION need a build for 147, the ABI Bun 1.4 reports.

What still bites people is less about compatibility tables and more about operations: APM agents that patch Node internals, rare Node APIs, and memory behavior under months of traffic. The Bun Node.js compatibility page lists module-by-module status.

Is Bun faster at raw JavaScript?

Sometimes. CPU-bound micro-benchmarks were mixed, so don't expect a blanket speedup. Bun was about 3 times faster at parsing small JSON and 1.4 times faster than Node 26 on a 67 KB document, but JSON.stringify tied Node 26. Node 26 made a big jump over Node 24 on JSON, 1.8 times faster on stringify.

I dropped one test: a regex replace on a constant string ran at 196 million operations per second on Bun, which means JavaScriptCore optimized the work away. That's the trouble with micro-benchmarks. Trust the HTTP and real-app numbers more than these.

Should I use Bun in production in 2026?

For new services, it's a reasonable default now. Bun 1.4 is fast, frugal and broadly compatible, and platforms such as Vercel Functions run it. For existing Node services, migrate only when you can measure the benefit and you have tested memory over days, not minutes. Trigger.dev reported a 5x throughput gain moving a service to Bun and also hit a Bun-only memory leak on the way.

How do I migrate a Node.js app to Bun?

Move in three steps and keep a way back at each one. First swap the package manager, then run your tests on Bun, then switch the production runtime behind a canary.

# 1. package manager only (zero runtime risk)
bun install                 # creates bun.lock next to package-lock.json

# 2. run tests and scripts on Bun
bun run test                # your existing test script
bun --bun run test          # force the Bun runtime even for "node" shebangs

# 3. run the server on Bun, keep the code portable
bun src/server.ts

// portable entry point: Bun.serve on Bun, @hono/node-server on Node
import { Hono } from 'hono'

const app = new Hono()
app.get('/health', (c) => c.json({ ok: true }))

if (typeof Bun !== 'undefined') {
  Bun.serve({ port: 3000, fetch: app.fetch })
} else {
  const { serve } = await import('@hono/node-server')
  serve({ fetch: app.fetch, port: 3000 })
}

Frameworks built on Web standards, like Hono, make this painless because the same fetch handler runs on both. For database access, pg worked unchanged on Bun in my test, and Bun.sql is the built-in Postgres client that was 4% faster than pg on Bun in my test. If you're choosing an ORM, see Drizzle vs Prisma. If you self-host, Coolify runs a Bun Dockerfile like any other.

Common mistakes when comparing Bun and Node.js

• Benchmarking hello world only. Bun.serve vs node:http showed a 1.73x gap; Express showed 1.55x and a large-heap handler 1.28x.
• Comparing against an old Node. Node 26 was 8-16% faster than Node 24 on four of five HTTP tests. Compare against the Node you would actually run.
• Ignoring memory over time. A 10-second run says nothing about a slow leak. Watch RSS for days in staging.
• Running the load generator on the same cores. Pin the server and the load generator to separate CPUs, or the numbers mostly measure contention.
• Forgetting --bun. bun run executes scripts whose CLI has a #!/usr/bin/env node shebang with Node unless you pass --bun.
• Switching runtime and dependencies at once. Swap the package manager first; it gives most of the day-to-day win with none of the runtime risk.

Related: I also ran a NestJS 12 app on Bun 1.4.3: it served 1.49 times Node 24's requests per second on a hello route and started in 264 ms vs 361 ms. See the NestJS 12 migration guide.

Related: framework choice matters on Bun too. In Hono vs Express vs Fastify, Hono served 118,432 JSON requests per second on Bun 1.4.3, 1.62× its Node 24 result, while Express and Fastify gained less.

Key takeaways

• Bun 1.4.3 served 1.84 times Node 24's requests per second on a Hono JSON API, and 1.48 times with a Postgres query in every request.
• Bun used 25-70% less memory under load, for example 36 MB vs 105 MB RSS for the Hono app.
• Bun started in 3.3 ms versus 26-29 ms for Node and ran a TypeScript file in 3.8 ms versus about 60 ms.
• bun install was 13 times faster than npm cold and 29 times faster with a warm cache and lockfile.
• Node 26 alone was 8-16% faster than Node 24 on four of five HTTP tests, a free upgrade when it becomes LTS on October 28.
• sharp, better-sqlite3, bcrypt, argon2, pg and a Next.js 16.4 build all worked on Bun 1.4.3.
• Adopt Bun as package manager first, then as runtime for new services; keep large existing Node services on Node 26 until you've tested memory over days.

FAQ

Is Bun faster than Node.js?

For HTTP servers, yes. In my tests Bun 1.4.3 served 98,145 requests per second on a Hono JSON API against 53,408 on Node.js 24 and 60,431 on Node.js 26. With a Postgres query in every request Bun was 1.48 times faster than Node 24. CPU-bound micro-benchmarks were mixed, so the gap depends on the workload.

Does Bun use less memory than Node.js?

Usually. Under load my Hono app used 36 MB RSS on Bun versus 105 MB on Node 24 and 26, and the Postgres route used 61 MB versus 206 MB on Node 24. With a large in-memory cache Bun idled lower but briefly peaked higher, at 491 MB against 455 MB, so test memory with your own data.

Is Bun production ready in 2026?

For many services, yes. Bun 1.4 passes 1,517 more Node.js test-suite tests than 1.3, runs common native addons, and is offered on platforms such as Vercel Functions. Teams still report Bun-specific memory issues under long-running load, so canary it and watch memory for days before moving a large existing service.

Is bun install faster than npm?

Yes. On a Next.js 16.4.2 app with 458 packages, a cold install took 15.4 seconds with npm and 1.15 seconds with Bun. A lockfile install with a warm cache took 4.6 seconds with npm ci and 0.16 seconds with bun install --frozen-lockfile. It writes a normal node_modules, so the app can still run on Node.

Does Next.js work with Bun?

Yes. A Next.js 16.4.2 production build succeeded with bun --bun next build in 3.03 seconds against 3.22 seconds on Node 24. Use the --bun flag, because bun run otherwise launches the Next.js CLI with Node due to its node shebang. Turbopack compiles in Rust either way, so builds gain little.

Do native modules like sharp and bcrypt work in Bun?

The popular ones do. On Bun 1.4.3, sharp, better-sqlite3, bcrypt, argon2 and pg installed from npm and passed the same smoke test as on Node 24. Bun runs N-API addons and reports NODE_MODULE_VERSION 147, so packages that select a prebuilt binary by ABI need a build for 147.

Should I upgrade to Node 26 or switch to Bun?

If you have a large existing service, upgrade to Node 26 first: it was 8 to 16 percent faster than Node 24 on most of my HTTP tests and becomes LTS on October 28, 2026. Switch the runtime to Bun when you start a new service or can measure a clear gain in staging.

What changed in Bun 1.4?

Bun 1.4, released August 20, 2026, is the first Bun written in Rust instead of Zig. It reports Node.js 26 compatibility, adds 1,517 Node.js test-suite tests, fixes over 2,900 issues, starts 50 percent faster on Linux, and adds built-ins such as Bun.Image, Bun.WebView, Bun.markdown and Bun.cron. It also has breaking changes worth reviewing.

Originally published on fabwaseem.com.