Bun vs Node.js vs Deno 2026 — benchmark production yang jujur

TL;DR

• Bun: menang benchmark (120K req/s, cold start 15ms), TypeScript native, 95% npm compatible. Greenfield project tanpa exotic native deps.
• Node 22 LTS: ekosistem paling mature, support universal, tim paling familiar. Default pilihan untuk existing project dan team yang belum ready eksperimen.
• Deno 2.0: permission model paling secure, edge function via Deno Deploy excellent. Kurang cocok untuk complex app yang butuh banyak npm package.
• Verdict: Conditional. Switch runtime hanya kalau ada bottleneck konkret — jangan benchmark-driven migration.

Konteks

Saya pakai ketiga runtime ini di berbagai konteks sepanjang 2025-2026:

• Node 22 LTS: 3 production app (fintech internal tools + API Jakarta), sudah jalan sejak Node 18, upgrade bertahap
• Bun 1.x: 2 greenfield project (SaaS internal reporting + CLI tooling), mulai Bun 1.0, sekarang di Bun 1.1
• Deno 2.0: 2 edge function di Deno Deploy (webhook handler + image resizer), plus eksperimen lokal

Background saya: Node sejak 2017 (9 tahun), Bun sejak beta 2023, Deno sejak 1.x 2022.

Tulisan ini bukan benchmark marketing — angkanya saya ambil dari kombinasi wrk test sendiri + referensi benchmark komunitas yang reproducible.

Benchmark numbers

HTTP throughput

Setup: wrk -t4 -c100 -d30s, server Hello World minimal, Apple M2 Pro, macOS 15.

Runtime	Throughput (req/s)	Latency avg	Latency p99
Bun 1.1	~120.000	0.8ms	2.1ms
Deno 2.0	~95.000	1.0ms	2.8ms
Node 22 LTS	~85.000	1.2ms	3.4ms

Bun menang ~41% vs Node, ~26% vs Deno di HTTP layer.

Tapi: ini micro-benchmark. Kalau app Anda query PostgreSQL (≥5ms), call external API (≥50ms), atau Redis (≥1ms), perbedaan 0.4ms di runtime layer tidak akan kelihatan di end-to-end latency user.

Cold start & memory

Runtime	Cold start	Memory baseline	TypeScript native
Bun 1.1	~15ms	~18MB	Ya (native)
Deno 2.0	~38ms	~28MB	Ya (native)
Node 22 LTS	~45ms	~35MB	Tidak (butuh tsx/ts-node)

Cold start penting untuk:

• Lambda/serverless function (setiap invocation cold start)
• CLI tooling yang dijalankan manual
• Container scaling horizontal yang sering spin up/down

Untuk long-running server (VPS, container selalu nyala), cold start tidak relevan.

TypeScript developer experience

Node tanpa tooling: tidak bisa jalankan .ts langsung.

# Node: butuh setup
npm install -D tsx typescript
# tambah script di package.json atau jalankan:
npx tsx src/index.ts

# Bun: langsung
bun src/index.ts

# Deno: langsung
deno run src/index.ts

Bun dan Deno wins besar untuk DX TypeScript. Node butuh extra step yang sudah jadi muscle memory developer Node lama, tapi friction buat newcomer.

Ekosistem maturity

Aspek	Node 22	Bun 1.1	Deno 2.0
npm package compatibility	100%	~95%	~85% (via npm: prefix)
Native module (C++ addon)	100%	80-90%	60-70%
Community library	Terbesar	Pakai npm	Deno std + npm
Framework support	Express, Fastify, Hapi, dll	Semua Node framework	Hono, Oak, Fresh
Hosting support Indonesia	Universal	VPS OK, PaaS varies	Deno Deploy + VPS

Node ecosystem advantage

9 tahun npm ecosystem tidak bisa diremehkan. Setiap problem: ada paketnya. Setiap error: ada Stack Overflow-nya. Setiap hosting: support Node.

Untuk konteks Indonesia khususnya:

• Midtrans SDK: officially Node, ada untuk Bun (compatible), Deno butuh workaround
• RajaOngkir/Biteship SDK: Node-first
• Firebase Admin, GCP SDK, AWS SDK: semua Node-first, Bun compatible, Deno butuh npm: prefix

Bun 95% compatibility — angka apa yang 5% itu?

Yang sering bermasalah di Bun:

• sharp (image processing, pakai native libvips): kadang butuh npm install manual instead of bun install untuk binary yang benar
• bcrypt (C++ binding): ada workaround, tapi lebih mudah pakai bcryptjs (pure JS) sebagai drop-in
• canvas (Node canvas): kadang tidak compile
• node-gyp dependencies: hit-or-miss

Solusi mudah: kalau butuh package yang problematic di Bun, ganti pure-JS alternative biasanya ada. Untuk bcrypt → bcryptjs. Untuk image processing → jimp atau sharp dengan fallback.

Production readiness per hosting

VPS Indonesia (Hetzner Singapore, AWS Jakarta, GCP Jakarta, Biznet)

Runtime	Status	Cara install
Node 22	✅ Official	nodesource.com atau nvm
Bun	✅ Manual	curl -fsSL https://bun.sh/install | bash
Deno	✅ Manual	curl -fsSL https://deno.land/x/install/install.sh | bash

Semua bisa di VPS — tidak ada hambatan. Node paling straightforward karena sudah ada di package manager distro.

PaaS (Railway, Render, Fly.io)

Platform	Node	Bun	Deno
Railway	✅	✅ Official	✅
Render	✅	✅ Official	✅
Fly.io	✅	✅	✅
Vercel Functions	✅	✅ (edge)	✅ (edge)
Deno Deploy	❌	❌	✅ Optimal

Shared hosting Indonesia (Niagahoster, Domainesia, DomaiNesia)

Shared hosting biasanya hanya support Node via cPanel. Bun dan Deno tidak relevant di konteks ini — untuk production app modern, pakai VPS.

Decision framework

Existing production app

→ Stay di Node kecuali ada bottleneck konkret.

Ganti runtime untuk app yang sudah jalan itu risk tanpa immediate reward kalau:

• App I/O-bound (database, external API) — runtime performance tidak observable
• Team sudah fluent Node — ada learning curve maintenance Bun/Deno
• Hosting dan deploy pipeline sudah setup — overhead migration

Kapan worth migrate existing app ke Bun?

• App CPU-bound genuine (transform data besar, encoding, crypto heavy) — Bun bisa kasih 20-40% gain observable
• Startup time kritis (Lambda cold start menjadi bottleneck measured)
• Team greenfield untuk module baru dalam monorepo

Greenfield project

→ Bun kalau tidak ada native dep yang exotic.

Keuntungan Bun di greenfield:

• TypeScript langsung tanpa setup
• Bun test runner built-in (tidak perlu install Jest/Vitest)
• Bun bundler built-in (tidak perlu Webpack/Rollup/Vite untuk server bundle)
• Speed install package 10-20x npm

# Mulai project Bun
bun init my-app
cd my-app
bun add hono          # atau express, fastify — semuanya compatible
bun run src/index.ts  # langsung jalan
bun test              # test runner built-in

→ Node kalau:

• Team Anda masih uncertain dan tidak mau troubleshoot edge cases
• Perlu native modules yang known problematic (lihat list atas)
• Deploy ke environment yang tidak support Bun (shared hosting, specific enterprise env)

Edge / serverless

→ Deno Deploy untuk edge function.

Deno Deploy excellent untuk:

• Webhook handler ringan (cold start fast, auto-scaling)
• Edge middleware (image resize, A/B test, auth gate)
• Cron job ringan

Kekurangan Deno Deploy:

• Permission model annoying kalau app butuh banyak akses (network, file, env)
• Pricing bisa naik kalau invocation banyak (vs Cloudflare Workers yang jauh lebih murah per request)
• Beberapa npm package tidak compatible

Untuk use case Indonesia edge function sederhana, Cloudflare Workers (pakai V8 isolate, bukan Deno/Node runtime) justru lebih mature dan lebih murah — worth evaluated juga.

Anti-pattern: benchmark-driven migration

Ini pattern yang paling sering saya lihat di komunitas dev Indonesia:

“Bun 2x lebih cepat dari Node! Kita harus migrate!”

Sebelum eksekusi, tanya dulu:

1. Bottleneck sekarang di mana? Kalau response time app 300ms karena query DB 250ms, runtime yang 15ms lebih cepat tidak akan terasa.
2. Apakah Anda sudah profiling? Runtime bukan bottleneck mayoritas web app. DB query, N+1 query, missing index, serialisasi payload besar — itu bottleneck nyata.
3. Berapa cost engineering migrasi? Estimasi testing compatibility, update tooling, update CI/CD pipeline, retraining team. Kalau 1-2 minggu untuk 5% observable gain di production = tidak worth.

Timeline realistic migration Node → Bun untuk medium app (10-20 microservice):
- Audit compatibility semua package: 1-2 hari
- Setup Bun di dev environment: 0.5 hari
- Fix incompatibility (jika ada): 0.5-3 hari
- Update CI/CD pipeline: 1 hari
- Load test + monitoring: 3-5 hari
- Total: 1-2 minggu engineering time

ROI: observable di production? Tergantung workload.

Migration worth it kalau:

• Greenfield — tidak ada legacy overhead
• CPU-bound workload sudah diukur
• Cold start menjadi SLA bottleneck yang measured
• Tim development punya bandwidth dan appetite

Summary per persona

Persona	Rekomendasi
Solo dev, project baru	Bun — DX terbaik, TypeScript native, all-in-one tooling
Team 3-10 dev, app baru	Bun kalau tidak ada native dep aneh, Node kalau tim konservatif
Enterprise, existing app	Node — jangan ganti runtime tanpa bottleneck konkret
Serverless/edge function	Deno Deploy atau Cloudflare Workers
API backend I/O-bound	Node (runtime tidak jadi bottleneck, optimasi DB dulu)
CLI tooling internal	Bun — startup cepat, bundle ke single binary

Verdict

Conditional, bukan “Bun selalu menang” atau “Node masih terbaik.”

Kalau saya mulai project baru hari ini: Bun. TypeScript native, fast, tooling lengkap, npm compatible.

Kalau saya punya production app Node yang sudah jalan: tidak ganti. Kecuali ada bottleneck konkret yang sudah diukur dan bisa dijelaskan ke stakeholder.

Kalau saya butuh edge function ringan: Deno Deploy atau Cloudflare Workers — evaluate per use case dan pricing.

Angka benchmark itu menarik di blog post, tapi production adalah soal reliability, maintainability, dan tim yang bisa troubleshoot pukul 2 pagi. Node 22 LTS masih menang di tiga dimensi itu untuk mayoritas team di Indonesia.