Rust vs Node.js: test porównawczy backendu i opóźnienia

Sharkbench to niezależny projekt społecznościowy, który mierzy trzy rzeczy: zdolność frameworka do obsługi współbieżnych żądań HTTP, operacje we/wy i serializację JSON. Test odbywa się w systemie Docker/Linux na procesorze Ryzen 7 7800X3D, a ostatnia publiczna aktualizacja miała miejsce 24 sierpnia 2025 r. (sharkbench.dev/web, dostęp: 24 sierpnia 2026 r.).

Źródło: Sharkbench, 24 sierpnia 2025 — Docker/Linux, Ryzen 7 7800X3D.

Axum — framework, którego używa Aurabase w swoim rdzeniu Rust, zweryfikowany w Cargo.toml — przetwarza na tym stanowisku 21 030 żądań na sekundę. Express, framework Node.js najczęściej używany w środowisku produkcyjnym, przetwarza 5766 na tym samym sprzęcie: współczynnik 3,6. To nie jest odosobniony przypadek. Wszystkie cztery przetestowane frameworki Rust mieszczą się w wąskim zakresie od 18 000 do 22 000 wymagań/s, podczas gdy trzy testowane frameworki Node.js osiągają limit od 5766 do 9340.

W praktyce „req/s” mierzy przepustowość przy ciągłym, współbieżnym obciążeniu, a nie prędkość izolowanego żądania w witrynie o małym natężeniu ruchu. W przypadku punktu końcowego wywoływanego raz na kilka sekund różnica nigdy nie jest widoczna. Ma to decydujące znaczenie w przypadku gorącego punktu końcowego — przepływu w czasie rzeczywistym, publicznego interfejsu API o dużym natężeniu ruchu, zadania obejmującego tysiące wywołań — gdzie liczba żądań przetworzonych na rdzeń procesora przy jednakowym sprzęcie bezpośrednio określa rachunek za infrastrukturę.

Średnie opóźnienie ma tę samą hierarchię na tym stanowisku: od 1,4 do 1,7 ms dla testowanych frameworków Rust w porównaniu do 3,4 do 5,5 ms dla testowanych frameworków Node.js.

Źródło: Sharkbench, 24 sierpnia 2025 r. — średnie opóźnienie, a nie p99.

Liczba ta jest średnią, a nie p99. Wstrzymania związane ze śmieciami w zarządzanym środowisku wykonawczym wpływają głównie na kolejkę wysyłkową — na najwolniejsze żądania, a nie na medianę. Jest to temat dedykowanego artykułu z tej serii: dlaczego brak modułu zbierającego elementy bezużyteczne zmienia opóźnienie p99.

Rust zarządza pamięcią według własności, sprawdzaną w czasie kompilacji — żaden moduł zbierający elementy bezużyteczne nie działa w tle i nie zakłóca wykonywania. Oficjalna Księga Rust podsumowuje to w następujący sposób: „Żadna z cech własności nie spowolni twojego programu podczas jego działania” (The Rust Programming Language, doc.rust-lang.org, dostęp 24 sierpnia 2026). Pamięć jest zwalniana, gdy tylko zmienna będąca jej właścicielem wykracza poza zakres — jest to znany czas kompilacji, a nie nieprzewidywalna przerwa w czasie wykonywania.

fn main() {
    let data = String::from("réponse API"); // `data` jest właścicielem ciągu
    process(data); // posiadanie opuszcza tutaj
    // „dane” nie są już tutaj ważne — żadnego wiszącego wskaźnika, żadnego podwójnego zwolnienia
} // „dane” są tutaj uwalniane w sposób deterministyczny

fn process(s: String) {
    println!("{s}");
} // `s` wykracza tutaj poza zakres: natychmiastowe wydanie, bez przepustki na śmieci

Z kolei Node.js działa na pojedynczym wątku JavaScript i deleguje operacje we/wy do jądra poprzez wielofazową pętlę zdarzeń (timery, odroczone wywołania zwrotne, odpytywanie, sprawdzanie...) — ale wszelkie synchroniczne obliczenia w tym wątku, w tym przepustka do zbierania elementów bezużytecznych z silnika V8, blokują wykonywanie podczas jego działania (oficjalna dokumentacja Node.js, nodejs.org, dostęp 24 sierpnia 2026). Jest to różnica w modelu pamięci, a nie szczegół implementacji.

Najbardziej sprzeczny z intuicją wynik z tej samej analizy nie dotyczy Rusta: dotyczy samego Node.js. Express — jeden i ten sam kod, jedno i to samo API — wzrasta z 5766 żądań/s w Node.js do 18 917 żądań/s w Bun, współczynnik ×3,3, bez zmiany wiersza kodu aplikacji (Sharkbench, 24 sierpnia 2025 r.).

Źródło: Sharkbench, 24 sierpnia 2025 r. — ten sam kod Express, trzy środowiska wykonawcze JavaScript.

W Deno ten sam kod Express ogranicza się do 6088 żądań/s — blisko Node.js, daleko od Bun. Język JavaScript jest identyczny we wszystkich trzech przypadkach; To środowisko wykonawcze — silnik JS, implementacja pętli zdarzeń, zbieranie elementów bezużytecznych — zmienia grę. Porównywanie „Rust” do „Node.js” bez określenia środowiska wykonawczego, wersji i frameworku jest jak porównywanie konfiguracji, a nie języków.

Testy porównawcze TechEmpower Framework ilustrują ten sam pomysł na większą skalę. Repozytorium open source zostało zaktualizowane 24 marca 2026 r., a jego ostatnia runda (runda 23) była tematem postu z dnia 16 marca 2026 r. (TechEmpower, dostęp: 24 sierpnia 2026 r.). W tym projekcie przeprowadza się wiele rodzajów testów w setkach implementacji, właśnie dlatego, że pojedynczy test nigdy nie reprezentuje frameworka, nie mówiąc już o języku.

Convex, gracz na rynku baz danych, sformułował w tej sprawie najjaśniejsze stanowisko: odmawiając udziału w marketingowej „wojnie na wykresy słupkowe” pomiędzy konkurującymi bazami danych, uznanej za wprowadzającą w błąd. „To teatr skalowania, a nie skalowanie”, pisze zespół (Convex, dostęp 24 sierpnia 2026 r.). Podzielamy tę lekturę: gołe liczby, bez opublikowanej metodologii, niczego nie dowodzą – ani dla konkurencji, ani dla nas.

Konkretne zmiany: sprzęt (procesor, pamięć RAM), dokładna wersja frameworku i środowisko wykonawcze, rozmiar ładunku JSON, poziom konkurencji i czas trwania testu – wszystko to wpływa na ranking – czasem bardziej niż sam wybór języka. Ławka, która nie publikuje tych parametrów, nie reprodukuje się, dlatego nie weryfikuje się sama — zobacz naszą kompletną i powtarzalną metodologię benchmarkingu backendu.

Podstawowy backend Aurabase jest napisany w języku Rust, na axum i tokio — sprawdzany w Cargo.toml monorepo: dziesięć usług (aura-gateway, aura-auth, aura-db…) ma tę samą zależność obszaru roboczego axum (0.8) i to samo środowisko wykonawcze tokiow 2021 r. wydanie. Brama, która kieruje ruchem płaszczyzny danych i płaszczyzny zarządzania, oprócz axum opiera się na hyper — szczegółowe informacje można znaleźć w naszym artykule na temat architektury płaszczyzny danych/płaszczyzny zarządzania bramy. Strukturę obszaru roboczego Cargo obsługującą te dziesięć usług opisano w naszym artykule na temat obszaru roboczego Cargo.

Nie mamy jeszcze opublikowanych danych dotyczących przepustowości i opóźnień Aurabase wraz z udokumentowaną metodologią i sprzętem. Jest to celowe: wolimy publikować metodologię przed wykresem, a nie odwrotnie – jest to temat przyszłego artykułu z tej serii.

Aby uzyskać pełne porównanie architektury — zunifikowany rdzeń Rust w Aurabase w porównaniu z heterogenicznym stosem Elixir/Go/TypeScript/Node udokumentowany u bezpośredniego konkurenta — zobacz nasze szczegółowe porównanie Aurabase vs Supabase. Jeśli już migrujesz projekt, przewodnik migracji Supabase do Aurabase omawia schemat, zasady RLS i SDK.

Wszystkie wiersze cytowane w tym artykule, opublikowane przez Sharkbench 24 sierpnia 2025 r. (Docker/Linux, Ryzen 7 7800X3D).

Przytocz te dane: Sharkbench, „Web Framework Benchmarks”, sharkbench.dev/web, ostatnia aktualizacja 24 sierpnia 2025 r.

Na przytoczonym tutaj stanowisku wszystkie frameworki Rusta działają w wąskim zakresie — 18 000 do 22 000 req/s, 1,4–1,7 ms — znacznie wyprzedzając frameworki Node.js na samym Node.js (5766–9340 req/s, 3,4–5,5 ms). Ale środowisko wykonawcze zmienia sytuację w takim samym stopniu, jak język: Express na Bun prawie dogania Axum na Rust.

Jeśli oceniasz backend wyłącznie na podstawie surowej wydajności, przed podaniem liczby wymagaj metodologii: sprzętu, wersji, rozmiaru ładunku, poziomu konkurencji. Aurabase nie opublikował jeszcze własnych danych liczbowych; kiedy to nastąpi, na pierwszym miejscu będzie metodologia.