高速 Rust バックエンドのための SQLx、Diesel、SeaORM

SQLx、Diesel、SeaORM は、同じツールの 3 つのバリエーションではありません。 SQLx は低レベルのツールキットであり、オプションのチェックで強化された Postgres ドライバーです。 Diesel は、Rust の意味での古典的な ORM、つまり SQL の上にある型の層です。 SeaORM は、エンティティ、関係、オブジェクトの読み込みなど、Ruby/Python の意味での ORM です。以下の表は検証可能な事実をまとめたもので、日付はすべて 2026 年 8 月 23 日です。

バージョン、ダウンロード、スター: crates.io API および GitHub API、2026 年 8 月 23 日にクエリ。SQLx リポジトリは transact-rs/sqlx (以前の launchbadge/sqlx) で追跡されています。

過去 90 日間のダウンロード数 (数百万件) ( crates.io API のrecent_downloads フィールド)。出典: crates.io、2026 年 8 月 23 日にインタビュー。

SQLx は自身を「DSL を使用せずにコンパイル時にチェックされるクエリを備えた非同期の純粋な Rust SQL クレート」と説明しています (公式 README、github.com/transact-rs/sqlx、2026 年 8 月 23 日にアクセス)。クエリ ビルダーもエンティティも必要ありません。SQL を作成すると、SQLx はそれを実行する 2 つの方法を提供します。

// モード 1 — コンパイル時マクロ: 実際の開発データベースに対してチェックされます。
let user = sqlx::query_as!(User, "SELECT id, email FROM users WHERE id = $1", user_id)
    .fetch_one(&pool)
    .await?;

// モード 2 — 動的: テーブル/列は実行時に決定されます。
let sql = format!("SELECT * FROM {table} WHERE id = $1");
let row = sqlx::query(&sql).bind(user_id).fetch_one(&pool).await?;

モード 1 では、cargo build の時点でデータベースにアクセスできる必要があります。マクロは型をチェックするためにデータベースに接続します。モード 2 には静的チェックはありませんが、テーブル名を含め、実行時に構築されるあらゆる SQL 文字列を受け入れます。これは、Aurabase が使用するモードです (セクション 06)。

モード 1 に対する一般的な反対意見: アクセス可能な開発ベースなしで CI を構築するにはどうすればよいですか? sqlx-cli はオフライン モードで応答します (公式 sqlx-cli ドキュメント、2026 年 8 月 23 日に参照)。

1. 開発データベースに接続した状態で、ローカルで cargo sqlx prepareを起動します。検証された各リクエストのメタデータは .sqlxフォルダーに書き込まれます。
2. この .sqlx フォルダーをリポジトリのコードの隣にコミットします。
3. CI で SQLX_OFFLINE=trueを定義します。ビルドはバージョン管理されたメタデータを読み取り、実際のデータベースへの接続を試行しなくなります。

同じツールは移行 (sqlx migrate add / run / revert) も管理します。これは、 aura-migrations が Aurabase 側で個別に引き受ける役割です。

Diesel は、自らを「Rust 用の安全で拡張可能な ORM およびクエリ ビルダー」と称しています (公式 Web サイト Diesel.rs、2026 年 8 月 23 日にアクセス)。このプロジェクトはまた、「コンパイル時にデータベースが誤って相互作用する可能性を排除する」とも主張しています。 SQLx との基本的な違い: Diesel は、ビルド時にデータベースに接続する必要がなく、Rust 型システム自体でクエリをチェックします。

公式 Diesel 比較ページ (2026 年 8 月 23 日にアクセス) 自体にその違いが記載されています。Diesel は「コンパイル時にクエリの一部をチェックすることもできる」ということです。これにより、Rust ベクトルの IN、バッチ挿入、条件句など、検証済みの動的クエリを構築できます。逆に、SQLx はマクロについて「コンパイル時に常にクエリ全体を知る必要がある」ため、これら 3 つのケースは上記のモード 1 の範囲外のままです。

Diesel はデフォルトで同期です。 async は別のクレート diesel-asyncを経由します。この同じページでは、crates.io チームが Diesel-async の PostgreSQL パイプラインに切り替えた後、エンドポイントの 1 つで 20% の向上を測定したと報告しています。このページには、この機能が SQLx と SeaORM にないことが示されています。これは、単一のエンドポイントに関する Diesel の自社サイトでの声明であり、当社が再現または一般化した独立した測定値ではありません。そのように受け取ってください。

Diesel には、独自の移行およびスキーマ生成ツールも含まれています (公式 README、2026 年 8 月 23 日にアクセス)。 diesel migration run は、バージョン管理された SQL ファイルを適用します。 diesel print-schema は、テーブルを記述する Rust モジュール schema.rs を再生成します。この部分は、タイプセーフなクエリ ビルダーの残りの部分がコンパイル時のクエリをチェックするために使用されます。

SeaORM は自身を「Rust 用の非同期および動的 ORM」 (公式サイト sea-ql.org/SeaORM、2026 年 8 月 23 日にアクセス) と説明しており、Ruby/Python/Node ORM からインスピレーションを得た ActiveModel モデルを備えています。 1-1、1-N、M-N および自己参照関係、結合またはデータ ローダーによるインテリジェントな読み込み、 sea-orm-cliを介して既存のデータベースから生成できるエンティティ。検証はコンパイル時ではなく実行時に行われます。

見落とされがちな点: SeaORM は常に SQLx の代替となるわけではなく、上部に 2 つのレイヤーが存在する場合もあります。 SQL の生成は、独自の動的クエリ ビルダーである sea-queryを経由します。これは、sea-orm 2.0.2 のオプションではない依存関係です (crates.io の説明: 「MySQL、Postgres、SQLite 用の動的クエリ ビルダー」、2026 年 8 月 23 日に確認)。実行は sqlx/sqlx-core および sea-query-sqlx — オプションとして宣言され、機能によってアクティブ化される 3 つの依存関係 (sqlx-postgresなど — crates.io API、2026 年 8 月 23 日に検証) を経由します。具体的には、標準の Postgres バックエンドを備えた SeaORM を選択するということは、SQLx を置き換えるのではなく、SQLx の上にクエリ ビルダー、次にエンティティ/リレーションを追加することを意味します。

移行は同じ専用ツール ロジックに従います。sea-orm-cli migrate generate/up/down はスキーマのバージョン管理を管理します。 次に、sea-orm-cli generate entity は、更新されたデータベースからエンティティ ファイルを再生成します。これは、SQLx の動的モードよりも diesel print-schema に近い、スキーマからコードへのラウンド トリップです。

次の場合は SQLx を選択してください…

• 実行時に決定されるスキーマ (マルチテナント、動的イントロスペクション)
• DSL を学ぶことなく SQL に近づきたい
• 交渉不可能なネイティブ非同期

こんなときはディーゼルを選んでください…

• 安定したスキーマ（ビルド時に既知）
• コンパイル時にデータベースを接続せずにプッシュされた静的検証
• デフォルトの同期を受け入れ可能、またはパイプラインの場合はディーゼル非同期

次の場合は SeaORM を選択してください…

• ActiveRecord のエルゴノミクス: リレーションシップ、オブジェクト グラフ
• 既存のデータベースから生成されたエンティティ
• SQL ドライバーの上にもう 1 層抽象化層を追加しても問題ありません

Aurabase Cargo ワークスペースは、 postgres、 runtime-tokio-rustls、 uuid、 chrono、 json、 derive および rust_decimalの機能を備えた sqlx = "0.8" を固定します。 aura-db および aura-db-adapters サービスはこれに直接依存しています (Cargo.toml リポジトリ、2026 年 8 月 23 日で確認)。

依存関係行よりも重要なこと: このコードでは、マクロ sqlx::query! または query_as! の呼び出しはありません (0 回発生)。これに対し、動的形式の sqlx::query()/query_as()への呼び出しは 532 回あります。その理由はスタイルの好みではなく、建築上の理由です。各 Aurabase プロジェクトは独自の Postgres スキーマ内に存在し、ログイン時に SET LOCAL search_pathによって解決されます。クエリされたテーブル名は、コンパイルされたバイナリではなく、HTTP リクエストで到着します。

接続プーリング自体は標準 SQLx のままです。 libs/aura-db-adapters は、このレベルで独自のオーバーレイを使用せずに、 PgPoolOptions::new() (2026 年 8 月 23 日の postgres/mod.rsで検証) 経由でプールを開きます。プロプライエタリなものは、テナント ルーティング、動的 SQL に挿入されたテーブル識別子の検証、WHERE句/PostgREST 互換フィルターの構築などです。

// ターゲット スキーマはクエリによって解決されますが、ビルド時には不明です
sqlx::query("SET LOCAL search_path TO $1, public")
    .bind(project_schema)
    .execute(&mut *tx).await?;

// 動的REST層で決定されるテーブル/カラム（PostgREST互換）
let sql = format!("SELECT * FROM {} WHERE {}", table, where_clause);

Diesel の静的検証モデルは、バイナリのコンパイル時に既知のパターンを想定しています。その反対は、プロジェクトごとに無制限の数のパターンを提供する単一のバイナリで、実行時に検出されます。 SeaORM のエンティティ生成では、固定スキーマと同じ仮定が行われます。これは SQLx 対 Diesel に関する絶対的な判断ではありません。これはアーキテクチャの選択です。ビルド時に既知のパターンと実行時に解決されるパターンです。プロジェクトごとのスキーマのパーティショニングと関連する RLS ポリシーの詳細については、データベース ドキュメント および RLS ガイドを参照してください。

SQLx、Diesel、SeaORM は、同じ表彰台に 3 つの場所を置くのではなく、3 つの異なるニーズをカバーします。ディーゼルは、事前にわかっているパターンをできるだけ早くチェックします。 SeaORM では、抽象化のもう 1 つの層 (多くの場合、SQLx 自体の上に) を受け入れれば、オブジェクトの使いやすさにかかる時間を節約できます。 SQLx は、3 つの中で最も必要最低限​​の機能を備えています。そのため、aura-dbマルチテナント ルーティングなど、実行時にしか分からないパターンに適しています。

既存のプロジェクトを Postgres に移行しており、RLS スキーマとポリシー側で実際に何が変わるのかを探している場合は、移行ガイド Supabase → Aurabase でこの主題について詳しく説明します。