The benchmarks are real. I just didn’t expect them to matter less than everything else.<\/p>\n
My team \u2014 four engineers, one of whom is constitutionally allergic to anything not boring and battle-tested \u2014 runs a mid-sized API service that handles about 12,000 requests per minute at peak. We’re on AWS, using Hono as our HTTP framework, PostgreSQL behind a PgBouncer connection pool, and a cluster of background workers that process job queues. Nothing exotic. Nothing that would make a Hacker News thread interesting for the right reasons.<\/p>\n
I started the Bun migration in November 2025. We went fully live in early February 2026. Bun 1.2.4 to be specific, running on Node.js 22.14 before the switch. This is what actually<\/a> happened.<\/p>\n So the honest reason I wanted to migrate wasn’t startup time or raw throughput \u2014 it was Lambda cold starts. We have a handful of event-driven functions sitting alongside the main API, and on Node.js 22 we were seeing cold start times between 800ms and 1.4 seconds depending on the function’s dependency footprint. That’s tolerable until your product team decides to add a user-facing webhook handler that runs on Lambda, and suddenly 1.1 seconds of cold start is a conversation at standup.<\/p>\n I’d been watching Bun’s progress since 1.0 dropped in September 2023. By mid-2025 the complaints about Node.js compatibility had quieted down considerably, most of the critical GitHub issues were closed, and the ecosystem was just… calmer about it. That felt like the right signal. I’m not an early adopter by nature \u2014 I let other people find the load-bearing bugs.<\/p>\n The other thing, and I should be upfront about this, was curiosity. Eight years of<\/a> Node.js means I can set it up in<\/a> my sleep, which is comfortable and also a little deadening. Bun forced me to actually think about the runtime again.<\/p>\n My skeptical teammate Marcus’s concern was simple: “We have zero on-call bandwidth for runtime-level weirdness.” He wasn’t wrong. I promised him a staged rollout with easy rollback, which is the only reason he agreed.<\/p>\n I expected That part took about a day. The test suite ran on Bun’s test runner without modification, which genuinely surprised me \u2014 I expected at least one Jest quirk to bite us.<\/p>\n What actually cost us time was our APM setup. We use Datadog, and the I pushed our first production deployment on a Friday afternoon and promptly discovered that our database query spans weren’t showing up in<\/a> Datadog. Not a crash, not a data issue \u2014 just invisible infrastructure. Which is a specific kind of Friday stress. We rolled back the APM config (not the Bun deployment, crucially) and spent the following week sorting it out properly.<\/p>\n By January we had full observability restored. But that two-week gap where I couldn’t fully trust my traces was uncomfortable in a way that benchmark numbers don’t capture.<\/p>\n Right, so \u2014 the actual numbers. I ran synthetic benchmarks before migrating, and I’ll share them, but I find the production data more interesting.<\/p>\n Synthetic load test, same Hono app, My Setup and Why I Actually<\/a> Pulled the Trigger on This<\/h2>\n
The Migration Itself: Mostly Fine, Then Not Fine at All<\/h2>\n
package.json<\/code> compatibility to be the main friction. It wasn’t. bun install<\/code> just worked, bun run<\/code> picked up our existing scripts, and Hono didn’t need any changes at all. The TypeScript handling through Bun’s built-in transpiler was a relief \u2014 no more ts-node or tsx config to babysit.<\/p>\n\/\/ Before: package.json scripts with ts-node\n"start": "ts-node -r tsconfig-paths\/register src\/index.ts",\n"dev": "nodemon --exec ts-node src\/index.ts",\n\n\/\/ After: clean\n"start": "bun src\/index.ts",\n"dev": "bun --watch src\/index.ts",\n<\/code><\/pre>\ndd-trace<\/code> Node.js agent has its own ideas about how to hook into the runtime. Bun 1.2 has solid node:<\/code> compatibility, but there are still specific internals that APM agents depend on \u2014 vm<\/code> module behavior, certain async_hooks<\/code> edge cases \u2014 and dd-trace<\/code> was partially blind in Bun for about two weeks<\/a> while I worked through the configuration. The Datadog Bun support page existed but was, charitably, aspirational. I ended up running their agent in compatibility mode and losing some auto-instrumentation for that period.<\/p>\nBenchmark Numbers from 3 Months of<\/a> Real Traffic<\/h2>\n
autocannon<\/code> at 1000 concurrent connections, PostgreSQL queries included:<\/p>\n