In einer echten Anwendung nicht. Im reinen HTTP-Test auf einem CPU-Kern lieferte Bun 1.3.14 122.170 Anfragen pro Sekunde und Node.js 24.18 nur 47.734, also etwa das 2,6-Fache. Ein Dienst mit Routing, Validierung und Datenbank kam dagegen auf Bun, Node.js und Deno auf dieselben 12.000 Anfragen pro Sekunde, weil die Datenbank das Tempo bestimmte. „3-mal schneller" ist ein Benchmark-Ergebnis, kein Versprechen für Ihre Seite.
Was die schnellen Zahlen tatsächlich messen
Ein im Juli 2026 veröffentlichter Benchmark lief mit festen Versionen (Node 24.18.0, Bun 1.3.14, Deno 2.9.1) auf einem Linux-Desktop mit 12 Kernen. Die absoluten Werte hängen von dieser Maschine ab, achten Sie also auf die Verhältnisse:
- Leerer JSON-Endpunkt, ein Kern: Bun 122.170 Anfragen pro Sekunde, Node.js 47.734. Deno 2.9.1 lag mit 133.093 vorn.
- Kaltstart eines Hello-World-Skripts: Bun 11 ms, Node.js 21 ms.
JSON.stringifybei 3,3 MB: Bun 5,5 ms, Node.js 13,6 ms.- 585 Pakete bei kaltem Cache installieren:
bun install5,8 Sekunden, npm 11,8 Sekunden. - Speicher im Leerlauf: Bun 36 MB, Node.js 49 MB.
BullMQ ließ einen eigenen Queue-Benchmark auf Bun 1.3.3 und Node.js 24.13 laufen. CPU-lastige Arbeit war auf Bun 33 % schneller. Die Jobverarbeitung, die auf Redis wartet, nur 12 %. Je mehr eine Aufgabe auf etwas außerhalb des Prozesses wartet, desto weniger zählt die Runtime.
Wo der Abstand verschwindet
Ein unabhängiger Test mit einem URL-Kürzer samt Routing, Validierung und Datenbank ergab auf allen drei Runtimes 12.000 Anfragen pro Sekunde. Derselbe Autor fand ein zweites Problem: Das verbreitete Lasttest-Werkzeug autocannon ist selbst in Node.js geschrieben und stößt auf einer 12-Kern-Maschine bei rund 65.000 Anfragen pro Sekunde an. Jeder Vergleich damit kann zwei schnelle Runtimes nicht trennen, und viele Artikel mit „Bun ist immer vorn" wurden so gemessen.
Eine begutachtete Studie von 2025 zu I/O-lastigem HTTP ermittelte laut Strapi 27.500 Anfragen pro Sekunde für Bun und 28.200 für Node.js. Eine dort ebenfalls erwähnte Untersuchung im Bun-GitHub-Projekt maß Bun bei einer allokationslastigen Last hinter Node.js (11.800 gegen 16.200), bis eine Korrektur den Abstand verkleinerte. Bun kann verlieren, wenn der heiße Pfad viele kurzlebige Objekte erzeugt.
Wann sich Bun lohnt
- Der Dienst erledigt pro Anfrage viel JSON- oder andere CPU-Arbeit.
- Die Startzeit zählt, etwa bei kurzlebigen Jobs oder Containern, die auf null skalieren.
- Ihre CI verbringt Minuten mit
npm install. Sie könnenbun installnutzen und weiter mit Node.js laufen. - Sie wollen Testrunner und Bundler eingebaut, ohne zusätzliche Pakete.
Wann Node.js die sicherere Wahl ist
- Sie hängen von nativen Erweiterungen oder einem Monitoring-Agenten ab, der zuerst Node.js unterstützt.
- Ihr heißer Pfad erzeugt viele Objekte oder Ihre Anwendung ist framework-lastig; Berichte zeigen dort höheren Speicherbedarf bei Bun.
- Sie wollen die Release mit Langzeitunterstützung, von der jede Hosting-Anleitung und jeder Bewerbermarkt ausgeht.
In 20 Minuten mit Ihrer eigenen Last testen
- Starten Sie die echte Anwendung mit der echten Datenbank auf der Maschine, auf der sie später läuft, nicht auf dem Laptop.
- Nutzen Sie ein Lasttest-Werkzeug, das nicht in Node.js geschrieben ist, etwa
oha:oha -z 15s -c 200 http://127.0.0.1:3000/echte-route. - Lassen Sie jede Runtime dreimal laufen und nehmen Sie den Median. Beobachten Sie neben den Anfragen pro Sekunde auch den Speicher.
- Wechseln Sie nur, wenn der Unterschied mit der Datenbank im Spiel bleibt.
Die Runtime wählen Sie selbst auf einem Cloud-Server, wo Sie Root-Zugriff haben. Ein Cloud VPS Mini (1 vCPU, 1 GB RAM, ab 14,99 € im Monat) reicht für eine Test-API. Bei 1 GB RAM sehen Sie vor der Entscheidung auf die Speicherspalte.
Fragen
Ist Bun für eine normale Website schneller als Node.js?
Meist nicht spürbar. Wartet jede Anfrage auf eine Datenbank oder eine externe API, ist die Runtime nur ein kleiner Teil der Antwortzeit.
Kann ich Bun nur als Paketmanager nutzen?
Ja. bun install funktioniert auch in einem Projekt, das weiter auf Node.js läuft, und Installationen sind die Stelle, an der der Gewinn klar und das Risiko gering ist.
Warum zeigen ältere Artikel einen größeren Abstand?
Viele verglichen alte Node.js-Versionen, nutzten ein Lasttest-Werkzeug mit Obergrenze oder testeten einen leeren Endpunkt. Runtime-Benchmarks veralten schnell, prüfen Sie also bei jedem Artikel die Versionen, auch bei diesem.
