Bun reached 1.0 in late 2023. By early 2026, we've had it in production long enough to stop being excited and start being honest. This is what we've learned, where the runtimes diverge, and what we still leave on Node.
The short version
Bun is meaningfully faster for the things it's faster at, drop-in compatible for most things it claims to be, and still occasionally surprises you in ways Node never would. We use both. The choice is per-project, not per-team.
Where Bun wins
Cold start
If you're doing anything Lambda-shaped or CLI-shaped — short-lived processes, scripts, build tools — Bun starts up in a fraction of the time. We replaced our internal CLI tools with Bun and the difference is felt every single day.
Test runner
bun test is the test runner Node should have shipped in 2018. Jest-compatible API, zero config, fast enough that watch mode is actually pleasant. We migrated our smaller services off Jest entirely.
Built-in transpilation
Running TypeScript or JSX without a build step is genuinely useful for prototypes and internal tools. The Bun bundler is no replacement for esbuild or Rolldown for app builds, but for "run this script directly," it removes a category of friction.
Package installs
bun install is fast in a way that changes how you treat node_modules. We've stopped caching it aggressively in CI for some projects — it's faster to install from scratch than to validate a cache.
Where Node still wins
Long-running production services
Steady-state HTTP throughput on a properly-tuned Node process is competitive with or better than Bun for most workloads we've measured. The cold-start advantage doesn't matter for a process that lives for weeks.
Ecosystem depth
Some packages we depend on still misbehave under Bun. Native modules, anything that does clever things with the loader, certain telemetry libraries — every few months we hit something. The fix is usually pinning to Node for that specific service.
Observability
Production-grade tracing and profiling tooling is still Node-first. Bun's diagnostic story has improved, but if your incident response runbook involves --inspect, heap snapshots, or specific APM agents, Node is the lower-risk choice.
The compatibility footnote
Bun's headline is "drop-in Node replacement." This is true most of the time. The 5% of the time it isn't, you find out at the worst possible moment. We've been burned by:
process.versionsshape differences breaking a version check.- Subtle differences in how streams handle backpressure under load.
- One esoteric crypto API behaving slightly differently between versions.
None of these are showstoppers. All of them ate a half day before we found them. Treat Bun as a Node-compatible runtime, not as Node. Test the path that matters.
Our 2026 default
For a new service:
- Internal CLI / build tool / script: Bun.
- Long-running HTTP API with mature deps: Node, unless we have a reason.
- Greenfield app where we control the dependency tree: Bun, with an escape hatch in CI to test on Node too.
- Edge functions: Workers runtime (neither), via the platform's tooling.
What we'd tell ourselves in 2024
Don't pick a runtime for sentimental reasons. Bun is good. Node is good. The interesting questions in 2026 are about where your code runs (edge, serverless, container, longlived VM) more than which JS runtime it runs on. Optimise the choice for that, and the runtime question usually answers itself.