Bun is Fast. Your Event Loop is Not.

"Software engineering is more than just centering a div." — howtocenterdiv.com

TLDR: Bun wins benchmarks. Your app still bottlenecks on DB connections, blocking CPU work, and N+1 queries. Switching runtimes before fixing those is optimizing the wrong layer. Migrate bun install and bun test today — safe, immediate wins. Move the runtime only when the profiler tells you to.

Bun vs Node.js Performance: What Actually Matters

• database query latency
• connection pool exhaustion
• blocking CPU work in request handlers
• N+1 queries hiding inside loops

What Bun Actually Speeds Up

• Startup time — cold starts are noticeably quicker than Node.js
• Raw I/O throughput — built on JavaScriptCore and native APIs, file and network I/O is faster
• Tooling — bun install, bun test, bun build beat npm/jest/webpack by a significant margin
• Simple HTTP servers — if your handler does minimal work, you'll see the benchmark numbers in production

What the Event Loop Actually Is

codeCopy
1Request comes in
2  → handler starts
3  → hits await db.query(...)
4  → Event Loop: "ok, I'll park this, do something else"
5  → DB responds
6  → Event Loop: "pick this back up"
7  → handler continues
8  → response sent

The Promise.all Problem Nobody Talks About

javascriptCopy
1// "parallel" — looks efficient
2const [users, orders, inventory] = await Promise.all([
3  db.query('SELECT * FROM users WHERE active = true'),
4  db.query('SELECT * FROM orders WHERE status = pending'),
5  db.query('SELECT * FROM inventory WHERE stock < 10'),
6]);

codeCopy
1Connection pool size: 10 (default in most PG clients)
2
3Request 1: Promise.all — takes 3 connections
4Request 2: Promise.all — takes 3 connections
5Request 3: Promise.all — takes 3 connections
6Request 4: needs 3 connections, pool has 1 left → waits
7Request 5: needs 3 connections, pool has 0 left → waits
8...
950 concurrent requests: 150 connections needed, 10 available
10  → queue builds
11  → p99 spikes
12  → you blame the DB

When the Event Loop Actually Blocks

javascriptCopy
// Blocks everything for the duration — don't do this
const hash = crypto.pbkdf2Sync(password, salt, 100000, 64, 'sha512');

// Offloads to libuv thread pool — do this
const hash = await crypto.pbkdf2(password, salt, 100000, 64, 'sha512');

javascriptCopy
// Parsing a 50MB JSON payload — blocks
const data = JSON.parse(hugeString);

// Tight CPU loop — blocks
for (let i = 0; i < 1_000_000_000; i++) { /* ... */ }

javascriptCopy
import { Worker } from 'worker_threads';

const worker = new Worker('./heavy-task.js', { workerData: payload });
worker.on('message', (result) => resolve(result));

The Memory Question Benchmarks Skip

codeCopy
1Node.js under load:
2  → memory grows, GC kicks in, memory drops
3  → predictable sawtooth
4
5Bun under sustained load:
6  → memory can grow faster between GC cycles
7  → RSS climbs without dropping in some workloads
8  → you restart the process, it's fine — until it isn't

So When Does Bun Actually Matter?

Before You Switch Runtimes

codeCopy
11. Where does your p99 latency come from?
2   → Profile first. Don't guess.
3
42. Are your DB queries using indexes?
5   → EXPLAIN ANALYZE before anything else.
6
73. What's your connection pool size vs concurrent request count?
8   → pool_size = (core_count * 2) + effective_spindle_count
9
104. Are you doing synchronous CPU work in request handlers?
11   → Move it to workers.
12
135. Are you making N+1 queries inside loops?
14   → Fix this before touching the runtime.

The Migration Path

FAQ