Three weeks before launching a fintech dashboard for a payments client last year, my senior dev Priya walked into our Shoreditch office and said "I want to swap the API layer to Bun." I almost said no on instinct. Then I didn't. That decision taught me more about both runtimes than any benchmark thread on Hacker News ever could.
I've been building on Node since 2015. At Seahawk Media we've shipped over 12,000 sites and applications across WordPress, Next.js, Remix, plain Express, and plenty of stranger things. Bun entered our stack seriously around mid-2023. By now I have a proper opinion. Not a hot take. An opinion.
Here's what I've actually learned.
---
The Benchmark Conversation Is Mostly Noise
Every six months someone posts a fresh comparison showing Bun handling 80,000 requests per second against Node's 40,000 on some synthetic HTTP hello-world test. And honestly? That number is real. Bun's own benchmarks show genuinely impressive throughput, especially on I/O-bound workloads.
But here's the thing. Nobody runs hello-world in production.
The moment you add a real ORM, a Redis client, three middleware layers, JWT validation, and a file upload handler, the gap narrows considerably. I ran identical Express-compatible apps (one on Node 22, one on Bun 1.1) against a Postgres instance for the fintech project and saw Bun win by about 18% on p50 latency. Meaningful, not miraculous.
Where the speed actually matters
The place I've noticed Bun's performance advantage most isn't HTTP throughput. It's startup time and script execution. Running a one-off data migration script that Node takes 1.4 seconds to boot? Bun does it in 180ms. For CLI tooling, local dev scripts, and scheduled jobs, that difference compounds into real quality-of-life improvement across a team.
---
The Node Ecosystem Is Still an Unfair Advantage
I want to be direct about this because I see too many people gloss over it. Node's npm ecosystem is 15 years old. Bun is compatible with most of it, yes, but "most" is doing heavy lifting in that sentence.
Back in early 2024, a client project needed sharp for server-side image processing. Simple enough. Except the specific version we needed had a native binding that Bun's FFI layer didn't handle cleanly at the time. We burned a day on it before I just switched that service back to Node 20. No drama, no ideology, just pragmatism.
The compatibility story has improved a lot since then. But if your stack leans heavily on native Node addons (think canvas , argon2 , anything with .node bindings), test thoroughly before committing. Don't assume. Check the Bun compatibility tracker before you start a migration.
Package management is a different story
Bun's package manager is genuinely faster than npm, and I now use it even on Node projects. bun install on a project with 400 dependencies takes about 8 seconds on my M2 MacBook Pro. npm takes 47 seconds on the same machine. That's not a benchmark. That's me timing it last Tuesday with time bun install versus time npm install.
I use Bun as a package manager with Node as the runtime on probably 60% of our projects now. Best of both worlds.
---
TypeScript: Bun Wins This One Clearly
I'll be blunt. Running TypeScript on Node still requires a build step, or ts-node , or tsx , or some combination of configuration that makes me want to lie down. Bun runs .ts files natively with no config. None.
For internal tooling at Seahawk, this has been transformative. I write a TypeScript script, I run it with bun script.ts , done. No tsconfig.json gymnastics, no esm vs cjs drama. For a team shipping at speed across many client projects, the friction reduction is real.
The caveat: Bun uses its own TypeScript transpiler, not the official TypeScript compiler. So type errors won't stop execution. It strips types and runs. If you're relying on the TypeScript compiler for correctness guarantees at runtime (you shouldn't be, but people do), that's a gap to understand.
---
What I Actually Run in Production Right Now
Let me be specific because vague generalisations help no one.
On Node 22:
- All WordPress headless backends using WPGraphQL + Apollo Server
- Any service with native binary dependencies
- Long-running Express APIs with battle-tested middleware stacks
- Anything touching legacy codebase with heavy CommonJS modules
On Bun 1.1+:
- Internal CLI tooling and dev scripts
- New Hono-based API services (Hono on Bun is genuinely lovely)
- Scheduled cron jobs and one-off migration scripts
- Webhook receivers and lightweight edge-adjacent services
The pattern is pretty simple. Greenfield and internal tools: Bun. Client-facing production services with complex dependency trees: Node, unless there's a specific reason to switch.
---
The SQLite Incident (And What It Taught Me)
I mentioned this at the top. Worth explaining.
Bun ships with a built-in SQLite driver. Fast, zero-dependency, genuinely useful. On a staging environment for a content management tool in late 2023, we used it to store session data. After a particularly aggressive series of concurrent writes during load testing, the database file got into a weird state. Not corrupted beyond recovery, but locked in a way that required manual intervention at 2am my time.
Was it a Bun bug specifically? Honestly, I'm not certain. It may have been our write patterns. But on the same workload, the Node + better-sqlite3 setup I tested afterward didn't reproduce it.
The lesson isn't "Bun SQLite is broken." It's that Bun's built-in APIs, as convenient as they are, have less community surface area. When something goes wrong at 2am, you want Stack Overflow threads and GitHub issues. Node has seventeen years of those. Bun has three.
---
Deployment and Tooling Compatibility
This section matters more than people admit.
Vercel, Railway, Render, and Fly.io all support Bun deployments now. Railway in particular made it dead simple, roughly as easy as Node. AWS Lambda is trickier. You're packaging a custom runtime or using a layer, which adds complexity.
Docker is fine. oven/bun is the official base image and it works well. I use it on several services. The image is leaner than the Node equivalents if you care about that.
What's less mature is the observability layer. Tools like Datadog's Node.js APM agent, certain OpenTelemetry auto-instrumentation packages, and some Sentry SDK features work differently or not at all on Bun. I lost about four hours last spring figuring out why distributed traces were dropping spans on a Bun service. Turned out to be an async context propagation difference. Node's AsyncLocalStorage behaviour and Bun's implementation diverge in subtle ways that bite you in tracing.
If you're running serious production observability, test your entire telemetry stack before going live on Bun. Not after.
---
My Honest Take on the "Should I Switch?" Question
Here's a quick framework I use when a client or team member asks:
- Is this a new project with no legacy dependencies? Evaluate Bun seriously.
- Are you writing mostly internal tooling or scripts? Use Bun. Today.
- Do you need native addons or very specific npm packages? Stick to Node, test first.
- Is startup time or script execution speed a pain point? Bun will help noticeably.
- Are you on AWS Lambda or a platform without first-class Bun support? Node is less friction.
- Is your team already familiar with the Node ecosystem's quirks? Factor in the learning curve on Bun's differences.
And a few things worth watching:
- Bun's Windows support has improved dramatically but is still behind macOS and Linux on edge cases
- The
bun:testbuilt-in runner is actually good, but Jest plugins you rely on may not work - Hot module reloading with
--hotis impressive but occasionally unpredictable on complex module graphs
---
FAQ
Is Bun production-ready in 2026?
For specific use cases, absolutely yes. For a greenfield API service with minimal native dependencies, Bun is production-ready and has been for a while. For complex enterprise applications with years of Node-specific dependencies, I'd call it "production-ready with caveats." The caveats aren't dealbreakers but they require due diligence.
Should I migrate existing Node projects to Bun?
Almost certainly not, unless you have a specific problem Bun solves for that project. Migrations carry risk. If your Node app is working, the productivity cost of migrating rarely pays off compared to just using Bun on new projects. I haven't migrated a single existing client project. I've started new ones on Bun.
Is Bun faster than Node for all workloads?
No. CPU-bound workloads show minimal difference because both ultimately run V8 (Node) or JavaScriptCore (Bun). The gains show up most in I/O-heavy workloads, startup time, and anything where Bun's native implementations (HTTP server, file I/O, SQLite) replace JavaScript-layer equivalents. For a heavily computation-bound service, you won't notice much.
What framework works best with Bun?
Hono is the one I reach for. It's lightweight, TypeScript-first, and designed with runtimes like Bun in mind. ElysiaJS is the other popular choice and is Bun-native, with impressive benchmark numbers. I've used both. Hono I trust more in production because the community is larger and the edge cases are better documented.
Will Bun eventually replace Node?
Probably not replace. Coexist. Node has too much institutional momentum in enterprise environments and the npm ecosystem will keep both relevant for a long time. What Bun has already done is push Node to improve. Node 22 is meaningfully faster than Node 18, partly because the competition exists. That's good for everyone writing JavaScript server-side.
---
The runtime you pick matters less than the code you write on top of it. But picking the wrong one for the wrong project does cost you time, and time is the only thing I can't buy more of. Use Bun where it makes sense. Trust Node where it's earned. And for the love of everything, use bun install on both.