Rust vs Node.js: バックエンドのベンチマークとレイテンシー

Sharkbench は、同時 HTTP リクエスト、I/O 操作、JSON シリアル化を処理するフレームワークの能力という 3 つのことを測定する独立したコミュニティ プロジェクトです。このテストは、Ryzen 7 7800X3D 上の Docker/Linux で実行され、最後の公開アップデートは 2025 年 8 月 24 日です (sharkbench.dev/web、2026 年 8 月 24 日にアクセス)。

出典: Sharkbench、2025 年 8 月 24 日 — Docker/Linux、Ryzen 7 7800X3D。

Axum — Aurabase が Rust コアに使用するフレームワーク (Cargo.toml で検証済み) — このベンチでは 1 秒あたり 21,030 リクエストを処理します。本番環境で最もよく使用されている Node.js フレームワークである Express は、同じハードウェア上で 5,766 を処理します (係数 3.6)。これは特別なケースではありません。テストされた 4 つの Rust フレームワークはすべて 18,000 ～ 22,000 req/s の狭い範囲内に収まりましたが、テストされた 3 つの Node.js フレームワークの上限は 5,766 ～ 9,340 でした。

実際には、「req/s」は、トラフィックの少ないサイトでの個別のリクエストの速度ではなく、持続的な同時負荷の下でのスループットを測定します。数秒ごとに呼び出されるエンドポイントでは、違いは見られません。これは、ホット エンドポイント (リアルタイム フロー、大量のトラフィックを伴うパブリック API、数千件の呼び出しをつなぎ合わせるジョブ) で決定的になります。同じハードウェアの場合、CPU コアごとに処理されるリクエストの数がインフラストラクチャの請求額を直接決定します。

平均レイテンシは、このベンチでも同じ階層に従います。テストされた Node.js フレームワークの 3.4 ～ 5.5 ミリ秒と比較して、テストされた Rust フレームワークの場合は 1.4 ～ 1.7 ミリ秒です。

出典: Sharkbench、2025 年 8 月 24 日 — 中程度のレイテンシー、p99 ではありません。

この数値は平均値であり、p99 ではありません。マネージド ランタイムでのガベージ一時停止は、主にディスパッチ キュー (中央値ではなく、最も遅いリクエスト) に影響します。これは、このシリーズの専用記事の主題です: ガベージ コレクターの不在により p99 レイテンシーが変化する理由。

Rust はコンパイル時にチェックされる所有権によってメモリを管理します。バックグラウンドで実行されて実行を中断するガベージ コレクターはありません。公式の Rust Book は次のように要約しています: 「所有権の機能のどれも、実行中にプログラムの速度を低下させることはありません」 (The Rust Programming Language、doc.rust-lang.org、2026 年 8 月 24 日にアクセス)。メモリは、それを所有する変数がスコープ外になるとすぐに解放されます。これは、実行時の予測できない一時停止ではなく、コンパイル時の既知の時点です。

fn main() {
    let data = String::from("réponse API"); // `data` は文字列を所有します
    process(data); // 所有権はここから離れます
    // ここでは「data」はもう有効ではありません - ダングリング ポインタも二重解放もありません
} // 「データ」はここで決定的にリリースされます

fn process(s: String) {
    println!("{s}");
} // ここでは「s」は範囲外になります: 即時リリース、ガベージ コレクション パスなし

逆に、Node.js は単一の JavaScript スレッドで実行され、マルチフェーズ イベント ループ (タイマー、遅延コールバック、ポーリング、チェックなど) を介して I/O 操作をカーネルに委任します。ただし、V8 エンジンからのガベージ コレクション パスを含むそのスレッド上の同期計算は、実行中に実行をブロックします (公式 Node.js ドキュメント、 nodejs.org、2026 年 8 月 24 日にアクセス）。これはメモリ モデルの違いであり、実装の詳細ではありません。

同じベンチから得られた最も直観に反する結果は、Rust に関するものではなく、Node.js 自体に関するものです。 Express — まったく同じコード、まったく同じ API — は、アプリケーション コードの行を変更することなく、Node.js の 5,766 req/s から Bun の 18,917 req/s まで、係数 3.3 に達します (Sharkbench、2025 年 8 月 24 日)。

出典: Sharkbench、2025 年 8 月 24 日 — 同じ Express コード、3 つの JavaScript ランタイム。

Deno では、この同じ Express コードの上限は 6,088 req/s であり、Bun には遠く及ばず、Node.js に近い値です。 JavaScript 言語は 3 つのケースすべてで同じです。ゲームを変えるのはランタイム (JS エンジン、イベント ループ実装、ガベージ コレクション) です。ランタイム、バージョン、フレームワークを指定せずに「Rust」と「Node.js」を比較することは、言語ではなく構成を比較するようなものです。

TechEmpower Framework Benchmarks は、同じ考え方をより大きなスケールで示しています。そのオープンソース リポジトリは 2026 年 3 月 24 日に更新され、その最新のラウンド (ラウンド 23) は 2026 年 3 月 16 日の投稿の対象となりました (TechEmpower、2026 年 8 月 24 日にアクセス)。このプロジェクトでは、数百の実装に対してさまざまな種類のテストを実行します。これは、単一のテストが言語はおろかフレームワークを表すことは決してないためです。

データベース市場のプレーヤーである Convex は、この件に関して最も明確な立場を表明しています。競合するデータベース間のマーケティング「棒グラフ戦争」への参加は誤解を招くと考えられ、参加を拒否します。 「スケーリングではなく、スケーリング劇場です」、チームはこう書いています (Convex、2026 年 8 月 24 日にアクセス)。私たちもこの考えを共有しています。公開された方法論のない裸の数字は、競合他社にとっても、私たちにとっても、何も証明しません。

What it changes in concrete terms: hardware (CPU, RAM), exact version of the framework and runtime, size of the JSON payload, level of competition and duration of the test all vary the ranking — sometimes more than the choice of language itself. A bench that does not publish these parameters does not reproduce, therefore does not verify itself — see our complete and reproducible methodology for benchmarking abackend.

The core backend of Aurabase is written in Rust, on axum and tokio — checked in the Cargo.toml of the monorepo: ten services (aura-gateway, aura-auth, aura-db…) share the same workspace dependency axum (0.8) and the same runtime tokio, in 2021 edition. The gateway which routes data plane and management plane traffic relies on hyper in addition to axum — the full details are in our article on the data plane / management plane architecture of the gateway. The structure of the Cargo workspace that supports these ten services is documented in our article on the Cargo workspace.

まだ公開されていないのは、文書化された方法論とハードウェアを伴う Aurabase のスループットまたはレイテンシの数値です。これは意図的なものです。私たちは、その逆ではなく、図の前に方法論を公開することを好みます。これは、このシリーズの将来の記事の主題です。

アーキテクチャの完全な比較 (Aurabase の統合 Rust コアと、直接の競合他社で文書化された異種スタックの Elixir/Go/TypeScript/Node) については、詳細な比較 Aurabase と Supabaseを参照してください。すでにプロジェクトを移行している場合は、Supabase から Aurabase への移行ガイド でスキーマ、RLS ポリシー、SDK について説明しています。

この記事で引用されているすべての行は、2025 年 8 月 24 日に Sharkbench によって公開されたものです (Docker/Linux、Ryzen 7 7800X3D)。

次のデータを引用します: Sharkbench、「Web Framework Benchmarks」、sharkbench.dev/web、最終更新日は 2025 年 8 月 24 日です。

ここで引用されているベンチでは、Rust フレームワークはすべて狭い範囲 (18,000 ～ 22,000 req/s、1.4 ～ 1.7 ミリ秒) で実行され、Node.js 自体の Node.js フレームワーク (5,766 ～ 9,340 req/s、3.4 ～ 5.5 ミリ秒) よりもはるかに優れています。しかし、ランタイムは言語と同じくらい状況を変えます。Bun 上の Express は Rust 上の Axum にほぼ追いつきます。

バックエンドを生のパフォーマンスのみで評価する場合は、ハードウェア、バージョン、ペイロード サイズ、競合レベルなどの数値の前に方法論が必要です。 Aurabase はまだ独自の数値を発表していません。そうなると、まず方法論が優先されます。