Rust vs. Node.js: Backend-Benchmark und Latenz

Sharkbench ist ein unabhängiges Community-Projekt, das drei Dinge misst: die Fähigkeit eines Frameworks, gleichzeitige HTTP-Anfragen, I/O-Vorgänge und JSON-Serialisierung zu verarbeiten. Der Test läuft unter Docker/Linux auf einem Ryzen 7 7800X3D, mit einem letzten öffentlichen Update am 24. August 2025 (sharkbench.dev/web, abgerufen am 24. August 2026).

Quelle: Sharkbench, 24. August 2025 – Docker/Linux, Ryzen 7 7800X3D.

Axum – das Framework, das Aurabase für seinen Rust-Kern verwendet, verifiziert in Cargo.toml – verarbeitet auf dieser Bank 21.030 Anfragen pro Sekunde. Express, das in der Produktion am häufigsten verwendete Node.js-Framework, verarbeitet 5.766 auf derselben Hardware: ein Faktor von 3,6. Dies ist kein Einzelfall. Die vier getesteten Rust-Frameworks liegen alle in einem engen Bereich von 18.000 bis 22.000 req/s, während die drei getesteten Node.js-Frameworks zwischen 5.766 und 9.340 liegen.

In der Praxis misst „req/s“ den Durchsatz unter anhaltender gleichzeitiger Last – nicht die Geschwindigkeit einer isolierten Anfrage auf einer Website mit geringem Datenverkehr. Bei einem Endpunkt, der alle paar Sekunden aufgerufen wird, ist der Unterschied nie sichtbar. Entscheidend wird es bei einem Hot-Endpunkt – einem Echtzeitfluss, einer öffentlichen API mit starkem Datenverkehr, einem Job, der Tausende von Aufrufen aneinanderreiht –, wo die Anzahl der pro CPU-Kern verarbeiteten Anfragen bei gleicher Hardware direkt die Infrastrukturrechnung bestimmt.

Die durchschnittliche Latenz folgt auf dieser Bank der gleichen Hierarchie: 1,4 bis 1,7 ms für die getesteten Rust-Frameworks, verglichen mit 3,4 bis 5,5 ms für die getesteten Node.js-Frameworks.

Quelle: Sharkbench, 24. August 2025 – mittlere Latenz, nicht p99.

Bei dieser Zahl handelt es sich um einen Durchschnitt, nicht um p99. Garbage-Pausen in einer verwalteten Laufzeit wirken sich hauptsächlich auf die Versandwarteschlange aus – die langsamsten Anforderungen, nicht den Median. Dies ist das Thema eines speziellen Artikels in dieser Reihe: Warum das Fehlen eines Garbage Collectors die p99-Latenz ändert.

Rust verwaltet den Speicher nach Besitz und überprüft ihn zur Kompilierungszeit – kein Garbage Collector läuft im Hintergrund und unterbricht die Ausführung. Das offizielle Rust Book fasst es wie folgt zusammen: „Keine der Eigentumsfunktionen wird Ihr Programm verlangsamen, während es läuft“ (The Rust Programming Language, doc.rust-lang.org, abgerufen am 24. August 2026). Der Speicher wird freigegeben, sobald die Variable, die ihn besitzt, den Gültigkeitsbereich verlässt – ein bekannter Zeitpunkt zur Kompilierungszeit, keine unvorhersehbare Pause zur Laufzeit.

fn main() {
    let data = String::from("réponse API"); // „data“ besitzt die Zeichenfolge
    process(data); // Der Besitz verlässt hier
    // „data“ ist hier nicht mehr gültig – kein baumelnder Zeiger, kein Double Free
} // „Daten“ werden hier deterministisch freigegeben

fn process(s: String) {
    println!("{s}");
} // „s“ geht hier außerhalb des Geltungsbereichs: sofortige Veröffentlichung, ohne Garbage-Collection-Pass

Node.js hingegen läuft auf einem einzelnen JavaScript-Thread und delegiert E/A-Vorgänge über eine mehrphasige Ereignisschleife (Timer, verzögerte Rückrufe, Abfrage, Prüfung ...) an den Kernel – aber jede synchrone Berechnung in diesem Thread, einschließlich eines Garbage-Collection-Durchlaufs von der V8-Engine, blockiert die Ausführung während der Ausführung (offizielle Node.js-Dokumentation, nodejs.org, abgerufen im August 24, 2026). Dies ist ein Unterschied im Speichermodell, kein Implementierungsdetail.

Das kontraintuitivste Ergebnis derselben Bank betrifft nicht Rust: Es betrifft Node.js selbst. Express – ein und derselbe Code, ein und dieselbe API – geht von 5.766 req/s auf Node.js auf 18.917 req/s auf Bun, ein Faktor von ×3,3, ohne eine Zeile Anwendungscode zu ändern (Sharkbench, 24. August 2025).

Quelle: Sharkbench, 24. August 2025 – gleicher Express-Code, drei JavaScript-Laufzeiten.

Auf Deno ist derselbe Express-Code auf 6.088 req/s begrenzt – nahe an Node.js, weit entfernt von Bun. Die JavaScript-Sprache ist in allen drei Fällen identisch; Es ist die Laufzeit – ihre JS-Engine, ihre Event-Loop-Implementierung, ihre Garbage Collection – die das Spiel verändert. Der Vergleich von „Rust“ mit „Node.js“ ohne Angabe von Laufzeit, Version und Framework ist wie ein Vergleich von Konfigurationen, nicht von Sprachen.

Die TechEmpower Framework Benchmarks veranschaulichen die gleiche Idee in größerem Maßstab. Sein Open-Source-Repository wurde am 24. März 2026 aktualisiert und seine letzte Runde (Runde 23) war Gegenstand eines Beitrags vom 16. März 2026 (TechEmpower, abgerufen am 24. August 2026). Dieses Projekt führt viele Arten von Tests für Hunderte von Implementierungen durch, gerade weil ein einzelner Test niemals ein Framework darstellt, geschweige denn eine Sprache.

Convex, ein Akteur auf dem Datenbankmarkt, hat die klarste Position zu diesem Thema formuliert: die Weigerung, sich am Marketing-„Balkendiagrammkrieg“ zwischen konkurrierenden Datenbanken zu beteiligen, der als irreführend erachtet wird. „Es ist Skalierungstheater, nicht Skalierung“, schreibt das Team (Convex, abgerufen am 24. August 2026). Wir teilen diese Lesart: Eine bloße Zahl ohne veröffentlichte Methodik beweist nichts – weder für einen Konkurrenten noch für uns.

Was es konkret ändert: Hardware (CPU, RAM), genaue Version des Frameworks und der Laufzeit, Größe der JSON-Payload, Grad der Konkurrenz und Dauer des Tests – all das beeinflusst das Ranking – manchmal mehr als die Wahl der Sprache selbst. Eine Bank, die diese Parameter nicht veröffentlicht, reproduziert sich nicht und verifiziert sich daher nicht selbst – sehen Sie sich unsere vollständige und reproduzierbare Methodik zum Benchmarking einesBackends an.

Das Kern-Backend von Aurabase ist in Rust geschrieben, auf axum und tokio – überprüft im Cargo.toml des Monorepos: Zehn Dienste (aura-gateway, aura-auth, aura-db…) teilen in der Ausgabe 2021 die gleiche Arbeitsbereichsabhängigkeit axum (0.8) und die gleiche Laufzeit tokio. Das Gateway, das den Datenebenen- und Managementebenenverkehr weiterleitet, basiert zusätzlich zu axum auf hyper – die vollständigen Details finden Sie in unserem Artikel über , die Datenebenen-/Managementebenenarchitektur des Gateways. Die Struktur des Cargo-Arbeitsbereichs, der diese zehn Dienste unterstützt, ist in unserem Artikel über den Cargo-Arbeitsbereichdokumentiert.

Was wir noch nicht haben, ist eine veröffentlichte Aurabase-Durchsatz- oder Latenzzahl mit dokumentierter Methodik und Hardware. Dies ist Absicht: Wir veröffentlichen die Methodik lieber vor der Abbildung und nicht umgekehrt – dies ist das Thema eines zukünftigen Artikels in dieser Reihe.

Den vollständigen Architekturvergleich – einheitlicher Rust-Kern bei Aurabase im Vergleich zum heterogenen Stack Elixir/Go/TypeScript/Node, dokumentiert bei einem direkten Konkurrenten – finden Sie in unserem detaillierten Vergleich Aurabase vs. Supabase. Wenn Sie bereits ein Projekt migrieren, deckt der Migrationsleitfaden Supabase zu Aurabase das Schema, die RLS-Richtlinien und das SDK ab.

Alle in diesem Artikel zitierten Zeilen, veröffentlicht von Sharkbench am 24. August 2025 (Docker/Linux, Ryzen 7 7800X3D).

Zitieren Sie diese Daten: Sharkbench, „Web Framework Benchmarks“, sharkbench.dev/web, zuletzt aktualisiert am 24. August 2025.

Auf der hier zitierten Benchmark laufen die Rust-Frameworks alle in einem engen Bereich – 18.000 bis 22.000 Req/s, 1,4–1,7 ms – weit vor den Node.js-Frameworks auf Node.js selbst (5.766–9.340 Req/s, 3,4–5,5 ms). Aber die Laufzeit verändert die Situation ebenso wie die Sprache: Express auf Bun holt Axum auf Rust fast ein.

Wenn Sie ein Backend allein anhand der reinen Leistung bewerten, müssen Sie die Methodik vor der Zahl angeben: Hardware, Version, Nutzlastgröße, Wettbewerbsgrad. Aurabase hat noch keine eigenen Zahlen veröffentlicht; Wenn dies der Fall ist, wird die Methodik an erster Stelle stehen.