Gerçek bir uygulamada hayır. Tek CPU çekirdeğinde boş bir HTTP testinde Bun 1.3.14 saniyede 122.170 istek, Node.js 24.18 ise 47.734 istek sundu; yaklaşık 2,6 kat. Ama yönlendirme, doğrulama ve veritabanı olan bir servis Bun'da, Node.js'te ve Deno'da aynı 12.000 istek/saniyeyi verdi, çünkü hızı veritabanı belirledi. "3 kat hızlı" bir benchmark sonucu. Sizin siteniz için verilmiş bir söz değil.
Hızlı rakamlar aslında neyi ölçüyor
Temmuz 2026'da yayınlanan bir benchmark, sabitlenmiş sürümlerle (Node 24.18.0, Bun 1.3.14, Deno 2.9.1) 12 çekirdekli bir Linux masaüstünde koştu. Mutlak sayılar o makineye bağlı; oranlara bakın:
- Boş JSON endpoint'i, tek çekirdek: Bun saniyede 122.170 istek, Node.js 47.734. Deno 2.9.1 133.093 ile öndeydi.
- Hello-world betiğinin soğuk başlangıcı: Bun 11 ms, Node.js 21 ms.
- 3,3 MB'lık veride
JSON.stringify: Bun 5,5 ms, Node.js 13,6 ms. - Soğuk önbellekle 585 paket kurulumu:
bun install5,8 saniye, npm 11,8 saniye. - Boştaki bellek: Bun 36 MB, Node.js 49 MB.
BullMQ, Bun 1.3.3 ve Node.js 24.13 ile kendi kuyruk benchmark'ını koştu. CPU'ya dayalı iş Bun'da %33 hızlıydı. Redis'i bekleyen iş işleme ise yalnızca %12 hızlıydı. Bir iş süreç dışında bir şeyi ne kadar çok bekliyorsa, runtime o kadar az önemli.
Fark nerede kayboluyor
Yönlendirme, doğrulama ve veritabanı içeren bir URL kısaltıcı üzerinde bağımsız bir test, üç runtime'da da saniyede 12.000 istek verdi. Aynı yazar ikinci bir sorun buldu: yaygın yük aracı autocannon kendisi Node.js ile yazılmış ve 12 çekirdekli makinede saniyede yaklaşık 65.000 istekte tavana vuruyor. Onunla yapılan hiçbir karşılaştırma iki hızlı runtime'ı birbirinden ayıramaz; "Bun hep birinci" diyen yazıların çoğu böyle ölçülmüş.
Strapi'nin özetlediği, 2025'te hakemli dergide yayımlanan bir çalışma, G/Ç'ye dayalı HTTP'de Bun için saniyede 27.500, Node.js için 28.200 istek buldu. Aynı yazıda anılan bir Bun GitHub incelemesi, çok nesne üreten bir iş yükünde Bun'un Node.js'in gerisinde kaldığını ölçtü (11.800'e karşı 16.200); sonra bir düzeltme farkı daralttı. Sıcak yolda çok sayıda kısa ömürlü nesne üretiliyorsa Bun kaybedebilir.
Bun ne zaman değer
- Servis, istek başına çok JSON ya da başka CPU işi yapıyor.
- Açılış süresi önemli: kısa ömürlü işler ya da sıfıra ölçeklenen konteynerler.
- CI'nız
npm installiçin dakikalar harcıyor.bun installkullanıp Node.js'te çalışmaya devam edebilirsiniz. - Ek paket olmadan yerleşik test koşturucu ve paketleyici istiyorsunuz.
Node.js ne zaman daha güvenli
- Native eklentilere ya da önce Node.js'i destekleyen bir izleme aracısına bağımlısınız.
- Sıcak yolunuz çok nesne üretiyor ya da uygulamanız framework ağırlıklı; raporlarda Bun'un daha çok bellek kullandığı görülüyor.
- Her hosting rehberinin ve işe alım havuzunun varsaydığı uzun süreli destek sürümünü istiyorsunuz.
Kendi iş yükünüzde 20 dakikada deneyin
- Gerçek uygulamayı gerçek veritabanıyla, dizüstünde değil, yayına alacağınız makinede çalıştırın.
- Node.js ile yazılmamış bir yük aracı kullanın, örneğin
oha:oha -z 15s -c 200 http://127.0.0.1:3000/gercek-rota. - Her runtime'ı üç kez koşturup medyanı alın. Saniyedeki istekle birlikte belleğe de bakın.
- Yalnızca veritabanı devredeyken fark kalıyorsa geçin.
Runtime'ı kendiniz, kök erişiminiz olan bir bulut sunucuda seçersiniz. Cloud VPS Mini (1 vCPU, 1 GB RAM, ayda 14,99 €'dan) deneme API'si için yeter. 1 GB RAM ile karar vermeden önce bellek sütununa bakın.
Sorular
Sıradan bir web sitesi için Bun, Node.js'ten hızlı mı?
Fark edilecek kadar değil. Her istek bir veritabanını ya da dış API'yi bekliyorsa, runtime yanıt süresinin küçük bir parçası.
Bun'u yalnızca paket yöneticisi olarak kullanabilir miyim?
Evet. bun install, Node.js'te çalışmaya devam eden bir projede de çalışır ve hız kazancının açık ve düşük riskli olduğu tek yer kurulumlar.
Eski yazılar neden daha büyük fark gösteriyor?
Çoğu eski Node.js sürümleriyle kıyasladı, tavana vuran bir yük aracı kullandı ya da boş endpoint'i test etti. Runtime benchmark'ları hızlı eskir; bu yazı dahil, her yazının sürümlerine bakın.
