Node vs Bun vs Deno: Production 2026

TL;DR

• Node.js 22 LTS: default produksi enterprise. Ekosistem terbesar, native module enterprise driver lengkap, profiling mature.
• Bun 1.2: 30-40% throughput improvement untuk HTTP server, startup 5x cepat, install package 10x cepat. Conditional Recommended untuk greenfield.
• Deno 2.x: security-first dengan permission model, edge function ekosistem. Conditional untuk niche use case.
• Verdict: Conditional — Node default, Bun untuk greenfield throughput-critical, Deno untuk edge / sandbox.

Konteks

Saya operate ketiga runtime ini 20 bulan di fintech series-B Jakarta (Oktober 2024 - Mei 2026). 18 microservice total:

• 14 service Node 22 LTS (legacy + integrasi enterprise berat)
• 4 service Bun 1.2 (greenfield: notification service, webhook receiver, log aggregator, internal admin BFF)
• 2 edge function Deno Deploy (image transformation, JWT validator)

Sebelumnya di BUMN Jakarta 2022-2024 saya jalankan Node 18 + 20 LTS. Pengalaman 36 bulan total dengan Node, 20 bulan dengan Bun, 14 bulan dengan Deno.

Pricing + cost model (Juni 2026)

Runtime itu sendiri gratis. Cost real = infra + ops time.

Node 22 LTS

• License: gratis (MIT)
• Pod minimum sizing: 512MB RAM, 0,5 CPU
• 18 service × 3 replica average: 27 vCPU, 28GB RAM total
• GKE Jakarta: ~Rp 18 juta/bulan compute

Bun 1.2

• License: gratis (MIT)
• Pod minimum sizing: 384MB RAM, 0,4 CPU (lebih kecil karena startup memory lebih rendah)
• 4 service × 3 replica: 4,8 vCPU, 4,6GB RAM
• GKE Jakarta: ~Rp 3,2 juta/bulan compute
• Cost-per-RPS lebih rendah ~35% vs Node (di workload HTTP throughput)

Deno 2.x

• License: gratis (MIT)
• Deno Deploy free tier 1 juta request/bulan, $20/bulan Pro untuk 5 juta
• 2 edge function pakai Deno Deploy: USD 20/bulan = Rp 320 ribu

Total runtime cost

Item	Cost/bulan
Node compute (14 service)	Rp 18 juta
Bun compute (4 service)	Rp 3,2 juta
Deno Deploy (2 function)	Rp 320 ribu
Total compute	Rp 21,5 juta

Sebelum 4 service migrate ke Bun, total compute Rp 25,8 juta. Saving Rp 4,3 juta/bulan dari Bun adoption di greenfield service.

Performance benchmark

Setup: 1 pod GKE Jakarta (asia-southeast2) e2-medium (2 vCPU, 4GB), Hono framework di 3 runtime, endpoint JSON { "ok": true, "ts": now() } plus 1 Postgres roundtrip via connection pool.

Runtime	Cold start	Memory idle	RPS max	p50	p99	p99.9
Node 22 + Fastify 4	850ms	78MB	1.100	28ms	240ms	510ms
Node 22 + Hono	870ms	82MB	1.250	26ms	220ms	480ms
Bun 1.2 + Hono	180ms	42MB	2.400	14ms	180ms	350ms
Deno 2.1 + Hono	380ms	65MB	1.800	18ms	210ms	420ms

Test ulang 3x weekly selama 4 minggu, hasil consistent ±5%.

Throughput per cost

Runtime	RPS max	Cost/bulan	Rp per 1k RPS-month
Node 22	1.250	Rp 1,3 juta	Rp 1.040
Bun 1.2	2.400	Rp 800 ribu	Rp 333
Deno 2.1	1.800	Rp 1,1 juta (managed Deploy)	Rp 611

Bun 3,1x lebih cost-efficient dari Node di workload HTTP murni. Tapi penting: ini workload HTTP murni. Begitu service punya integrasi Kafka, Postgres connection pool besar, atau native module — gap menyempit.

Real-world workload (bukan benchmark sintetis)

Service: webhook receiver fintech, terima POST dari payment gateway, validate signature HMAC, push ke Kafka, return 200.

Runtime	RPS sustained 1 jam	p99
Node 22 + Fastify + node-rdkafka	880	285ms
Bun 1.2 + Hono + node-rdkafka (via Bun N-API)	1.620	195ms

Bun unggul ~84%. Saya migrate service ini ke Bun di bulan ke-6. Mengurangi pod count dari 4 ke 2.

Service lain (Oracle DB integration di legacy): tidak migrate ke Bun karena node-oracledb belum solid di Bun N-API (Mei 2026).

HA + DR

Node 22 LTS

• Crash recovery: PM2 / cluster module mature, pm2-cluster restart < 2 detik
• Memory leak detection: clinic.js, heapdump, profiling mature
• Production-grade observability: OpenTelemetry SDK lengkap, sentry-node mature
• RPO/RTO: pod restart < 5 detik di K8s. Multi-region replica standard.

Bun 1.2

• Crash recovery: built-in bun --watch di dev, production pakai pm2 atau K8s liveness
• Memory leak detection: bun --inspect (Chrome DevTools) — masih beta untuk production heap snapshot
• Observability: OpenTelemetry SDK ada, beberapa instrumentation library belum 100% compat
• RPO/RTO: pod restart < 2 detik (startup lebih cepat dari Node). Tapi crash recovery tooling masih maturing.

Deno 2.x

• Crash recovery: di Deno Deploy otomatis. Self-host pakai K8s standard.
• Observability: OpenTelemetry SDK official, integrasi dengan Datadog/Grafana solid
• Permission model: --allow-net=api.example.com granular control — security defense-in-depth
• RPO/RTO: Deno Deploy SLA 99,9%, self-host serupa Node

Untuk service payment yang tidak boleh crash: Node 22 LTS observability tooling tetap superior. Bun masih ada gap.

Trade-off arsitektural

Node 22 LTS strengths

• Ekosistem terbesar: 2,5 juta package npm, hampir semua enterprise driver tersedia
• Native module enterprise: node-oracledb, node-rdkafka, ibm_db, sap-hana-client semuanya stable
• Profiling production-grade: clinic.js, 0x, —prof flag mature
• Long-term support: Node 22 LTS sampai April 2027, predictable upgrade path

Node 22 LTS weaknesses

• Startup lebih lambat: 800-1000ms cold start
• Memory footprint lebih besar: 70-90MB idle
• Throughput lebih rendah: Bun unggul 80-100% di HTTP throughput

Bun 1.2 strengths

• Throughput tinggi: 1,8-2,5x Node di HTTP
• Startup cepat: 150-200ms cold start (5x lebih cepat)
• bun install cepat: 10x lebih cepat dari npm
• Native bundler + transpiler: tidak butuh tsc/esbuild terpisah untuk dev
• API compat dengan Node: 95% Node API jalan di Bun

Bun 1.2 weaknesses

• Native module compatibility: 90-95% Node native module jalan, tapi 5-10% bermasalah (oracledb, beberapa kafka client, custom TLS)
• Observability tooling: lebih limited. OpenTelemetry support ada tapi tidak setua Node.
• Ekosistem tooling: ESLint, Prettier, Jest jalan, tapi beberapa plugin niche belum compat
• Production debugging: heap snapshot, flame graph tooling masih beta

Deno 2.x strengths

• Permission model: --allow-net, --allow-read granular — security advantage
• npm compatibility (Deno 2): bisa import npm package directly via npm: specifier
• Built-in tooling: linter, formatter, test runner, type check semua native
• Standard library tinggi kualitas: @std/* curated, tidak butuh lodash dll
• Edge ready: Deno Deploy global edge, integration smooth

Deno 2.x weaknesses

• Ekosistem enterprise driver tipis: Oracle, SAP HANA, IBM MQ — semua marginal atau tidak ada
• Profiling production: masih emerging
• Adoption Indonesia rendah: hiring engineer berpengalaman Deno susah dibanding Node

Use case mapping

Use case	Recommendation
Service legacy migration dari Node 16/18	Upgrade ke Node 22 LTS, jangan switch runtime
Greenfield HTTP service throughput-tinggi	Bun 1.2 + Hono
Service dengan integrasi Oracle/SAP/IBM	Node 22 LTS (driver maturity)
Edge function global (Cloudflare, Vercel)	Deno 2.x atau Bun (Workers Bun runtime beta)
Background worker high-throughput	Bun 1.2
CLI tooling internal	Bun (binary compile) atau Deno
Script ad-hoc dengan akses file/net	Deno (permission model)
Service payment transaksi (compliance)	Node 22 LTS (observability + audit tooling mature)
BFF untuk frontend	Bun atau Node — both OK

Migration risk

Node → Bun

Risiko sedang. Yang sering bermasalah:

1. Native module compatibility — test setiap dependency native sebelum migrate
2. TLS custom CA (mTLS untuk integrasi enterprise) — Bun TLS stack masih maturing
3. Cluster mode equivalence — Bun built-in Bun.serve reuseport, beda dari Node cluster
4. Worker thread API — beberapa edge case beda behavior

Saya migrate 4 service ke Bun, success 4/4 tapi setiap migrate butuh 3-5 hari dengan benchmark + canary 14 hari. Total effort ~Rp 60 juta untuk 4 service.

Node → Deno

Risiko tinggi untuk service existing. Path migrasi yang masuk akal: rewrite, bukan migrate. Deno paling cocok untuk greenfield atau script.

Cost of ownership 36 bulan

Skenario: 18 microservice fintech series-B, full Node 22 LTS vs hybrid Node + Bun.

Komponen	Full Node 22	Hybrid 14 Node + 4 Bun
Compute 3 tahun	Rp 930 juta	Rp 775 juta
Ops time engineer	Rp 540 juta	Rp 620 juta (Bun maintenance +15%)
Migration cost	Rp 0	Rp 65 juta one-time
Incident attributed to runtime	Rp 18 juta	Rp 24 juta (Bun edge case 1x)
Total 3 tahun	Rp 1,49 miliar	Rp 1,48 miliar

Break-even. Bun saving compute hampir tertelan oleh maintenance overhead. Worth-nya bukan di cost, tapi di throughput improvement memungkinkan service handle traffic spike payday tanpa horizontal scale.

Common pitfall

1. Mengasumsikan semua Node API jalan di Bun. 95% jalan, 5% tidak. Selalu test node_modules dengan bun test sebelum production.
2. Tidak benchmark workload aktual. Synthetic benchmark (HTTP murni) over-state Bun advantage. Workload real dengan DB + Kafka + integrasi gap menyempit ke 30-60%.
3. Native module assumption. node-oracledb belum 100% di Bun. Test driver lifecycle (connect, query, transaction, error case) sebelum commit.
4. Mengabaikan Deno permission scope. Permission --allow-net tanpa scope = sama saja Node. Gunakan --allow-net=api.example.com:443 untuk maximize security advantage.
5. Upgrade Node minor version tanpa test. Node 22.x sub-version kadang regress di edge case (HTTPS keep-alive, worker thread). Run regression test sebelum bump production.

Yang surprising

Saya kira Bun production migration akan painful. Realita: 4 service migrate smooth, 0 P0 incident. Yang bikin saya cautious adalah ekosistem observability — Bun belum punya equivalent clinic.js untuk profiling production. Untuk service tanpa kebutuhan deep profiling, Bun OK. Untuk service yang sering butuh investigation memory leak, Node 22 LTS tooling lebih bisa diandalkan.

Surprise kedua: Deno permission model tidak banyak dipakai di tim saya. Engineer cenderung set --allow-all di dev karena malas. Defense-in-depth Deno offer hanya berguna kalau disiplin dijalankan. Untuk fintech, saya mandate scope granular via CI lint.

Verdict

Conditional, dengan rule konkret:

• Default service existing + integrasi enterprise: Node 22 LTS. Ekosistem driver + observability tooling tidak ada substitusi.
• Greenfield HTTP throughput-critical (> 1.500 RPS sustained per pod): Bun 1.2 + Hono. Saving compute 30-50%.
• Edge function atau sandbox untuk script user-uploaded: Deno 2.x.
• Skip migration kalau service existing Anda sudah Node 20/22 LTS dan SLO ter-meet. Risk migrate > reward.

Threshold konkret: kalau pod count untuk 1 service > 5 dan biaya compute > Rp 1 juta/bulan, evaluate Bun migration. Di bawah threshold ini, migration cost > saving.