SQLx vs Diesel vs SeaORM per un backend Rust veloce

SQLx, Diesel e SeaORM non sono tre varianti dello stesso strumento. SQLx è un toolkit di basso livello: un driver Postgres arricchito con un controllo opzionale. Diesel è un classico ORM nel senso di Rust: uno strato di tipi sopra SQL. SeaORM è un ORM nel senso Ruby/Python: entità, relazioni, caricamento di oggetti. La tabella seguente riporta i fatti verificabili, tutti datati 23 agosto 2026.

Versioni, download e stelle: API crates.io e API GitHub, interrogate il 23 agosto 2026. Repository SQLx tracciato sotto transact-rs/sqlx (precedentemente launchbadge/sqlx).

Download negli ultimi 90 giorni, in milioni (camporecent_downloads dell'API crates.io). Fonte: crates.io, intervistato il 23 agosto 2026.

SQLx si descrive come "una cassa SQL Rust asincrona e pura con query controllate in fase di compilazione senza DSL" (README ufficiale, github.com/transact-rs/sqlx, accesso il 23 agosto 2026). Nessun generatore di query, nessuna entità: scrivi SQL e SQLx offre due modi per eseguirlo.

// Modalità 1: macro in fase di compilazione: verificata rispetto a un database di sviluppo reale
let user = sqlx::query_as!(User, "SELECT id, email FROM users WHERE id = $1", user_id)
    .fetch_one(&pool)
    .await?;

// Modalità 2: dinamica: tabella/colonne decise in fase di esecuzione
let sql = format!("SELECT * FROM {table} WHERE id = $1");
let row = sqlx::query(&sql).bind(user_id).fetch_one(&pool).await?;

La modalità 1 richiede un database accessibile al momento di cargo build: la macro si connette ad esso per verificare i tipi. La modalità 2 non prevede controlli statici, ma accetta qualsiasi stringa SQL costruita in fase di esecuzione, inclusi i nomi delle tabelle. Questa è la modalità utilizzata da Aurabase (sezione 06).

Obiezione comune contro la modalità 1: come creare CI senza una base di sviluppo accessibile? sqlx-cli risponde in modalità offline (doc ufficiale sqlx-cli, consultato il 23 agosto 2026):

1. Localmente, con un database di sviluppo connesso, avvia cargo sqlx prepare: i metadati di ogni richiesta verificata vengono scritti in una cartella .sqlx.
2. Salva questa cartella .sqlx nel repository, accanto al codice.
3. In CI, definisci SQLX_OFFLINE=true: la build legge i metadati con versione e non tenta più di connettersi a un database reale.

Lo stesso strumento gestisce anche le migrazioni (sqlx migrate add / run / revert) — un ruolo che aura-migrations assume separatamente lato Aurabase.

Diesel si presenta come "un ORM e un generatore di query sicuro ed estensibile per Rust" (sito ufficiale diesel.rs, accesso il 23 agosto 2026). Il progetto afferma inoltre che "elimina la possibilità di interazioni errate del database in fase di compilazione". La differenza fondamentale con SQLx: Diesel controlla le tue query nello stesso sistema di tipo Rust, senza bisogno di un database collegato in fase di creazione.

La stessa pagina di confronto Diesel (accessibile il 23 agosto 2026) individua la differenza: Diesel “può anche controllare parti della query in fase di compilazione”. Ciò ti consente di creare query dinamiche già verificate: un IN su un vettore Rust, un inserimento batch, una clausola condizionale. SQLx, al contrario, “ha sempre bisogno di conoscere l’intera query in fase di compilazione” per la sua macro: questi tre casi rimangono fuori dall’ambito della modalità 1 vista sopra.

Il diesel è sincrono per impostazione predefinita; async passa attraverso la cassa separata diesel-async. Questa stessa pagina riporta che il team di crates.io ha misurato un guadagno del 20% su uno dei suoi endpoint dopo il passaggio al pipeline PostgreSQL di diesel-async. La pagina indica che questa funzionalità manca da SQLx e SeaORM. Questa è un'affermazione di Diesel sul proprio sito relativa a un singolo endpoint, non una misurazione indipendente che abbiamo riprodotto o generalizzato: da prendere come tale.

Diesel include anche i propri strumenti di migrazione e generazione di schemi (README ufficiale, accesso il 23 agosto 2026). diesel migration run applica file SQL con versione. diesel print-schema rigenera il modulo Rust schema.rs che descrive le tue tabelle — la parte che il resto del generatore di query indipendente dai tipi poi utilizza per controllare le tue query in fase di compilazione.

SeaORM si descrive come "un ORM asincrono e dinamico per Rust" (sito ufficiale sea-ql.org/SeaORM, accesso il 23 agosto 2026), con un modello ActiveModel ispirato agli ORM Ruby/Python/Node. Relazioni 1-1, 1-N, M-N e autoreferenziali, caricamento intelligente tramite join o caricatore dati, entità che possono essere generate da un database esistente tramite sea-orm-cli. La verifica viene eseguita in fase di esecuzione, non in fase di compilazione.

Punto spesso trascurato: SeaORM non è sempre un'alternativa a SQLx, a volte è composto da due livelli sopra. La generazione SQL passa attraverso sea-query, il proprio generatore di query dinamiche. È una dipendenza non opzionale di sea-orm 2.0.2 (descrizione di crates.io: "un generatore di query dinamiche per MySQL, Postgres e SQLite", verificato il 23 agosto 2026). L'esecuzione passa attraverso sqlx/sqlx-core e sea-query-sqlx — tre dipendenze dichiarate facoltative, attivate dalla funzionalità (sqlx-postgres, ecc. — API crates.io, verificata il 23 agosto 2026). Concretamente: scegliere SeaORM con il backend Postgres standard significa aggiungere un generatore di query quindi entità/relazioni su SQLx, non sostituirlo.

Le migrazioni seguono la stessa logica degli strumenti dedicati: sea-orm-cli migrate generate/up/down gestisce il controllo delle versioni dello schema. sea-orm-cli generate entity rigenera quindi i file di entità dal database aggiornato: un viaggio di andata e ritorno da schema a codice più vicino a diesel print-schema che alla modalità dinamica di SQLx.

Scegli SQLx se...

• Schema deciso in fase di esecuzione (multi-tenant, introspezione dinamica)
• Vuoi rimanere vicino a SQL, senza DSL da imparare
• Asincrono nativo non negoziabile

Scegli Diesel se...

• Schema stabile, noto al momento della build
• Verifica statica inviata senza database connesso in fase di compilazione
• Sincronizzazione predefinita accettabile o diesel asincrona per pipeline

Scegli SeaORM se...

• Ergonomia di ActiveRecord: relazioni, grafici degli oggetti
• Entità generate da un database esistente
• Un ulteriore livello di astrazione sopra un driver SQL non è un problema

L'area di lavoro Aurabase Cargo aggiunge sqlx = "0.8" alle funzionalità postgres, runtime-tokio-rustls, uuid, chrono, json, derive e rust_decimal. I servizi aura-db e aura-db-adapters dipendono direttamente da esso (verificato nel repository Cargo.toml, 23 agosto 2026).

Ciò che conta più di una linea di dipendenza: nessuna chiamata alla macro sqlx::query! o query_as! in questo codice (0 occorrenze), rispetto alle 532 chiamate a sqlx::query()/query_as(), la forma dinamica. Il motivo è architettonico, non una preferenza di stile. Ogni progetto Aurabase vive nel proprio schema Postgres, risolto all'accesso da SET LOCAL search_path. Il nome della tabella interrogata arriva nella richiesta HTTP, non nel binario compilato.

Il pool di connessioni stesso rimane SQLx standard: libs/aura-db-adapters apre il proprio pool tramite PgPoolOptions::new() (verificato in postgres/mod.rs, 23 agosto 2026), senza overlay proprietario a questo livello. Ciò che è proprietario viene sopra: routing del tenant, convalida degli identificatori di tabella inseriti nell'SQL dinamico e costruzione di clausole WHERE/filtri compatibili con PostgREST.

// Lo schema di destinazione viene risolto tramite query, non noto al momento della compilazione
sqlx::query("SET LOCAL search_path TO $1, public")
    .bind(project_schema)
    .execute(&mut *tx).await?;

// Tabella/colonne decise dal livello REST dinamico (compatibile con PostgREST)
let sql = format!("SELECT * FROM {} WHERE {}", table, where_clause);

Il modello di verifica statica di Diesel presuppone uno schema noto al momento della compilazione del codice binario. L'opposto: un singolo binario che serve un numero illimitato di modelli per progetto, scoperto in fase di esecuzione. La generazione di entità di SeaORM presuppone lo stesso schema fisso. Questo non è un verdetto su SQLx rispetto a Diesel in termini assoluti: è una scelta di architettura: modello noto in fase di compilazione rispetto a modello risolto in fase di esecuzione. Per informazioni dettagliate sul partizionamento schema per progetto e sulle policy RLS associate, vedere la documentazione del database e la guida RLS.

SQLx, Diesel e SeaORM coprono tre diverse esigenze, non tre posti sullo stesso podio. Diesel controlla uno schema che conosci in anticipo il prima possibile. SeaORM ti fa risparmiare tempo sull'usabilità degli oggetti se accetti un ulteriore livello di astrazione, spesso oltre a SQLx stesso. SQLx rimane il più semplice dei tre: questo è ciò che lo rende adatto a un modello che conosci solo in fase di esecuzione, come il routing multi-tenantaura-db.

Se stai migrando un progetto esistente su Postgres e stai cercando cosa cambia realmente sul lato dello schema e delle policy RLS, la nostra guida alla migrazione Supabase → Aurabase dettaglia l'argomento.