Hızlı bir Rust arka uç için SQLx, Diesel ve SeaORM karşılaştırması

SQLx, Diesel ve SeaORM aynı aracın üç çeşidi değildir. SQLx, düşük seviyeli bir araç setidir; isteğe bağlı bir kontrolle zenginleştirilmiş bir Postgres sürücüsü. Diesel, Rust anlamında klasik bir ORM'dir: SQL'in üzerinde bir tür katmanı. SeaORM, Ruby/Python anlamında bir ORM'dir: varlıklar, ilişkiler, nesnelerin yüklenmesi. Aşağıdaki tablo, tümü 23 Ağustos 2026 tarihli doğrulanabilir gerçekleri göstermektedir.

Sürümler, indirmeler ve yıldızlar: Crates.io API ve GitHub API, 23 Ağustos 2026'da sorgulandı. SQLx deposu transact-rs/sqlx (eski adıyla launchbadge/sqlx) altında izleniyor.

Son 90 gündeki indirme sayısı (milyon cinsinden) (crates.io API'sininrecent_downloads alanı). Kaynak: Crates.io, 23 Ağustos 2026'da yapılan röportaj.

SQLx kendisini "DSL olmadan derleme zamanı kontrol edilen sorguları içeren eşzamansız, saf bir Rust SQL sandığı" olarak tanımlıyor (resmi README, github.com/transact-rs/sqlx, 23 Ağustos 2026'da erişildi). Sorgu oluşturucu yok, varlık yok: SQL yazarsınız ve SQLx bunu yürütmek için iki yol sunar.

// Mod 1 — derleme zamanı makrosu: gerçek bir geliştirici veritabanıyla karşılaştırılarak kontrol edildi
let user = sqlx::query_as!(User, "SELECT id, email FROM users WHERE id = $1", user_id)
    .fetch_one(&pool)
    .await?;

// Mod 2 — dinamik: çalışma zamanında karar verilen tablo/sütunlar
let sql = format!("SELECT * FROM {table} WHERE id = $1");
let row = sqlx::query(&sql).bind(user_id).fetch_one(&pool).await?;

Mod 1, cargo build zamanında erişilebilen bir veritabanı gerektirir; makro, türleri kontrol etmek için ona bağlanır. Mod 2'de statik kontroller yoktur ancak tablo adları da dahil olmak üzere çalışma zamanında oluşturulan tüm SQL dizelerini kabul eder. Bu, Aurabase'in kullandığı moddur (bölüm 06).

Mod 1'e karşı yaygın itiraz: Erişilebilir bir geliştirme tabanı olmadan CI'da nasıl derleme yapılır? sqlx-cli çevrimdışı modda yanıt verir (resmi sqlx-cli belgesi, 23 Ağustos 2026'da başvurulmuştur):

1. Yerel olarak, bir geliştirici veritabanı bağlıyken cargo sqlx prepare'yi başlatın: doğrulanan her isteğin meta verileri bir .sqlxklasörüne yazılır.
2. Bu .sqlx klasörünü kodun yanındaki depoya kaydedin.
3. CI'da SQLX_OFFLINE=truetanımlayın: yapı, sürümlendirilmiş meta verileri okur ve artık gerçek bir veritabanına bağlanmaya çalışmaz.

Aynı araç, aura-migrations'nin Aurabase tarafında ayrı olarak üstlendiği bir rol olan geçişleri de yönetir (sqlx migrate add / run / revert).

Diesel kendisini "Rust için Güvenli, Genişletilebilir bir ORM ve Sorgu Oluşturucu" olarak tanıtıyor (resmi web sitesi diesel.rs, 23 Ağustos 2026'da erişildi). Proje ayrıca "derleme zamanında yanlış veritabanı etkileşimi olasılığını ortadan kaldırdığını" iddia ediyor. SQLx ile temel fark: Diesel, sorgularınızı derleme sırasında bağlı bir veritabanına ihtiyaç duymadan Rust tipi sistemin kendisinde kontrol eder.

resmi Diesel karşılaştırma sayfası (23 Ağustos 2026'da erişildi) kendisi farkı buluyor: Diesel "derleme zamanında sorgunun bazı kısımlarını da kontrol edebilir". Bu, zaten doğrulanmış dinamik sorgular (bir Rust vektörü üzerinde bir IN, bir toplu ekleme, bir koşullu cümle) oluşturmanıza olanak tanır. SQLx'in ise tersine, makrosu için "derleme zamanında her zaman sorgunun tamamını bilmesi gerekir": bu üç durum yukarıda görülen mod 1'in kapsamı dışında kalır.

Dizel varsayılan olarak senkronizedir; async ayrı bir sandıktan geçer diesel-async. Aynı sayfada, Crates.io ekibinin, diesel-async'in PostgreSQL ardışık düzenine geçtikten sonra uç noktalarından biri olan'de %20'lik bir kazanç ölçtüğünü bildiriyor. Sayfa, bu işlevselliğin SQLx ve SeaORM'de eksik olduğunu gösteriyor. Bu, Diesel'in kendi sitesinde tek bir uç nokta hakkında yaptığı bir açıklamadır; bizim çoğalttığımız veya genelleştirdiğimiz bağımsız bir ölçüm değildir: bu şekilde ele alınacaktır.

Diesel ayrıca kendi geçiş ve şema oluşturma araçlarını da içerir (resmi README, 23 Ağustos 2026'da erişildi). diesel migration run sürümlendirilmiş SQL dosyalarını uygular. diesel print-schema, tablolarınızı açıklayan schema.rs Rust modülünü yeniden oluşturur; bu, tür açısından güvenli sorgu oluşturucunun geri kalanının derleme zamanı sorgularınızı kontrol etmek için kullandığı kısımdır.

SeaORM kendisini Ruby/Python/Node ORM'lerinden esinlenen bir ActiveModel modeliyle "Rust için eşzamansız ve dinamik bir ORM" (resmi site sea-ql.org/SeaORM, 23 Ağustos 2026'da erişildi) olarak tanımlıyor. 1-1, 1-N, M-N ve kendi kendine referanslı ilişkiler, birleştirme veya veri yükleyici tarafından akıllı yükleme, sea-orm-cliaracılığıyla mevcut bir veritabanından oluşturulabilen varlıklar. Doğrulama derleme sırasında değil çalışma zamanında yapılır.

Çoğu zaman gözden kaçan nokta: SeaORM her zaman SQLx'e alternatif değildir, bazen üstte iki katman bulunur. SQL oluşturma, kendi dinamik sorgu oluşturucusu olan sea-queryüzerinden gerçekleşir. Bu, sea-orm 2.0.2'nin isteğe bağlı olmayan bir bağımlılığıdır (crates.io açıklaması: “MySQL, Postgres ve SQLite için dinamik bir sorgu oluşturucu”, 23 Ağustos 2026'da doğrulandı). Yürütme sqlx/sqlx-core ve sea-query-sqlx aracılığıyla gerçekleştirilir; isteğe bağlı olarak bildirilen, özelliğe göre etkinleştirilen üç bağımlılık (sqlx-postgresvb. — Crates.io API, 23 Ağustos 2026'da doğrulandı). Somut olarak: SeaORM'ü standart Postgres arka ucuyla seçmek, bir sorgu oluşturucu eklemek, ardından SQLx'in üzerine varlıklar/ilişkiler eklemek anlamına gelir, onu değiştirmek değil.

Geçişler aynı özel araç mantığını takip eder: sea-orm-cli migrate generate/up/down şema sürümlendirmeyi yönetir. sea-orm-cli generate entity daha sonra varlık dosyalarını güncellenmiş veritabanından yeniden oluşturur; şemadan koda gidiş-dönüş, SQLx'in dinamik modundan ziyade diesel print-schema'ye daha yakındır.

Aşağıdaki durumlarda SQLx'i seçin:

• Uygulama sırasında karar verilen şema (çok kiracılı, dinamik iç gözlem)
• Öğrenmek için DSL olmadan SQL'e yakın kalmak istiyorsunuz
• Pazarlığa açık olmayan yerel eşzamansız

Aşağıdaki durumlarda Dizel'i seçin:

• Yapım sırasında bilinen kararlı şema
• Derleme zamanına bağlı veritabanı olmadan itilen statik doğrulama
• Varsayılan senkronizasyon kabul edilebilir veya işlem hattı için dizel eşzamansız

Aşağıdaki durumlarda SeaORM'ü seçin:

• ActiveRecord ergonomisi: ilişkiler, nesne grafikleri
• Mevcut bir veritabanından oluşturulan varlıklar
• SQL sürücüsünün üzerinde bir soyutlama katmanı daha sorun değil

Aurabase Cargo çalışma alanı sqlx = "0.8" öğesini postgres, runtime-tokio-rustls, uuid, chrono, json, derive ve rust_decimalözellikleriyle sabitler. aura-db ve aura-db-adapters hizmetleri doğrudan buna bağlıdır (Cargo.toml deposunda doğrulanmıştır, 23 Ağustos 2026).

Bir bağımlılık satırından daha önemli olan şey: dinamik form olan sqlx::query()/query_as()'ye yapılan 532 çağrıyla karşılaştırıldığında, bu kodda sqlx::query! veya query_as! makrosuna çağrı yapılmaz (0 oluşum). Sebebi stil tercihi değil mimaridir. Her Aurabase projesi, giriş sırasında SET LOCAL search_pathtarafından çözümlenen kendi Postgres şemasında yaşar. Sorgulanan tablo adı derlenmiş ikili dosyada değil, HTTP isteğinde gelir.

Bağlantı havuzu oluşturmanın kendisi standart SQLx olarak kalır: libs/aura-db-adapters, havuzunu bu düzeyde özel bir katman olmadan PgPoolOptions::new() (postgres/mod.rs, 23 Ağustos 2026'da doğrulanmıştır) aracılığıyla açar. Tescilli olan yukarıda gelir: kiracı yönlendirme, dinamik SQL'e eklenen tablo tanımlayıcılarının doğrulanması ve WHEREyan tümcelerinin/PostgREST uyumlu filtrelerin oluşturulması.

// Hedef şema, derleme sırasında bilinmeyen sorguyla çözümlenir
sqlx::query("SET LOCAL search_path TO $1, public")
    .bind(project_schema)
    .execute(&mut *tx).await?;

// Dinamik REST katmanı tarafından belirlenen tablo/sütunlar (PostgREST uyumlu)
let sql = format!("SELECT * FROM {} WHERE {}", table, where_clause);

Diesel'in statik doğrulama modeli, ikili dosyanın derlendiği sırada bilinen bir modeli varsayar. Tam tersi: çalışma zamanında keşfedilen, proje başına sınırsız sayıda desene hizmet eden tek bir ikili dosya. SeaORM'ün varlık oluşturma işlemi, sabit bir şemayla aynı varsayımı yapar. Bu, mutlak anlamda SQLx ile Diesel arasında bir karar değildir; bu bir mimari seçimidir: oluşturma sırasında bilinen modele karşı çalışma zamanında çözülen model. Proje başına şema bölümleme ve ilgili RLS politikalarının ayrıntıları için Veritabanı belgelerimize ve RLS kılavuzu'ye bakın.

SQLx, Diesel ve SeaORM aynı podyumda üç yeri değil üç farklı ihtiyacı karşılıyor. Diesel, önceden bildiğiniz bir düzeni mümkün olduğu kadar erken kontrol eder. SeaORM, genellikle SQLx'in üstüne ek olarak bir soyutlama katmanını daha kabul ederseniz nesne kullanılabilirliği konusunda size zaman kazandırır. SQLx, üçü arasında en temel olanı olmaya devam ediyor:aura-dbçok kiracılı yönlendirme gibi, onu yalnızca çalışma zamanında bildiğiniz bir model için uygun kılan da budur.

Mevcut bir projeyi Postgres'e taşıyorsanız ve RLS şeması ve politikaları tarafında gerçekten nelerin değiştiğini arıyorsanız, geçiş kılavuzumuz Supabase → Aurabase konuyu detaylandırıyor.