SQLx vs Diesel vs SeaORM : quel accès Postgres pour un backend Rust performant

SQLx, Diesel et SeaORM ne sont pas trois variantes du même outil. SQLx est un toolkit bas niveau — un pilote Postgres augmenté d'une vérification optionnelle. Diesel est un ORM classique au sens Rust : une couche de types au-dessus du SQL. SeaORM est un ORM au sens Ruby/Python : des entités, des relations, un chargement d'objets. Le tableau ci-dessous fixe les faits vérifiables, tous datés du 23 août 2026.

Versions, téléchargements et étoiles : API crates.io et API GitHub, interrogées le 23 août 2026. Dépôt SQLx suivi sous transact-rs/sqlx (anciennement launchbadge/sqlx).

SQLx se décrit lui-même comme « an async, pure Rust SQL crate featuring compile-time checked queries without a DSL » (README officiel, github.com/transact-rs/sqlx, consulté le 23 août 2026). Pas de query builder, pas d'entités : vous écrivez du SQL et SQLx propose deux façons de l'exécuter.

// Mode 1 — macro compile-time : vérifiée contre une base de dev réelle
let user = sqlx::query_as!(User, "SELECT id, email FROM users WHERE id = $1", user_id)
    .fetch_one(&pool)
    .await?;
// Mode 2 — dynamique : table/colonnes décidées à l'exécution
let sql = format!("SELECT * FROM {table} WHERE id = $1");
let row = sqlx::query(&sql).bind(user_id).fetch_one(&pool).await?;

Le mode 1 exige une base accessible au moment du cargo build — la macro s'y connecte pour vérifier les types. Le mode 2 n'a aucune vérification statique, mais accepte n'importe quelle chaîne SQL construite à l'exécution — dont les noms de table. C'est le mode que retient Aurabase (section 06).

Objection courante contre le mode 1 : comment builder en CI sans base de dev accessible ? sqlx-cli répond par un mode hors-ligne (doc officielle sqlx-cli, consultée le 23 août 2026) :

1. En local, avec une base de dev connectée, lancez cargo sqlx prepare : les métadonnées de chaque requête vérifiée sont écrites dans un dossier .sqlx.
2. Committez ce dossier .sqlx dans le dépôt, à côté du code.
3. En CI, définissez SQLX_OFFLINE=true : le build lit les métadonnées versionnées et n'essaie plus de se connecter à une base réelle.

Le même outil gère aussi les migrations (sqlx migrate add / run / revert) — un rôle que aura-migrations assume séparément côté Aurabase.

Diesel se présente comme « a Safe, Extensible ORM and Query Builder for Rust » (site officiel diesel.rs, consulté le 23 août 2026). Le projet revendique aussi qu'il « eliminate[s] the possibility of incorrect database interactions at compile time ». La différence de fond avec SQLx : Diesel vérifie vos requêtes dans le système de types de Rust lui-même, sans avoir besoin d'une base connectée au moment du build.

La page de comparaison officielle de Diesel (consultée le 23 août 2026) situe elle-même la différence : Diesel « can also check parts of the query at compile time ». Cela permet de construire des requêtes dynamiques déjà vérifiées — un IN sur un vecteur Rust, un insert par lot, une clause conditionnelle. SQLx, à l'inverse, « always needs to know the whole query at compile time » pour sa macro : ces trois cas restent hors de portée du mode 1 vu plus haut.

Diesel est synchrone par défaut ; l'async passe par le crate séparé diesel-async. Cette même page rapporte que l'équipe de crates.io a mesuré un gain de 20 % sur un de leurs endpoints après passage au pipelining PostgreSQL de diesel-async. La page indique cette fonctionnalité absente de SQLx et SeaORM. C'est une affirmation de Diesel sur son propre site à propos d'un seul endpoint, pas une mesure indépendante que nous avons reproduite ni généralisée : à prendre comme telle.

Diesel embarque aussi ses propres outils de migration et de génération de schéma (README officiel, consulté le 23 août 2026). diesel migration run applique les fichiers SQL versionnés. diesel print-schema régénère le module Rust schema.rs décrivant vos tables — la pièce que le reste du query builder type-safe consomme ensuite pour vérifier vos requêtes au compile-time.

SeaORM se décrit comme « an async & dynamic ORM for Rust » (site officiel sea-ql.org/SeaORM, consulté le 23 août 2026), avec un modèle ActiveModel inspiré des ORM Ruby/Python/Node. Relations 1-1, 1-N, M-N et auto-référencées, chargement intelligent par join ou par data loader, entités générables depuis une base existante via sea-orm-cli. La vérification se fait au runtime, pas à la compilation.

Point souvent ignoré : SeaORM n'est pas toujours une alternative à SQLx, c'est parfois deux couches par-dessus. La génération du SQL passe par sea-query, son propre query builder dynamique. C'est une dépendance non optionnelle de sea-orm 2.0.2 (description crates.io : « a dynamic query builder for MySQL, Postgres and SQLite », vérifié le 23 août 2026). L'exécution, elle, passe par sqlx/sqlx-core et sea-query-sqlx — trois dépendances déclarées optionnelles, activées par feature (sqlx-postgres, etc. — API crates.io, vérifié le 23 août 2026). Concrètement : choisir SeaORM avec le backend Postgres standard, c'est ajouter un query builder puis des entités/relations au-dessus de SQLx, pas le remplacer.

Les migrations suivent la même logique d'outillage dédié : sea-orm-cli migrate generate/up/down gère le versionnage du schéma. sea-orm-cli generate entity régénère ensuite les fichiers d'entités depuis la base à jour — un aller-retour schéma-vers-code plus proche de diesel print-schema que du mode dynamique de SQLx.

Le workspace Cargo d'Aurabase épingle sqlx = "0.8" avec les features postgres, runtime-tokio-rustls, uuid, chrono, json, derive et rust_decimal. Les services aura-db et aura-db-adapters en dépendent directement (vérifié dans les Cargo.toml du dépôt, le 23 août 2026).

Ce qui compte davantage qu'une ligne de dépendance : aucun appel à la macro sqlx::query! ou query_as! dans ce code (0 occurrence), contre 532 appels à sqlx::query()/query_as(), la forme dynamique. La raison est architecturale, pas une préférence de style. Chaque projet Aurabase vit dans son propre schéma Postgres, résolu à la connexion par SET LOCAL search_path. Le nom de table interrogé arrive dans la requête HTTP, pas dans le binaire compilé.

Le pooling de connexions lui-même reste du SQLx standard : libs/aura-db-adapters ouvre son pool via PgPoolOptions::new() (vérifié dans postgres/mod.rs, le 23 août 2026), sans surcouche propriétaire à ce niveau. Ce qui est propriétaire vient au-dessus : le routage par tenant, la validation des identifiants de table injectés dans le SQL dynamique, et la construction des clauses WHERE/filtres compatibles PostgREST.

// Le schéma cible est résolu par requête, pas connu au build
sqlx::query("SET LOCAL search_path TO $1, public")
    .bind(project_schema)
    .execute(&mut *tx).await?;
// Table/colonnes décidées par la couche REST dynamique (compatible PostgREST)
let sql = format!("SELECT * FROM {} WHERE {}", table, where_clause);

Le modèle de vérification statique de Diesel suppose un schéma connu au moment de la compilation du binaire. À l'opposé : un seul binaire qui sert un nombre non borné de schémas par projet, découverts à l'exécution. La génération d'entités de SeaORM part de la même hypothèse d'un schéma fixe. Ce n'est pas un verdict sur SQLx contre Diesel dans l'absolu — c'est un choix d'architecture : schéma connu au build contre schéma résolu à l'exécution. Pour le détail du cloisonnement schema-per-project et des policies RLS associées, voir notre documentation Database et le guide RLS.

SQLx, Diesel et SeaORM couvrent trois besoins différents, pas trois places sur le même podium. Diesel vérifie le plus tôt possible un schéma que vous connaissez à l'avance. SeaORM vous fait gagner du temps sur l'ergonomie objet si vous acceptez une couche d'abstraction de plus — souvent au-dessus de SQLx lui-même. SQLx reste le plus nu des trois : c'est ce qui le rend adapté à un schéma que vous ne connaissez qu'à l'exécution, comme le routage multi-tenant d'aura-db.

Si vous migrez un projet existant vers Postgres et que vous cherchez ce qui change vraiment côté schéma et policies RLS, notre guide de migration Supabase → Aurabase détaille le sujet.