Rust arka uç DB kütüphanelerinden 4’ünün karşılaştırması
(aarambhdevhub.medium.com)Rust ile ciddi biçimde arka uç geliştirmiş olan herkes muhtemelen bir kez bu duvara çarpmıştır. Veritabanına ihtiyaç duyduğunuz anda, dört kütüphane kendi felsefeleri, trade-off’ları ve Reddit’teki sadık takipçi ordularıyla size dik dik bakmaya başlar.
Benim de başıma geldi. Son 1 yılda Diesel, SQLx, SeaORM ve Rusqlite ile gerçek production dağıtımları yaptım. Bazı seçimler tam isabetti, bazılarını ise yeniden yapacak olsam farklı seçerdim. Birkaç sonuç gerçekten şaşırtıcıydı.
Burada ne pazarlama söylemi var ne de “duruma göre değişir” gibi yuvarlak cevaplar. Dördünü de gerçek çalışan kodda kullanmış birinin dürüst değerlendirmesini paylaşacağım.
2026’da neden Rust ile DB işi yapılır?
Önce bunu aradan çıkaralım. Neden Python’da SQLAlchemy ya da Node’da Prisma kullanmıyorsunuz?
Veritabanı merkezli uygulamalarda insanı Rust seçmeye iten üç şey var.
Derleme zamanı güvenliği burada bambaşka bir seviyede. Bu kütüphanelerden bazıları SQL sorgularını doğrudan veritabanı şemasıyla karşılaştırıp derleme anında doğruluyor. Sütun adında yazım hatası mı yaptınız? Derleyici yakalıyor. WHERE koşulunda tipler uyuşmuyor mu? Kod çalışmadan önce eleniyor. Sabah 3’te yapılan debug seanslarını ne kadar azalttığını abartmak zor.
Asenkron nihayet olgunlaştı. Birkaç yıl önce Rust’ta asenkron veritabanı erişimi pürüzlüydü. Borrow checker ile boğuşur, lifetime’ları jonglör gibi çevirir, yarım olgunluktaki kütüphanelerle uğraşırdınız. 2026’da durum ne? Artık sadece çalışıyor. Tokio sağlam, kütüphaneler de yönünü bulmuş durumda.
Performansı düşünmek zorunda kalmıyorsunuz. ORM overhead’i istek bütçenizi kemirmiyor. Garbage collector işlem ortasında duraksamıyor. Sorgu çalışıyor, sonuç geliyor ve bellek deterministik olarak serbest bırakılıyor. Sıkıcı denecek kadar sorunsuz işliyor.
Dört aday
Şubat 2026 itibarıyla en güncel sürümlerle bakalım.
- Diesel (v2.3.6, Ocak 2026) — derleme zamanlı SQL sunan tam kapsamlı ORM
- SQLx (v0.8.6, mevcut kararlı sürüm) — asenkron SQL araç takımı (ORM değil)
- SeaORM (v2.0, Ocak 2026) — asenkron öncelikli dinamik ORM
- Rusqlite (v0.38.0, Aralık 2025) — hafif SQLite sarmalayıcısı
Bunlar, birbiriyle ilişkili sorunları çözen ama temelde farklı araçlar. Tek tek bakalım.
Diesel: hataları sizden önce yakalayan araç
En uygun olduğu durum: Derleme zamanı güvenliğini en üst düzeye çıkarmak isteyen ve şeması istikrarlı olan ekipler
Diesel 2015’ten beri var. Rust dünyasında bu neredeyse antik çağ demek. Ve bu olgunluk kendini en iyi anlamıyla belli ediyor.
Özü şu: Diesel kodunuz derleniyorsa SQL’iniz geçerlidir. Bu bir pazarlama sloganı değil, gerçekten böyle çalışıyor. Diesel, veritabanı şemasından Rust tipleri üretir ve derleyici yazdığınız her sorguyu bu tiplerle karşılaştırarak doğrular.
Diesel’in beni sürekli etkilemesinin nedeni
Derleme zamanı doğrulaması bağımlılık yapıyor. “Derleyici, testleri bile çalıştırmadan hatalı bir JOIN’i yakaladı” deneyimini bir kez yaşayınca, string tabanlı SQL’e dönmek pervasızca geliyor. Geçen ay şemayı refactor ettim—üç sütunun adını değiştirdim ve tiplerini güncelledim—Diesel ise daha derleme aşamasında düzeltilmesi gereken tüm sorguları eksiksiz gösterdi. Gerçekten hepsini.
Zero-cost abstraction burada bir slogan değil. Diesel’in ürettiği SQL, elle yazılmış SQL ile özünde aynı. Çalıştırma planlarını karşılaştırdım; aynıydılar. Yani ORM güvenliğiyle raw SQL performansını birlikte alıyorsunuz.
Migration tarafı düzgün çalışıyor. Bu düşük bir beklenti gibi gelebilir ama başka ekosistemlerde migration araçlarıyla boğuştuktan sonra Diesel’in migration sistemi ferahlatıcı derecede sağlam hissettiriyor. Oluştur, çalıştır, geri al—sadece çalışıyor.
Dürüst eksileri
Asenkron destek sonradan eklenmiş, baştan tasarlanmış değil. Diesel’in kendisi senkron. Asenkron kullanmak için diesel-async gerekiyor; bu iyi çalışıyor ama fazladan bir bağımlılık ve zihinsel yük demek. SQLx ya da SeaORM’un native async yaklaşımından geliyorsanız fark ediliyor.
Öğrenme eğrisi dik. Diesel’in tip sistemi güçlü ve güçlü olan şeyler karmaşık olabiliyor. Bir sorguyu bozduğunuzda derleyici hatası teknik olarak doğru olur, ama aynı zamanda 40 satırlık bir generic tip kusmuğu da olabilir. Okumayı öğreniyorsunuz ama ilk hafta zor geçiyor.
Dinamik sorgular can sıkıcı. Çalışma anında yapısı değişen sorgular—örneğin opsiyonel filtreleri olan bir arama endpoint’i—oluşturmak istediğinizde Diesel direnç gösteriyor. O, statik sorgu şekillerini seviyor. Sorgu dinamik hale geldikçe, iş mantığından çok tip sistemiyle boğuşuyorsunuz.
Diesel’i seçmeniz gereken an
- PostgreSQL veya MySQL projesi yürütüyorsunuz ve şema her hafta değişmiyor
- Derleme zamanı güvenliği sizin için vazgeçilmez
- Kod yıllarca production’da yaşayacak ve doğruluk kritik
- Başka güçlü bir sebep yoksa varsayılan tercihiniz bu olabilir
SQLx: SQL yazın, güvenlik de yanında gelsin
En uygun olduğu durum: SQL odaklı geliştiricilerin, DSL öğrenmeden derleme zamanı doğrulaması istemesi
Dürüst olalım. SQLx bir ORM değil. Sizin için sorgu üretmiyor, ilişkileri yönetmiyor. Bir SQL araç takımı. Ama birçok kişi onu ORM yerine kullanılacak yerde kullanıyor ve açıkçası? Pek çok proje için bu daha iyi bir tercih.
Büyü şöyle çalışıyor: Raw SQL sorgularını string olarak yazıyorsunuz. SQLx derleme zamanında gerçek veritabanına bağlanıp o sorguyu doğruluyor. Tablo yoksa, sütun adı yanlışsa veya tipler uyuşmuyorsa—derleme hatası. Yani normal SQL yazarken Diesel düzeyinde güvenlik alıyorsunuz.
SQLx’in gerçekten çok iyi olduğu noktalar
SQL biliyorsanız SQLx’i de biliyorsunuz. Öğrenmeniz gereken bir sorgu DSL’i yok. Yeni bir zihinsel model yok. Bildiğiniz SQL’i yazıyor, üstüne biraz makro serpiyorsunuz; gerisini derleyici hallediyor. Junior geliştiricileri SQLx projesine dahil etme deneyimime göre bu günler değil, saatler sürüyor.
İlk günden async. SQLx asenkron Rust için tasarlandı. Tokio da olur, async-std de; çalışma zamanınızı seçip devam edersiniz. Ek crate ya da uyumluluk katmanı yok. Asenkron veritabanı erişimi tam olarak böyle olmalı.
QueryBuilder dinamik sorguları iyi yönetiyor. SQLx’in Diesel’i sessizce geçtiği yer burası. Kullanıcıların 12 alanın herhangi bir kombinasyonuyla filtreleme yapabildiği bir arama endpoint’i mi gerekiyor? SQLx’in QueryBuilder aracı bu tür dinamik sorguları sezgisel biçimde kurmanıza izin veriyor. Sorguyu parça parça oluştursanız bile parametreleştirme sayesinde injection’a karşı güvende kalıyorsunuz.
Dürüst eksileri
Derleme sırasında veritabanının açık olması gerekiyor. SQLx hakkındaki en tartışmalı nokta bu. CI pipeline’ınız veritabanı erişimine ihtiyaç duyuyor ve yeni geliştiricilerin derlemeden önce DB’yi ayağa kaldırması gerekiyor. Offline mod, sorgu metadata’sını önbelleğe alıyor ama bu da hatırlanması gereken ek bir workflow adımı demek.
Yüksek seviyeli ORM özellikleri yok. İlişki yükleme yok. Eager/lazy loading yok. Otomatik JOIN yok. İç içe ilişkileri olan karmaşık veri modellerinde tüm SQL’i kendiniz yazmanız gerekiyor. Basit CRUD için sorun değil. Karmaşık veri grafikleri için ise zamanla yorucu hale geliyor.
Offline mod biraz disiplin istiyor. DB olmadan build almak istiyorsanız .sqlx dosyalarını üretmek için cargo sqlx prepare çalıştırmanız gerekiyor. Bu dosyalar önbelleğe alınmış sorgu metadata’sını tutuyor. Sorguyu değiştirip bunları yenilemeyi unutursanız? Bayat build. Çalışır ama sürtünme yaratır.
SQLx’i seçmeniz gereken an
- Ekip zaten SQL düşünce biçimiyle çalışıyor ve ekstra soyutlama katmanı istemiyor
- Dinamik sorgular temel bir gereksinim
- Yeni bir projeye başlıyorsunuz ve çalışan DB koduna en kısa yoldan ulaşmak istiyorsunuz
- Tavizsiz async veritabanı erişimine ihtiyacınız var
SeaORM: tanıdık hissettiren seçenek
En uygun olduğu durum: Async ve dinamik sorgularla modern bir ORM deneyimi isteyen geliştiriciler
Django ORM, ActiveRecord veya Eloquent kullandıysanız SeaORM size tanıdık gelecektir. Ve Ocak 2026’daki 2.0 sürümünden itibaren, gerçekten production’a hazır durumda.
SeaORM, Diesel’in tam tersine bir yaklaşım izliyor. Derleme zamanı doğrulaması yerine çalışma zamanında işliyor. Bir miktar güvenlikten ödün veriyorsunuz ama karşılığında diğer kütüphanelerin yaklaşamadığı bir esneklik kazanıyorsunuz.
SeaORM 2.0’ı dikkate değer yapan şeyler
İlişkiler tam beklediğiniz gibi çalışıyor. Bire çok, çoğa çok, eager loading, lazy loading—SeaORM hepsini hallediyor. Kullanıcı-gönderi-yorum-etiket gibi karmaşık veri modelleriniz varsa SeaORM bu ilişkiler arasında doğal biçimde gezinmenizi sağlıyor. Veritabanıyla kavga ediyor gibi hissettirmiyor.
Dinamik sorgular birinci sınıf vatandaş. Opsiyonel filtreler mi? Koşullu sıralama mı? Sayfalama mı? SeaORM bunların hepsini zahmetsizce yönetiyor. Sorgu üreticisi çalışma anında çalıştığı için yapı özgürce değişebiliyor. Diesel’in zorlandığı ve SeaORM’un parladığı alan tam olarak burası.
2.0’daki özellikler gerçekten işe yarıyor. Entity Loader, N+1 problemini şık biçimde çözüyor—ilişkili entity’leri tek tek sorgulamak yerine verimli biçimde toplu yüklüyor. sea-orm-sync, CLI araçları ve script’ler için senkron bir varyant sunuyor. Nested ActiveModel ise karmaşık insert işlemlerini temiz hale getiriyor.
Entity üretimi gerçekten zaman kazandırıyor. sea-orm-cli aracını veritabanınıza yöneltiyorsunuz ve size Rust entity’leri üretiyor. Şema değişti mi? Yeniden üretin. Çok gösterişli bir iş değil ama otomasyona bağlandığında elle struct tanımlamaktan doğan hataları azaltıyor.
Dürüst eksileri
Çalışma zamanı hataları gerçek bir risk. Diesel veya SQLx’in aksine SeaORM, şema uyumsuzluklarını derleme anında yakalamıyor. Bir sütun adını değiştirip entity’yi güncellemeyi unuttunuz mu? Çalışma zamanı hatası. Bunu telafi etmek için iyi test kapsamına ihtiyacınız var.
Görece yeni. SeaORM 2.0 stabil olsa da ekosistemi daha küçük. Daha az blog yazısı, daha az Stack Overflow yanıtı, daha az “ben de aynı sorunu yaşadım” başlığı var. Resmî dokümantasyona ve Discord’a daha fazla yaslanıyorsunuz.
Bir miktar çalışma zamanı overhead’i var. Dinamik sorgu oluşturmanın bir maliyeti olur. Küçük bir maliyet—uygulamaların %99’unda önemsiz düzeyde—ama her mikrosaniyeyi sıkıştırmaya çalışıyorsanız Diesel ya da SQLx daha hızlı olur.
SeaORM’u seçmeniz gereken an
- Entity’ler arası karmaşık ilişkileri olan bir web API geliştiriyorsunuz
- Dinamik arama/filtreleme ana özelliklerden biri
- Ekip Django, Rails veya Laravel geçmişine sahip ve tanıdık kalıplar istiyor
- Derleme zamanı garantilerinden çok geliştirme hızı önemli
Rusqlite: bariz tercih (SQLite için)
En uygun olduğu durum: CLI araçları, masaüstü uygulamaları, gömülü sistemler ve SQLite kullanan her şey
Rusqlite’e “ORM” demek cömertlik olur. Bu, SQLite için bir sarmalayıcı. Ama gücü de tam burada—tek bir işi yapıyor ve onu kusursuza yakın yapıyor.
Projeniz SQLite kullanıyorsa—ki pek çok Rust projesi kullanıyor—Rusqlite tartışmasız biçimde doğru seçim.
Rusqlite’in bu kadar iyi çalışmasının nedeni
Bundled SQLite harika. bundled feature flag’ini açtığınızda Rusqlite, SQLite’ı doğrudan binary’nin içine derliyor. Sistem bağımlılığı yok. “Lütfen sqlite3-dev kurun” türü dertler yok. Binary’niz her yerde çalışıyor. Hiçbir şey kurulu olmayan makinelere CLI aracı dağıttım; doğrudan çalıştı.
Olması gerektiği kadar ince bir katman. Rusqlite akıllı görünmeye çalışmıyor. Connection, prepared statement ve transaction sağlıyor; üstüne de Rust’ın tip güvenliğini ekliyor. Borrow checker kaynakların yanlış kullanımını engelliyor. Prepared statement’lar injection’ı önlüyor. Hepsi bu. Kütüphanenin olayı tam olarak bu.
SQLite’a özgü özellikleri açığa çıkarıyor. Özel SQL fonksiyonları, sanal tablolar, tam metin arama, JSON eklentileri—Rusqlite ile SQLite’ın tüm özelliklerine erişebiliyorsunuz. Genel amaçlı ORM’ler bunları soyutlama katmanının arkasına saklar. Rusqlite ise doğrudan kullanmanıza izin verir.
Dürüst eksileri
Sadece SQLite için geçerli. PostgreSQL ya da MySQL gerekiyorsa Rusqlite sizin kütüphaneniz değil. Konu burada kapanıyor.
ORM konforu yok. Sorgu üreticisi yok. İlişki yönetimi yok. Migration yok (tabii refinery veya rusqlite_migration kullanabilirsiniz). SQL string’lerini kendiniz yazıyor ve sonuçları elle eşliyorsunuz.
Sadece senkron. Rusqlite async yapmıyor. CLI araçlarında veya masaüstü uygulamalarında bu genelde sorun değil. Web sunucusunda ise SQLx’in SQLite desteğini kullanmanız ya da bunu bir thread pool ile sarmanız gerekir.
Rusqlite’i seçmeniz gereken an
- Yerel depolamaya ihtiyaç duyan bir CLI aracı geliştiriyorsunuz
- Gömülü veritabanı kullanan bir masaüstü uygulaması yapıyorsunuz
- SQLite’ın doğru veritabanı tercihi olduğu herhangi bir proje yürütüyorsunuz
- Veritabanı sunucusu kurulamayan ortamlara dağıtım yapıyorsunuz
Ben bunu pratikte nasıl seçiyorum?
Dördünü de production’da kullandıktan sonra kafamdaki çerçeve şöyle.
SQLite mı? → Rusqlite. Bitti. Fazla düşünmeyin.
Derleme zamanı SQL doğrulaması + sorgu DSL’i mi istiyorsunuz? → Diesel. Uzun ömürlü kod tabanlarında en güvenli bahis bu.
Derleme zamanı doğrulaması istiyor ama raw SQL tercih mi ediyorsunuz? → SQLx. Tüm güvenlik avantajları var, DSL öğrenme eğrisi yok.
Dinamik sorgular, ilişkiler ve modern async ORM mi gerekiyor? → SeaORM 2.0. Özellikle Django veya Rails geçmişiniz varsa.
Yeni bir proje için varsayılan seçim? → Genelde Diesel ile başlıyorum. Başka özel bir neden yoksa. Derleme zamanı güvenliği bana çok fazla kez hayat kurtardı.
Rahatsız edici gerçek
Rust topluluğunda kimsenin kabul etmek istemediği bir şey var: Çoğu projede bunlardan hangisini seçerseniz seçin gayet iyi çalışır.
Hepsi iyi bakılıyor. Hepsi SQL injection’ı önlüyor. Hepsi önem verdiğiniz veritabanlarıyla çalışıyor (kendi kapsamları içinde). Farklar uç noktalarda ortaya çıkıyor ve çoğumuz o uç noktalarda çalışmıyoruz.
Beyninizin çalışma biçimine uyanı seçin. SQL üzerinden düşünüyorsanız SQLx kullanın. Derleyicinin sizi kollamasını istiyorsanız Diesel kullanın. Zaten bildiğiniz ORM’lere benzeyen bir deneyim istiyorsanız SeaORM kullanın. SQLite ise Rusqlite kullanın.
Ve artık araştırmayı bırakıp bir şeyler inşa etmeye başlayın.
Henüz yorum yok.