SQLite’ı Bırakıp Rust Veritabanına Geçince Ne Değişti?

Bakın şimdi, “veriyi nereye koyacağız?” sorusu yıllardır geliştiricilerin en sevdiği kaçış rampası oldu. Ben de açık konuşayım — uzun süre aynı refleksi verdim: Daha açık söyleyeyim, sQLite. Küçük proje mi? SQLite. Log mu? SQLite. Ayar dosyası mı? Yine SQLite. Hatta bir ara evdeki otomasyon denemelerinde bile onu kullanmıştım; 2023 sonbaharında Kadıköy’de kurcaladığım mini IoT düzeneğinde her şeyi tek dosyada tutmak bayağı rahat gelmişti, itiraf edeyim.

Gel gelelim iş yapay zekâ destekli bir robotun “hafıza”sına gelince tablo değişiyor. Ciddi şekilde. Çünkü burada mesele sadece kayıt saklamak değil; görüntü, ses, zaman damgası, benzerlik araması ve hızlı geri çağırma gibi şeyler birbirine öyle bir giriyor ki, klasik ilişkisel veritabanı alışkanlığı tökezliyor… hatta dürüst olayım, bayağı tökezliyor (kendi tecrübem)

Bu yazıda dev.to’daki orijinal deneyimden ilham alarak meseleyi kendi gözümden anlatacağım: Neden bazı durumlarda SQLite fazla tanıdık olduğu için seçiliyor ama yine de doğru araç olmuyor? Ve Rust ile yazılmış gömülü bir veritabanı fikri neden özellikle kenar cihazlarda cazip hale geliyor?

Bunu biraz açayım.

Neden Her Şey SQLite Olunca İş Karışıyor?

SQLite’ın kötü olduğunu söylemek haksızlık olur. Tam tersine. Birçok iş için fena değil, hatta kurtarıcı. Ama robot hafızası (belki yanılıyorum ama) dediğimiz şey düz metin kayıtlarından ibaret değil ki — bir yüz görüntüsünü temsil eden 512 boyutlu embedding, kısa bir ses kırpıntısı, güven skoru, etiket ve bağlam bilgisi… Bunların hepsini tek satırlık mantıkla düşününce insanın eli ister istemez JSON’a gidiyor, oradan da işler çığırından çıkıyor.

Benzer bir sıkıntıyı geçen yıl Bursa’da küçük bir edge AI demo’sunda bizzat yaşadım. Görüntü sınıflandırma çıktısını önce PostgreSQL’e basmaya çalıştık, sonra birden “ya bunu neden böyle yapıyoruz?” diye birbirimize baktık. Kayıt saklamak kolaydı ama asıl dert sonradan o veriye hızlıca erişmekti. Aynı şey burada da geçerli.

Şimdi gelelim işin can alıcı noktasına.

“Satır” modeli bazen yetmiyor

SQLite size satır verir; güzel de verir üstelik. Ama AI ajanının hatırladığı — ki bu tartışılır — şey çoğu zaman satır değil, anlık bir paket gibidir — ben buna “moment” demeyi daha doğru buluyorum. Bir an var, içinde kamera karesi var, ses var, konum var, belki sıcaklık sensörü var, neden olmasın belki batarya seviyesi de var… Bunları ayrı kolonlara bölünce teoride düzenli görünüyor ama pratikte veri paramparça oluyor, yönetmek giderek zorlaşıyor (kendi tecrübem)

Lafı gevelemeden söyleyeyim: Uygulamanız çoğunlukla “şunu kaydet / şunu getir” seviyesindeyse SQLite iş görür. Ama konu benzerlik aramasına gelince işler değişir, çünkü artık veritabanı size sadece depolama değil, akıllıca erişim de vermek zorunda kalıyor.

Bir robotun hafızasında kilit soru şu değil: “Veri nerede duruyor?” Asıl soru şu: “İhtiyacım olduğunda bu anıyı ne kadar hızlı çıkarabiliyorum?”

Sorun Performans Değilmiş Gibi Görünüyor… Ta ki Ölçene Kadar

Açık konuşayım. Performans konusu ilk başta gerçekten yanıltıcı oluyor. Tek kayıt eklemek genelde gayet iyi hissettiriyor insana — “aa valla hızlı, sorun yok” diyorsunuz. Fakat yüz tanıma ya da benzer nesne bulma gibi işler başladığında maske düşüyor; Raspberry Pi 5 üzerinde yapılan ölçümlerde tek embedding kaydı makul sürede yazılıyor ama top-5 benzerlik araması ciddi gecikme yaratıyor.

Buna çok benzeyen bir şeyi Ankara’da ofiste test ettiğim küçük bir sesli asistan prototipinde gördüm. Kayıtlar düzgün saklanıyordu ama cevap üretirken sistem bir düşüneyim… durup durup düşünüyormuş gibi davranıyordu — pek hoş değildi, kullanıcı deneyimi berbat. Sorunun yarısı modeldeydi elbette, öbür yarısı ise veriyi yanlış katmanda işlemeye çalışmamızdı.

Kaba kuvvet arama ölçek büyüdükçe can sıkıyor

Yaklaşım	Kayıt ekleme	Top-5 benzerlik arama	Bellek baskısı
SQLite + Python döngüsü	Makul	Yavaşlıyor	Yükseliyor
Nesneye özel vektör odaklı yapı	Makul / iyi	Daha akıcı	Daha kontrollü

Şahsen, Fark şu aslında: SQLite size depolama sunuyor ama vektör benzerliği için ekstra iş çıkartıyor (şaşırtıcı ama gerçek). Siz de üstüne bir — ki bu tartışılır — de Python tarafında cosine similarity hesaplayınca her şey zincirleme ağırlaşıyor. Siz ne dersiniz? Tek tek row çekmek tamam da on bin kayıt olunca bu yöntem biraz çorba oluyor.

Bir dakika — bununla bitmedi.

Kısacası: problem SQL’in kendisi değil… problem SQL’i uygun olmayan veri tipine zorla giydirmek.

Rust Tabanlı Yeni Yaklaşım Ne Vaat Ediyor?

Aslında, MoteDB gibi Rust ile yazılmış gömülü veritabanlarının iddiası tam burada başlıyor: veri modelini AI/robotik kullanımına göre kurmak. Yani tabloyu merkeze almak yerine fragment mantığına geçmek — embeddings ayrı, blob’lar ayrı, sayısal alanlar ayrı ve hepsi birlikte anlam taşıyor. Kulağa güzel geliyor, değil mi? (ben de ilk duyduğumda şaşırmıştım) React’te Dosya Yükleme: Sürükle-Bırak ve Önizleme yazımızda bu konuya da değinmiştik.

Bana kalırsa bunun en dayanıklı yani sadeleşme hissi veriyor olması (ciddiyim). Eskiden serileştirme kodu yazıp dururken insan kendini sanki muhasebe programı geliştiriyormuş gibi hissediyordu; şimdi ise doğrudan amaç odaklı bir yapı kuruluyor gibi duruyor — kağıt üstünde tabii, pratikte hâlâ pişmesi gereken taraflar var elbette.

Neden fragment fikri mantıklı?

• Daha az dönüşüm: Embedding’i JSON’a çevirip tekrar parse etmeye gerek kalmıyor. (bence en önemlisi)
• Daha net erişim: Ses klibi lazım mı? Onu çekiyorsun; diğer parçaları boşuna taşımıyorsun. (bu kritik)
• Daha doğal sorgu: Benzerlik hesabını doğrudan embedding üzerinden yapmak mümkün oluyor.
• Daha düşük glue code: Araya giren yardımcı kod miktarı azalınca bakım yükü hafifliyor. — ciddi fark yaratıyor

Burada kritik nokta şu: Rust’ın güvenlik modeli sadece dil seviyesinde avantaj sağlamıyor; embedded senaryoda belleği daha kontrollü kullanmak da önemli oluyor. Mesela cihaz tarafında RAM kıymetliyken her gereksiz kopya can sıkıyor, bunu deneyimle söylüyorum.

Küçük Startup İçin Başka, Kurumsal İçin Başka Hikâye Var

E tabi herkesin ihtiyacı aynı değil. Küçük bir startup için mesele çoğu zaman hızla ürün çıkarmak oluyor — mevcut araçlarla işi halletmek istiyorlar ve bunda yanlış yok kesinlikle. Bir MVP’de SQLite kullanmak hâlâ çok mantıklı olabilir; ekip küçük, operasyon basit, neden karmaşıklaştırasın ki? Daha fazla bilgi için 2026’nın Viral AI Sanat Trendleri: Prompt Yazmanın İncelikleri yazımıza bakabilirsiniz. Daha fazla bilgi için Freelance Pazarındaki Kargaşa Bitiyor mu?: Assignly Ne Vadediyor yazımıza bakabilirsiniz.

Ama enterprise tarafta sahne değişir. Kurumsal projede veri tipi çeşitleniyor, ölçek artıyor, gözlemleme ihtiyacı yükseliyor. Bir robot filosu düşünün: onlarca cihaz, binlerce anlık hafıza parçası, ses, görüntü, telemetri… Burada genel amaçlı çözüm bazen fazla genel kalabiliyor. Hani arabayla traktör işi görmeye çalışmak gibi — teoride araç araçtır, pratikte fark çok büyük.

Nerede hangisi daha mantıklı?

Küçük startup:
- Hızlı kurulum
- Az bağımlılık
- Basit şema
- Düşük operasyon maliyeti
Kurumsal/edge AI:
- Multimodal veri
- Vektör arama
- Daha az dönüşüm
- Cihaz üstünde düşük gecikme
}

Küçük bir detay: Bence karar çizgisi oldukça net: Uygulamanız metin ağırlıklıysa veya birkaç tabloda dönüyorsa eski dostunuz yeter. Ama robotik, sensör füzyonu, yerel yapay zekâ ya da RAG-benzeri bellek katmanı varsa özel tasarlanmış yapıların değeri artıyor. Geçen ay İzmir’de görüştüğüm bir ekip tam bunu tartışıyordu; bir gün sonra biri bana mesaj attı. “keşke bunu iki ay önce bilseydik” dedi — işte hayat böyle.

Peki Eksileri Yok mu? Var Tabii!

Aman dikkat. Bu tip yeni çözümleri överken ayağı yere basmak lazım. Her güzel fikir ilk bakışta cilalı görünür. Ekosistemi henüz ham olabilir, dokümantasyon eksik kalabilir, araç zinciri tam oturmamış olabilir. Ben açıkçası bu noktada biraz temkinliyim — heyecanlanıyorum evet,. Hemen production’a almadan önce iki kez düşünüyorum.

Beni düşündüren taraflar

• Ekosistem: SQLite kadar yaygın destek beklemek gerçekçi olmayabilir.
• Migrasyon: Mevcut uygulamayı taşımak sandığınızdan yorucu olabilir.
• Kenar durumlar: Sorgular büyüdükçe beklenmedik köşeler çıkabilir.
• Ekip alışkanlığı: Anlatması kolay olsa bile herkes hemen adapte olmaz.
• Tam olgunluk meselesi: Kâğıt üstünde süper görünen şey pratikte sürpriz çıkarabilir. (bu kritik)

Aynen öyle, ben de tam buraya takılıyorum. İyi çalışan yeni araç görmek heyecan verici; ama production’a alınca bakım hikâyesi başlıyor. Bugün hız kazandıran özellik yarın debugging kabusu olabilir — o yüzden test etmek şart. Maalesef.

Bazı zaman en iyi çözüm en havalı olan değildir. Sadece en az sürpriz çıkarandır. Bu cümle kulağa kuru geliyor olabilir ama gerçek dünya genelde böyle işliyor. Benim editör masasında öğrendiğim derslerden biri de bu: heyecan güzel, ölçülmüş iyilik daha güzel. KDE Linux: En Saf Plasma Deneyimi, Ama Küçük Bir Pürüz Var yazımızda da bu konuya değinmiştik. Signals, Effects ve Aralarındaki Matematik: Aljabr’a Yakından Bakış yazımızda da bu konuya değinmiştik.

“Sık Kullanılan Senaryo” Değil “Doğru Senaryo”

Aklımdaki ana mesaj şu: AI ajanları için bellek tasarlarken önce veri modelini düşünün, sonra teknoloji seçin (şaşırtıcı ama gerçek). Yani tersinden gitmeyin. Önce hangi bilgiyi hatırlamak istiyorsunuz? Sonra onu nasıl geri çağıracaksınız? Ve üçüncü soru: bu işlem kaç milisaniye gecikebilir? Bu üç soruyu yanıtlamadan teknoloji tartışması açmak biraz havanda su dövmek gibi oluyor (evet, doğru duydunuz)

Hedefiniz yerel çalışan, internetten kopuk, gizlilik hassasiyetine sahip bir sistemse Rust tabanlı gömülü yaklaşım oldukça cazip görünüyor. En çok da Raspberry Pi, mini PC ya da endüstriyel edge kutularında bu tür mimariler fena halde işe yarıyor. Ama masaüstünde başlayan ufak prototipi sırf yeni diye komple yeniden yazmak da gerekmeyebilir — bunu da söyleyeyim.

Sizin İçin Pratik Çıkarsamalar

Aslında, Laf uzamasın, birkaç net sonuç bırakayım:

1. Eğer yalnızca küçük metinsel kayıt tutuyorsanız, SQLite hâlâ güçlü aday.
2. Eğer multimodal bellek kuruyorsanız, veri modelinizi ona göre tasarlayın.
3. Eğer vektör arama yapacaksanız, her şeyi satır bazlı düşünmeyin.
4. Eğer edge donanımı kullanıyorsanız, RAM ve gecikme bütçesini baştan planlayın.

Şahsen, Bana sorarsanız asıl kazanım belirgin şekilde daha az glue code yazılması. Küçük detay gibi görünüyor ama büyük fark yaratıyor — entegrasyon kodu arttıkça hata payınız da artıyor, bunu sayısız projede gördüm (ki bu çoğu kişinin gözünden kaçıyor). Geçen hafta İstanbul’da yaptığım kısa testte sadece serileştirme katmanını azaltmanın bile debug süresini ciddi düşürdüğünü bizzat gözlemledim. Başlangıçta beklediğimden fazla uğraştırdı, hayal kırıklığı mı? Evet (şaşırtıcı ama gerçek). Ama sonunda resmin neden böyle olduğunu anlamak gerçekten faydalıydı.

Sıkça Sorulan Sorular

MoteDB ne işe yarıyor?

MoteDB, özellikle multimodal veriyi ve embedding tabanlı aramayı gömülü ortamda yönetmek için tasarlanmış görünüyor. Robotlar, edge cihazları ve yerel AI senaryolarında anlam kazanıyor.

SQLite tamamen terk edilmeli mi?

Hayır. Metinsel veri, basit konfigürasyonlar ve geleneksel CRUD işleri için hâlâ çok iyi. Konu vektör arama ve karmaşık medya parçaları olduğunda sınırı ortaya çıkıyor.

Küçük projede Rust tabanlı veritabanına geçmek mantıklı mı?

Eğer ihtiyaç gerçekten multimodalse evet, yoksa erken optimizasyon tuzağına düşebilirsiniz. Önce kullanım senaryosunu netleştirin, sonra karar verin.

Neden embedding’leri JSON olarak saklamak kötü fikir sayılıyor?

Saklamak mümkün, evet ; ama okuma-yazma sırasında fazladan serileştirme maliyeti oluşur. Ayrıca similarity search aşamasında gereksiz dönüşüm yapılmış olur.

Orijinal Yazının Kaynağı — moteDB Deneyimi

Rust GitHub Sayfası — Resmi Proje Alanları İçin Başlangıç Noktası)

SQLite Resmi Dokümantasyonu”>