Rust vs Node.js: benchmark backend e latenza

Sharkbench è un progetto di comunità indipendente che misura tre cose: la capacità di un framework di gestire richieste HTTP simultanee, operazioni di I/O e serializzazione JSON. Il test viene eseguito sotto Docker/Linux su un Ryzen 7 7800X3D, con un ultimo aggiornamento pubblico il 24 agosto 2025 (sharkbench.dev/web, accesso il 24 agosto 2026).

Fonte: Sharkbench, 24 agosto 2025 - Docker/Linux, Ryzen 7 7800X3D.

Axum, il framework utilizzato da Aurabase per il suo core Rust, verificato in Cargo.toml, elabora 21.030 richieste al secondo su questo banco. Express, il framework Node.js più utilizzato in produzione, ne elabora 5.766 sullo stesso hardware: un fattore 3,6. Questo non è un caso isolato. I quattro framework Rust testati rientrano tutti in un intervallo ristretto compreso tra 18.000 e 22.000 req/s, mentre i tre framework Node.js testati raggiungono un limite compreso tra 5.766 e 9.340.

In pratica, “req/s” misura il throughput in condizioni di carico simultaneo sostenuto, non la velocità di una richiesta isolata su un sito a basso traffico. Per un endpoint chiamato una volta ogni pochi secondi, la differenza non viene mai vista. Diventa decisivo su un endpoint caldo – un flusso in tempo reale, un’API pubblica con traffico intenso, un lavoro che mette insieme migliaia di chiamate – dove il numero di richieste elaborate per core della CPU, a parità di hardware, determina direttamente il conto dell’infrastruttura.

La latenza media segue la stessa gerarchia su questo banco: da 1,4 a 1,7 ms per i framework Rust testati, rispetto a 3,4 - 5,5 ms per i framework Node.js testati.

Fonte: Sharkbench, 24 agosto 2025 — latenza media, non p99.

Questa cifra è una media, non un p99. Le pause inutili in un runtime gestito influiscono principalmente sulla coda di invio: le richieste più lente, non la mediana. Questo è l'argomento di un articolo dedicato in questa serie: perché l'assenza del garbage collector modifica la latenza p99.

Rust gestisce la memoria in base alla proprietà, controllata in fase di compilazione: nessun garbage collector in esecuzione in background che interrompe l'esecuzione. Il Rust Book ufficiale lo riassume come segue: "Nessuna delle funzionalità di proprietà rallenterà il tuo programma mentre è in esecuzione" (The Rust Programming Language, doc.rust-lang.org, accesso il 24 agosto 2026). La memoria viene liberata non appena la variabile che la possiede esce dall'ambito: un momento noto in fase di compilazione, non una pausa imprevedibile in fase di esecuzione.

fn main() {
    let data = String::from("réponse API"); // "data" possiede la stringa
    process(data); // il possesso se ne va da qui
    // "data" non è più valido qui: nessun puntatore penzolante, nessuna doppia libertà
} // I "dati" vengono rilasciati qui, in modo deterministico

fn process(s: String) {
    println!("{s}");
} // `s` esce dall'ambito qui: rilascio immediato, senza passaggio per la raccolta dei rifiuti

Node.js, al contrario, viene eseguito su un singolo thread JavaScript e delega le operazioni di I/O al kernel tramite un loop di eventi multifase (timer, callback differiti, poll, controllo...) - ma qualsiasi calcolo sincrono su quel thread, incluso un passaggio di garbage collection dal motore V8, blocca l'esecuzione durante l'esecuzione (documentazione ufficiale di Node.js, nodejs.org, accesso il 24 agosto 2026). Si tratta di una differenza nel modello di memoria, non di un dettaglio di implementazione.

Il risultato più controintuitivo della stessa analisi non riguarda Rust: riguarda lo stesso Node.js. Express - lo stesso codice, la stessa API - passa da 5.766 req/s su Node.js a 18.917 req/s su Bun, un fattore pari a ×3,3, senza modificare una riga di codice dell'applicazione (Sharkbench, 24 agosto 2025).

Fonte: Sharkbench, 24 agosto 2025: stesso codice Express, tre runtime JavaScript.

Su Deno, questo stesso codice Express ha un limite di 6.088 req/s, vicino a Node.js, lontano da Bun. Il linguaggio JavaScript è identico in tutti e tre i casi; È il runtime – il suo motore JS, l’implementazione del loop di eventi, la sua garbage collection – che cambia il gioco. Confrontare "Rust" con "Node.js" senza specificare runtime, versione e framework è come confrontare configurazioni, non lingue.

TechEmpower Framework Benchmarks illustra la stessa idea su scala più ampia. Il suo repository open source è stato aggiornato il 24 marzo 2026 e il suo round più recente (round 23) è stato oggetto di un post datato 16 marzo 2026 (TechEmpower, accesso il 24 agosto 2026). Questo progetto esegue molti tipi di test su centinaia di implementazioni, proprio perché un singolo test non rappresenta mai un framework, tanto meno un linguaggio.

Convex, attore nel mercato dei database, ha formulato la posizione più chiara sull'argomento: rifiutandosi di partecipare alla “guerra dei grafici a barre” di marketing tra database concorrenti, ritenuta fuorviante. "È un teatro in scala, non in scala", scrive il team (Convex, accesso il 24 agosto 2026). Condividiamo questa lettura: un semplice dato, senza una metodologia pubblicata, non prova nulla, né per un concorrente, né per noi.

Ciò che cambia in termini concreti: hardware (CPU, RAM), versione esatta del framework e del runtime, dimensione del payload JSON, livello di concorrenza e durata del test variano tutti la classifica, a volte più della scelta della lingua stessa. Un banco che non pubblica questi parametri non si riproduce, quindi non verifica se stesso: consulta la nostra metodologia completa e riproducibile per il benchmarking di un backend.

Il backend principale di Aurabase è scritto in Rust, su axum e tokio — controllato in Cargo.toml del monorepo: dieci servizi (aura-gateway, aura-auth, aura-db…) condividono la stessa dipendenza dello spazio di lavoro axum (0.8) e lo stesso runtime tokio, nell'edizione 2021. Il gateway che instrada il traffico del piano dati e del piano di gestione si basa su hyper oltre ad axum: i dettagli completi sono nel nostro articolo su l'architettura del piano dati/piano di gestione del gateway. La struttura dell'area di lavoro Cargo che supporta questi dieci servizi è documentata nel il nostro articolo sull'area di lavoro Cargo.

Ciò che non disponiamo ancora è un dato pubblicato sul throughput o sulla latenza di Aurabase con metodologia e hardware documentati. Questo è intenzionale: preferiamo pubblicare la metodologia prima della figura piuttosto che il contrario – questo sarà l’argomento di un futuro articolo di questa serie.

Per il confronto completo dell'architettura — core Rust unificato presso Aurabase rispetto allo stack eterogeneo Elixir/Go/TypeScript/Node documentato presso un concorrente diretto — consulta il nostro confronto dettagliato Aurabase vs Supabase. Se stai già eseguendo la migrazione di un progetto, la guida alla migrazione da Supabase ad Aurabase copre lo schema, le policy RLS e l'SDK.

Tutte le righe citate in questo articolo, come pubblicate da Sharkbench il 24 agosto 2025 (Docker/Linux, Ryzen 7 7800X3D).

Citare questi dati: Sharkbench, "Web Framework Benchmarks", sharkbench.dev/web, ultimo aggiornamento 24 agosto 2025.

Nel benchmark qui citato, i framework Rust funzionano tutti in un intervallo ristretto - da 18.000 a 22.000 req/s, 1,4-1,7 ms - molto più avanti dei framework Node.js su Node.js stesso (5.766-9.340 req/s, 3,4-5,5 ms). Ma il runtime cambia la situazione tanto quanto la lingua: Express su Bun quasi raggiunge Axum su Rust.

Se valuti un backend solo in base alle prestazioni grezze, richiedi la metodologia prima del numero: hardware, versione, dimensione del carico utile, livello di concorrenza. Aurabase non ha ancora diffuso i propri dati; quando ciò avverrà, la metodologia verrà prima di tutto.