Rust versus Node.js: backend-benchmark en latentie

Sharkbench is een onafhankelijk gemeenschapsproject dat drie dingen meet: het vermogen van een raamwerk om gelijktijdige HTTP-verzoeken af te handelen, I/O-bewerkingen en JSON-serialisatie. De test draait onder Docker/Linux op een Ryzen 7 7800X3D, met een laatste openbare update op 24 augustus 2025 (sharkbench.dev/web, geraadpleegd op 24 augustus 2026).

Bron: Sharkbench, 24 augustus 2025 — Docker/Linux, Ryzen 7 7800X3D.

Axum – het raamwerk dat Aurabase gebruikt voor zijn Rust-kern, geverifieerd in Cargo.toml – verwerkt 21.030 verzoeken per seconde op deze bank. Express, het Node.js-framework dat het meest wordt gebruikt in de productie, verwerkt 5.766 op dezelfde hardware: een factor 3,6. Dit is geen alleenstaand geval. De vier geteste Rust-frameworks vallen allemaal binnen een smal bereik van 18.000 tot 22.000 req/s, terwijl de drie geteste Node.js-frameworks tussen de 5.766 en 9.340 liggen.

In de praktijk meet ‘req/s’ de doorvoer onder aanhoudende gelijktijdige belasting – niet de snelheid van een geïsoleerd verzoek op een site met weinig verkeer. Voor een eindpunt dat elke paar seconden wordt aangeroepen, is het verschil nooit zichtbaar. Het wordt beslissend op een hot endpoint – een real-time flow, een openbare API met veel verkeer, een taak die duizenden oproepen aan elkaar rijgt – waar het aantal verwerkte verzoeken per CPU-kern, voor gelijke hardware, direct de infrastructuurrekening bepaalt.

De gemiddelde latentie volgt dezelfde hiërarchie op deze bank: 1,4 tot 1,7 ms voor de geteste Rust-frameworks, vergeleken met 3,4 tot 5,5 ms voor de geteste Node.js-frameworks.

Bron: Sharkbench, 24 augustus 2025 — gemiddelde latentie, niet p99.

Dit cijfer is een gemiddelde, geen p99. Garbage-pauzes in een beheerde runtime hebben vooral invloed op de verzendwachtrij: de langzaamste verzoeken, niet de mediaan. Dit is het onderwerp van een speciaal artikel in deze serie: waarom de afwezigheid van een garbage collector de p99-latentie verandert.

Rust beheert het geheugen op basis van eigendom, gecontroleerd tijdens het compileren - er draait geen garbage collector op de achtergrond en onderbreekt de uitvoering. Het officiële Rust Book vat het als volgt samen: “Geen van de eigendomskenmerken zal je programma vertragen terwijl het draait” (De Rust-programmeertaal, doc.rust-lang.org, geraadpleegd op 24 augustus 2026). Geheugen wordt vrijgegeven zodra de variabele die er eigenaar van is, buiten bereik raakt: een bekend tijdstip tijdens het compileren, niet een onvoorspelbare pauze tijdens runtime.

fn main() {
    let data = String::from("réponse API"); // `data` is eigenaar van de string
    process(data); // bezit vertrekt hier
    // 'data' is hier niet langer geldig - geen bungelende aanwijzer, geen dubbele gratis
} // 'gegevens' worden hier deterministisch vrijgegeven

fn process(s: String) {
    println!("{s}");
} // `s` valt hier buiten het bereik: onmiddellijke vrijgave, zonder afvalinzamelingspas

Node.js daarentegen draait op een enkele JavaScript-thread en delegeert I/O-bewerkingen naar de kernel via een meerfasige gebeurtenislus (timers, uitgestelde callbacks, poll, check...) - maar elke synchrone berekening op die thread, inclusief een garbage collection pass van de V8-engine, blokkeert de uitvoering terwijl deze draait (officiële Node.js-documentatie, nodejs.org, geraadpleegd in augustus 24, 2026). Dit is een verschil in het geheugenmodel, geen implementatiedetail.

Het meest contra-intuïtieve resultaat van dezelfde bank heeft geen betrekking op Rust: het betreft Node.js zelf. Express – één en dezelfde code, één en dezelfde API – gaat van 5.766 req/s op Node.js naar 18.917 req/s op Bun, een factor ×3,3, zonder ook maar één regel applicatiecode te veranderen (Sharkbench, 24 augustus 2025).

Bron: Sharkbench, 24 augustus 2025 – dezelfde Express-code, drie JavaScript-runtimes.

Op Deno bereikt dezelfde Express-code een maximum van 6.088 req/s – dichtbij Node.js, ver van Bun. De JavaScript-taal is in alle drie de gevallen identiek; Het is de runtime (de JS-engine, de implementatie van de eventloop, de garbagecollection) die het spel verandert. Het vergelijken van “Rust” met “Node.js” zonder de runtime, versie en framework te specificeren is als het vergelijken van configuraties, niet van talen.

TechEmpower Framework Benchmarks illustreert hetzelfde idee op grotere schaal. De open source repository werd op 24 maart 2026 bijgewerkt en de meest recente ronde (ronde 23) was het onderwerp van een bericht gedateerd 16 maart 2026 (TechEmpower, geraadpleegd op 24 augustus 2026). Dit project voert vele soorten tests uit op honderden implementaties, juist omdat een enkele test nooit een raamwerk vertegenwoordigt, laat staan ​​een taal.

Convex, een speler op de databasemarkt, heeft het duidelijkste standpunt over dit onderwerp geformuleerd: weigeren deel te nemen aan de marketing “staafdiagramoorlog” tussen concurrerende databases, die als misleidend wordt beschouwd. “Het is theater opschalen, niet schalen”, schrijft het team (Convex, geraadpleegd op 24 augustus 2026). Wij delen deze lezing: een naakt cijfer, zonder gepubliceerde methodologie, bewijst niets – noch voor een concurrent, noch voor ons.

Wat het concreet verandert: hardware (CPU, RAM), exacte versie van het raamwerk en runtime, grootte van de JSON-payload, concurrentieniveau en duur van de test variëren allemaal in de rangorde – soms meer dan de taalkeuze zelf. Een bench die deze parameters niet publiceert, reproduceert zichzelf niet en verifieert zichzelf daarom niet. Zie onze complete en reproduceerbare methodologie voor het benchmarken van eenbackend.

De kern-backend van Aurabase is geschreven in Rust, op axum en tokio – gecontroleerd in de Cargo.toml van de monorepo: tien services (aura-gateway, aura-auth, aura-db…) delen dezelfde werkruimteafhankelijkheid axum (0.8) en dezelfde runtime tokio, in de editie van 2021. De gateway die het verkeer op het datavlak en het beheervlak routeert, is afhankelijk van hyper naast axum. De volledige details staan ​​in ons artikel over , de architectuur van het datavlak/beheervlak van de gateway. De structuur van de Cargo-werkruimte die deze tien services ondersteunt, is gedocumenteerd in ons artikel over de Cargo-werkruimte.

Wat we nog niet hebben, is een gepubliceerd Aurabase-doorvoer- of latentiecijfer met gedocumenteerde methodologie en hardware. Dit is opzettelijk: we publiceren de methodologie liever vóór de figuur dan andersom – dit is het onderwerp van een toekomstig artikel in deze serie.

Voor de volledige architectuurvergelijking – verenigde Rust-kern bij Aurabase versus heterogene stack Elixir/Go/TypeScript/Node gedocumenteerd bij een directe concurrent – zie onze gedetailleerde vergelijking Aurabase versus Supabase. Als u al een project migreert, behandelt de Supabase naar Aurabase migratiegids het schema, het RLS-beleid en de SDK.

Alle regels die in dit artikel worden geciteerd, zoals gepubliceerd door Sharkbench op 24 augustus 2025 (Docker/Linux, Ryzen 7 7800X3D).

Citeer deze gegevens: Sharkbench, “Web Framework Benchmarks,” sharkbench.dev/web, voor het laatst bijgewerkt op 24 augustus 2025.

Op de hier aangehaalde bank draaien de Rust-frameworks allemaal binnen een smal bereik – 18.000 tot 22.000 req/s, 1,4-1,7 ms – ver vóór de Node.js-frameworks op Node.js zelf (5.766-9.340 req/s, 3,4-5,5 ms). Maar de looptijd verandert net zo veel de situatie als de taal: Express on Bun haalt Axum on Rust bijna in.

Als u een backend alleen op basis van de ruwe prestaties evalueert, moet u de methodologie vóór het getal laten gaan: hardware, versie, payload-grootte, concurrentieniveau. Aurabase heeft nog geen eigen cijfers vrijgegeven; als dat het geval is, komt de methodologie op de eerste plaats.