Bun shipped a runtime that boots in milliseconds and installs dependencies an order of magnitude faster than npm. Node.js shipped native TypeScript, a stable permission model, and a built-in test runner. In 2026 this is no longer a hype-vs-stability story - it is a workload question with surprisingly clean edges.
Pick wrong and you will either pay for cold starts you did not need to pay for, or you will spend a quarter porting native modules that never worked under Bun in the first place. This is the call as it stands in May 2026.
The contenders
| Runtime | Stable | Released | Positioning |
|---|---|---|---|
| Bun | 1.3.14 | 2026-05-13 | All-in-one JS/TS runtime, bundler, test runner, and package manager written in Zig. |
| Node.js | 24.x LTS / 26.0.0 Current | LTS Apr 2025 · Current 2026-05-05 | OpenJS-stewarded reference runtime for server-side JavaScript, V8-based. |
Official: bun.com · nodejs.org. Node 24 is the Active LTS; Node 26 is the new Current line that enters LTS October 2026 (Node 26 release notes). Bun 1.3.14 added experimental HTTP/3 fetch+serve and ConPTY-backed terminal handling on Windows (Bun 1.3.14). One non-trivial context shift: Anthropic acquired Bun in December 2025, and Bun now backs Claude Code's CLI infrastructure (Bun joins Anthropic).
Verdict
Bun wins startup latency, install speed, and integrated developer experience by margins that are no longer debatable. Node.js wins ecosystem maturity, native-module compatibility, and first-party APM support. Pick Bun for greenfield Linux services where cold start or CI time is load-bearing - serverless, CLIs, AI agents. Pick Node for brownfield migrations, native-binding-heavy workloads, or anywhere Datadog APM and Cloudflare Workers are non-negotiable.
Performance
Performance is where the Bun marketing is most accurate and least useful. Raw HTTP throughput differences vanish behind any real framework. The numbers that actually change architecture decisions are cold start and install time.
| Dimension | Bun 1.3 | Node 24/26 | Winner |
|---|---|---|---|
| Cold start | ~10 ms | ~200 ms | Bun (~20×) |
| HTTP plaintext (TechEmpower R25, Q1 2026) | >1M req/s/core | ~400k req/s/core (Express) | Bun (~2.5×) |
| Install, 50-dep app | ~0.8 s | ~14 s (npm) · ~4 s (pnpm) | Bun (~17× vs npm) |
| Install, 800-dep monorepo | ~4.8 s | ~134 s (npm) | Bun |
| Bundler cold build | 60% faster than Bun 1.2 on macOS | BYO (esbuild/tsx/swc) | Bun |
| JS heap (Next.js, Elysia workloads) | 10–30% lower in Bun 1.3 | Baseline | Bun |
Sources: TechEmpower Round 25, Q1 2026 (the project was archived 2026-03-24); Bun 1.3 release blog, October 2025; install timings from DeployHQ and BetterStack. The install gap holds because Bun uses a binary lockfile and roughly 165k syscalls vs npm's 1M+ for the same install.
The honest read: HTTP RPS deltas are mostly noise once you put Fastify in front of Node, but the 20× cold-start gap is structural - it is why Anthropic moved Claude Code's CLI onto Bun and why Lambda cold-start workloads gravitate the same way.
Developer experience
Until 2025 this was Bun's strongest argument. Node has narrowed the gap aggressively. Native TypeScript shipped stable in Node 25.2 / 24.12 - no flag, no loader - for erasable TS. Enums, namespaces, and parameter properties still need --experimental-transform-types, but most application code Just Runs (Node TS docs).
| Capability | Bun | Node 24/26 |
|---|---|---|
| Native TS execution | Full incl. enums, JSX | Erasable TS stable; enums via flag |
| Built-in test runner | Vitest-compatible | node:test + --watch |
| Bundler | Built-in (bun build) | BYO (esbuild, tsup) |
| Package manager | Built-in, binary lockfile | npm 11 (Node 24 default) |
| Single-file executables | bun build --compile | --experimental-sea-config |
| Permission model | Not implemented | --permission (stable) |
| Built-in SQLite | bun:sqlite + Bun.SQL (Postgres/MySQL) | node:sqlite stable |
| Hot reload + React Fast Refresh | Built-in | BYO (vite, tsx --watch) |
Bun is still the only runtime where you can scaffold a TypeScript + React project, install, bundle, test, and produce a single binary without installing a tool other than the runtime itself. Node's answer is that you do not need a single binary - you have the entire npm ecosystem of mature tools. Both positions are defensible.
Ecosystem and production adoption
Bun reports ~98% Node.js API compatibility at the JS level and ~34% on native modules (byteiota production guide, 2026). Read that second number carefully - anything depending on node-gyp, prebuilt binaries, or N-API wrappers is the migration risk that gets people fired.
Public Bun-in-production signals are legitimate: X, Midjourney (notification fan-out over WebSockets), Anthropic (Claude Code CLI), Railway's serverless runtime, and Tailwind's shipping CLI binary. Node remains the runtime of record for essentially every enterprise CMS, backend monolith, and SaaS platform deployed before 2024.
The decisive signal for many teams is observability. Datadog has no first-party Bun tracer - its official guide routes Bun through OpenTelemetry as an unsupported runtime. NewRelic is the same posture. OpenTelemetry's Node SDK works through Bun's Node compatibility shim, but several auto-instrumentations break in ways that show up only in production. If your APM contract is Datadog-shaped, this alone is enough to choose Node.
Platform support has stabilized: Bun runs natively on AWS Lambda and Vercel as of early 2026 (Bun Lambda guide), but Cloudflare Workers does not run Bun - Workers still uses workerd/V8 isolates and there is no roadmap to change that.
Production reliability
Node still wins this dimension, but the gap is narrower than the Bun skeptics admit. The honest weaknesses each runtime carries in May 2026:
Where Bun still loses
- Native modules - ~34% compatibility. Database drivers with native bindings, image processing (sharp, canvas), some crypto wrappers, anything pulling node-gyp.
- APM - no first-party Datadog/NewRelic tracer. OTel via Node shim is the only path.
- node:vm and node:cluster - partial. Sandboxing/eval workloads are risky; sticky-session load balancing with handle-passing is incomplete (Bun Node compat).
- Windows - usable since 1.1 with ARM64 in 1.3.10, but still the platform with the most filed issues. Production Bun is overwhelmingly Linux.
- Cloudflare Workers - unsupported and unlikely to change.
Where Node still loses
- Cold start - ~20× slower. Disqualifying for short-lived serverless and AI agent CLIs.
- Install speed - npm 11 (Node 24 default) is ~65% faster than npm 10 but still 5–17× slower than Bun on real installs.
- Tooling fragmentation - TS execution is stable but tsc is still needed for type checking; bundling and testing remain BYO. New projects must still pick from Vitest/Jest, esbuild/tsup/rollup, tsx/swc.
- TS coverage - built-in stripping rejects enums, namespaces, and parameter properties without a flag.
Migration cost
If you are considering moving an existing Node service to Bun, audit in this order before you write a single line of code:
- 1. Native dependencies. and inspect every . This is the single highest break risk.
- 2. node:cluster usage. Fork mode works in Bun; sticky-session load balancing and inter-worker handle passing do not.
- 3. node:vm usage. Any sandbox/eval pattern needs verification; and some cachedData paths are missing.
- 4. APM lock-in. If Datadog APM is contractual, you are downgrading to OTel-bridge "Custom Components" support.
- 5. Deployment targets. Cloudflare Workers is a non-starter.
- 6. Test framework. Vitest mocks port cleanly. Jest with heavy jest.mock ESM hoisting has edge cases.
Pick rules
Pick Bun if
- You are starting greenfield on Linux.
- Cold start latency is load-bearing - serverless, edge functions, AI agent CLIs, short-lived workers.
- CI install time is a real bottleneck (large monorepos, frequent cache misses).
- You want an integrated toolchain - runtime, bundler, package manager, test runner from one binary.
- You ship single-binary CLIs.
- Your APM is OpenTelemetry-first, not Datadog-first.
Pick Node.js if
- You operate an existing Node service with non-trivial native dependencies.
- Datadog or NewRelic APM is a hard contractual requirement.
- You deploy to Cloudflare Workers.
- Your team relies on heavy node:cluster handle-passing or node:vm sandboxing.
- Operational stability and hiring availability matter more than raw runtime speed.
- Your Windows production footprint is non-trivial.
Final recommendation
For a new server, CLI, or worker in 2026 where you control the deployment target, default to Bun. The startup and install gains are structural, the API surface is now genuinely production-ready for application code, and the integrated toolchain compounds developer time savings across the year. Reserve Node for the cases above - and they are real cases, not theoretical ones.
For an existing Node service, do not migrate on principle. Migrate when a specific business constraint - cold start, install time, single-binary distribution - makes the audit checklist worth running. If your audit returns native modules + Datadog + Cloudflare, the migration math does not work in 2026, and Node 24/26's native TS, permission model, node:sqlite, and test runner have closed the DX gap enough that staying put is not a compromise.
The interesting thing about this comparison is what it is no longer about. It is no longer Bun-versus-Node on credibility. Bun ships, Anthropic underwrites it, and major platforms run it. It is now a workload-fit decision, which is the healthiest place a runtime comparison can be.
What's next
Watch three signals over the next six months: first-party Datadog support for Bun (would flip many enterprise decisions), Node's release-cadence change (one major per year in April, all majors becoming LTS in October starting with Node 27), and whether Bun 1.4 closes the native-module compatibility gap above 50%. Any of those three reshuffles the pick rules above.