Bun vs Node.js: which should you run in production?

Anthropic acquired Bun in December 2025 and runs it inside Claude Code, which tells you Bun is now production-grade for real workloads rather than a demo runtime. For a new project with no hard Node-only dependency, Bun is a reasonable default: it starts fast, bundles a test runner and package manager, and its Node-API compatibility sits above 95% as of the v1.3.x line, so most of the npm ecosystem just works. Choose Node.js when you need the last few points of that compatibility, especially native addons, or when you need the guarantees around it: a formal LTS release line, the broadest hiring pool, and mature observability agents (Datadog, New Relic, OpenTelemetry auto-instrumentation) that have years of Node-specific hardening. Bun is MIT-licensed, so licensing isn't the deciding factor. The honest split is compatibility and operational maturity for Node, developer ergonomics and cold-start speed for Bun. Pick by which of those your deployment actually cares about.

The performance gap is real but narrows under load

Bun's headline is speed, and the synthetic numbers are eye-catching: a hello-world HTTP server can push roughly 4x the requests per second of the Node equivalent. Don't provision on that figure. Once a real request does what production requests do, query a database, wait on a downstream service, serialize a nontrivial JSON payload, the runtime stops being the bottleneck and the gap collapses toward parity. Your p99 latency is dominated by the database round-trip, not by which JavaScript engine parsed the handler. Bun's genuine, durable wins are elsewhere: process start time (which matters for serverless cold starts and short-lived jobs) and toolchain consolidation, since bun install, bun test, and the bundler replace a stack of separate tools.

How to decide

Reach for Node.js when any of these is true: you depend on a native C++ addon that hasn't been validated on Bun, you need a supported LTS line for compliance or long-term maintenance, your on-call tooling assumes Node's process model, or your team hires against Node experience. Reach for Bun when you're starting fresh, your dependencies are pure JavaScript or already Bun-tested, cold-start latency is a cost line, and you'd rather ship one toolchain than assemble one. A pragmatic middle path exists too: use Bun as the local dev and test runner for its speed while deploying on Node, since the API surface overlaps heavily.

Notes from fernforge. Runtime and compatibility details per the Bun documentation; the acquisition was announced in December 2025.