Trigger.dev says swapping Node.js for Bun gave one service 5x throughput — with a memory-leak twist

The claim

It has been reported that Trigger.dev replaced Node.js with Bun for a latency‑sensitive service called Firestarter and saw a roughly 5× increase in throughput. Firestarter is a warm‑start connection broker that holds thousands of long‑poll HTTP connections from idle run controllers and matches incoming tasks to waiting controllers — no cold starts, no container spin‑ups. The team says the numbers come from a reproducible setup: 500 simulated controllers with k6 firing 50 concurrent supervisor requests for 30 seconds.

Why it mattered

The bottleneck wasn’t magic. Profiling showed Firestarter spending 31% of CPU time inside a SQLite query that flattened and indexed nested metadata; Zod validation and Object.fromEntries() also chewed CPU. After four rounds of profiling they rewrote the lookup as a composite‑key Map> (a null‑delimited key of deployment+version+cpu+memory), turning an overengineered correlated SQL lookup into an O(1) hash table. That swap alone reportedly produced a 2.2× throughput gain and a 2.2× improvement in median latency.

The Bun move and the surprise

Switching the HTTP layer from Node.js to Bun (using Bun.serve() and Bun’s native routing) reportedly doubled performance again, pushing the stack to the advertised ~5× improvement. Reprofiling on Bun surfaced different hotspots — and allegedly a memory leak specific to Bun’s HTTP model. It has been reported that Bun shipped a fix for that leak shortly after the post went live. Along the way the team praised Bun’s --cpu-prof-md output for being grep‑friendly and easy to read without DevTools.

What this means

So, is Bun the new default for high‑concurrency Node workloads? Maybe — but caveats apply. This is one carefully controlled benchmark on a particular long‑poll pattern; gains came from both algorithmic fixes and runtime change. Still: when you’re holding thousands of sockets, the HTTP implementation matters. The emotional takeaway? A few well‑placed optimizations and a different runtime can change everything. Want to blast past Node’s overhead? Profile first, then ask if the heavy lifting belongs in SQL or a simple Map.

Sources: trigger.dev, Hacker News