Bun 2.0 vs Node.js 24 vs Deno 3 in 2026

The JavaScript runtime wars entered a new phase in 2026. Bun shipped major improvements to Node.js compatibility and introduced built-in SQL and S3 APIs. Node.js 24 landed with a stable V8 13.6, a stable permission model, and built-in WebSocket support. Deno continued its 2.x series with deeper npm compatibility and a growing JSR registry. If you're starting a new server-side project today, the choice between these three runtimes has real consequences for performance, ecosystem access, and operational cost.

This article breaks down what each runtime actually offers, where the benchmark numbers come from, and which wins for specific workloads.

TL;DR

Serverless / startup-sensitive: Use Bun — 8-15ms cold start vs 60-120ms for Node.js. Long-running Node.js services: Stay on Node.js 24 — 100% ecosystem compatibility, LTS stability, stable permission model. Edge-native / Deno Deploy: Use Deno 2.x — best-in-class security model, JSR registry, native TypeScript execution.

Key Takeaways

Bun 2.0: 3.7x HTTP throughput over Node.js, 10x faster startup, 25x faster package installs, built-in Bun.sql and S3 APIs
Node.js 24: V8 13.6, stable WebSocket client, stable permission model, Undici 7 (30% faster HTTP requests), Float16Array
Deno 2.x: Full Node/npm ESM compatibility, JSR registry, deno add package manager, KV storage, secure-by-default
Real-world gap: Synthetic benchmarks show 3x differences; with real DB queries the gap narrows to ~10-15%
Migration cost: Bun runs ~95% of npm packages unchanged; Deno requires ESM and may need adapter shims for CommonJS

At a Glance

	Bun 2.0	Node.js 24	Deno 2.x
HTTP throughput	~52K req/s	~14-20K req/s	~29-85K req/s
Cold start	8-15ms	60-120ms	40-60ms
Package install	~25x faster than npm	npm/yarn/pnpm	deno add / npm compat
TypeScript	Native (no build)	Requires tsc/tsx	Native (no build)
npm compat	~95%+	100%	~90%+ (ESM)
Security	No sandboxing	Opt-in permission model	Secure-by-default
License	MIT	MIT	MIT

Bun 2.0: What Changed

Bun launched in 2022 with one promise: be fast. By 2026, the 2.x series has delivered on that and added enough APIs to replace most of the Node.js standard library stack in new projects.

Node.js Compatibility

Bun passes over 90% of Node.js's own test suite for supported modules. The practical result is that most npm packages — including complex ones like @grpc/grpc-js, prisma, drizzle-orm, and esbuild — run without modification. The remaining 5-10% of incompatibilities cluster around native addons (.node files) that depend on V8 internals, and packages that use undocumented Node.js internals.

New APIs in 2.x

Bun.sql is the standout addition: a built-in PostgreSQL client that outperforms pg and postgres.js because it's implemented in Zig at the runtime level, not JavaScript. Similarly, Bun.s3 provides S3-compatible object storage access without installing an AWS SDK. These built-in APIs reduce cold start time by eliminating the module loading overhead of large SDK packages.

Bundler Improvements

bun build gained improved tree-shaking, CSS bundling, and a plugin API that makes it usable as a Webpack or Vite replacement for simple frontend builds. For complex frontend pipelines with code splitting and hot module replacement, Vite remains more capable — but for server-side bundles, bun build is now a legitimate option.

Package Manager Speed

bun install installs from a global cache and uses a binary lockfile format. In a Next.js project with 400 dependencies, bun install completes in under 2 seconds versus npm's 45-60 seconds on a warm cache. The lockfile (bun.lockb) is binary and requires bun to read, which is a tradeoff for teams that need human-readable lockfiles.

Node.js 24: What Changed

Node.js 24 is not trying to be fast. It's trying to be the foundation you can build production systems on without worrying about breaking changes, security advisories, or ecosystem gaps.

V8 13.6

The V8 upgrade in Node.js 24 adds Float16Array — useful for ML inference workloads — and performance improvements to Promise handling and garbage collection. For most web API workloads, the V8 upgrade translates to a 5-15% throughput improvement over Node.js 22.

Built-in WebSocket Client

Previous versions required ws, socket.io-client, or undici for WebSocket connections. Node.js 24's WebSocketStream is built into the runtime, stable, and follows the WHATWG WebSocket API. This eliminates a common dependency for services that consume WebSocket feeds (trading data, telemetry streams, live collaboration backends).

Stable Permission Model

The permission model was experimental in Node.js 20 and 22. In Node.js 24 it's stable and production-ready. You can now run Node.js processes with explicit allow-lists for file system paths, network hosts, environment variable access, and child process spawning:

node --allow-fs-read=/data --allow-net=api.example.com server.js

This brings Node.js closer to Deno's security model without requiring a full migration. For regulated environments (fintech, healthcare), the stable permission model is a significant operational improvement.

Undici 7

The built-in HTTP client upgrade brings 30% faster HTTP requests for fetch() calls and connection pool improvements. For services making high-volume outbound API calls, this matters more than the V8 changes.

Deno 2.x: What Changed

Deno 2 shipped in late 2024 and the 2.x series has steadily improved npm compatibility through early 2026. The original vision — a TypeScript runtime with security-first design — now coexists with full Node.js/npm compatibility.

npm Compatibility

Deno 2 is backwards compatible with Node.js and npm in ESM. You can use npm: specifiers in imports, and deno add manages packages in a deno.json file that looks familiar to anyone who has used package.json. Packages that are CommonJS-only still require an adapter, but most of the top-1000 npm packages now have ESM versions.

JSR Registry

JSR (JavaScript Registry) is Deno's answer to npm. It enforces TypeScript-first packages, generates documentation automatically, and supports cross-runtime compatibility (Deno, Node.js, Bun, browser). In early 2026, JSR hosts thousands of packages including Deno's own standard library (@std/path, @std/fs, @std/http). For new libraries, publishing to JSR rather than npm gives better TypeScript support out of the box.

Deno KV

Deno KV is a built-in key-value store backed by FoundationDB in Deno Deploy. For serverless applications hosted on Deno Deploy, this eliminates the need for an external Redis or DynamoDB instance for simple caching and session storage. The API is stable and available as an npm package for Node.js projects that want to use it.

Security Model

Deno's secure-by-default model requires explicit permission flags for network access, file system access, and environment variables. This is more granular than Node.js 24's permission model and has been battle-tested over multiple major versions. For zero-trust environments, Deno's approach remains the most mature.

Benchmark Deep Dive

Raw benchmark numbers require context. Here's what the numbers actually measure.

HTTP Hello-World

On a bare HTTP server responding with "Hello, World!":

Bun: ~52,000 req/s (JavaScriptCore + Zig I/O)
Deno: ~29,000-85,000 req/s (V8 + Rust I/O, varies by benchmark setup)
Node.js: ~14,000-20,000 req/s (V8 + libuv)

The Bun advantage here is real. JavaScriptCore's startup profile and Bun's Zig-written I/O loop produce genuinely lower latency for simple request/response patterns.

Real-World API (with DB query)

When you add a PostgreSQL query per request, the numbers converge significantly. Bun's Bun.sql maintains an edge (~15%) but the network round-trip to the database dominates. For IO-bound APIs, the runtime choice matters less than connection pool tuning and query optimization.

Startup Time

This is where Bun has the clearest advantage with no asterisks:

Bun: 8-15ms
Deno: 40-60ms
Node.js: 60-120ms

On AWS Lambda, Bun averages 156ms total invocation time vs Node.js 245ms — a 35% improvement. For functions invoked millions of times daily, this translates directly to cost savings.

Package Install

On a project with ~400 npm dependencies, approximate times:

bun install (cold): ~3-4s
pnpm install (cold): ~25-30s
npm install (cold): ~50-60s

Ecosystem and Compatibility

For greenfield projects, all three runtimes can handle modern TypeScript applications. The gaps appear when you need specific packages.

Native addons (.node binaries): Node.js only. Packages like sharp, canvas, bcrypt (non-pure-JS versions) require V8 internals. Bun is working on compatibility but it's incomplete.

Next.js / Remix / SvelteKit: These frameworks target Node.js. Bun runs Next.js in development mode but production builds have edge cases. Deno requires shims. If your stack is a JS metaframework, Node.js is the safest choice.

Edge deployment: Hono, Remix, and SvelteKit's edge adapters target WinterCG-compatible runtimes. Both Bun and Deno are WinterCG-compliant. Node.js is not (yet).

TypeScript without compilation: Both Bun and Deno execute .ts files directly. Node.js requires tsx, ts-node, or a build step. For scripts, CLIs, and small services, the no-build experience with Bun or Deno is a significant DX improvement.

Migration Cost: Node.js → Bun

For a typical Express.js application:

Install Bun (curl -fsSL https://bun.sh/install | bash)
Replace node server.js with bun server.js
Replace npm install with bun install
Test — most packages work immediately

The failure cases are native addons and packages using undocumented Node.js internals. Before committing to a migration, audit your package.json for addons and run bun test to surface incompatibilities early.

For bun.lockb in CI, you need Bun installed in your pipeline. If your CI environment is tightly controlled, this is a new dependency to manage. Some teams keep package-lock.json alongside bun.lockb to preserve the option to fall back to Node.js.

Migration Cost: Node.js → Deno

The migration to Deno 2.x is more involved for CommonJS-heavy codebases:

Convert require() to import
Replace package.json with deno.json (or use --compat mode)
Update imports to use npm: prefixes or map in deno.json
Add permission flags to your run commands

For new projects, Deno's TypeScript-first, security-first approach is compelling. For existing Node.js codebases with mixed CommonJS/ESM, the migration effort is proportional to how many CJS packages are in the dependency tree.

Winner by Use Case

Serverless functions (AWS Lambda, Cloudflare Workers): Bun for Lambda (cold start), Deno for Cloudflare Workers (native WinterCG support).

Long-running API servers with complex npm deps: Node.js 24 — 100% compatibility, LTS support through 2027, stable permission model.

New TypeScript projects with minimal deps: Bun or Deno — native TypeScript execution, faster iteration, better DX for scripts and tools.

CLI tools and scripts: Bun — fastest startup, installs as single binary, compiles to standalone executables with bun build --compile.

Data pipelines and ML inference: Node.js 24 — best native addon support, Float16Array in V8 13.6, mature ecosystem for ML-adjacent libraries.

Edge-deployed applications: Hono on Bun or Deno — both are WinterCG-compliant; pick based on your deployment platform (Cloudflare → Deno/Node, AWS Lambda@Edge → Bun/Node).