SQLite Ne Zaman Kullanılır? Kullanım Alanları ve Sınırları

Asıl Soru

SQLite, Postgres'in küçük bir versiyonu değil. Tamamen farklı bir araç. Veritabanının tamamı disk üzerinde tek bir dosya ve uygulamanız bu dosyayla aynı süreç içine bağlanan bir kütüphane üzerinden konuşuyor — sunucu yok, ağ yok, kullanıcı yönetimi yok. Bu tasarım SQLite'ı bazı işler için müthiş, bazıları için ise tam bir kâbus yapıyor.

Karar verirken sorulması gereken soru neredeyse hiçbir zaman "SQLite yeterince hızlı mı?" değil (genelde hızlı). Asıl soru şu: "Uygulamamın şekli SQLite'ın iyi olduğu işlere uyuyor mu?" Bunu da temelde iki şey belirliyor: verinin nerede durduğu ve aynı anda kaç farklı yerden yazıldığı.

SQLite'ı Veri Uygulamayla Birlikte Yaşadığında Kullanın

SQLite, veritabanı tek bir makinedeki tek bir uygulamaya ait olduğunda parlıyor. Dosya kodunuzun yanında duruyor, uygulamanız onu doğrudan açıyor ve mimarinizin tamamı bundan ibaret.

-- Tipik bir "veri uygulamayla birlikte yaşar" şeması:
-- bir masaüstü not alma uygulamasının yerel deposu.
CREATE TABLE notes (
    id        INTEGER PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT,
    created   TEXT DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO notes (title, body) VALUES
    ('Market Alışverişi', 'süt, ekmek, kahve'),
    ('Fikirler',          'sqlite eğitim taslağı');

SELECT id, title, created FROM notes;

Bu küçücük şema, gerçek bir uygulamanın komple backend'i bile olabilir. Bu yaklaşımın doğal olarak oturduğu birkaç senaryo:

• Masaüstü ve mobil uygulamalar. Yapısal yerel depolama isteyen her iOS ve Android uygulaması arka planda SQLite kullanıyor. Firefox, Chrome ve tarayıcıların çoğu da öyle.
• CLI araçları. git, paket yöneticileri ve dotfile yöneticileri gömülü veritabanlarıyla çalışır.
• Gömülü cihazlar. Router'lar, arabalar, uçaklar — birkaç yüz kilobayt alana sığacak bir veritabanı isteyen her şey.
• Test suite'leri. Her test için sıfırdan bir SQLite dosyası (ya da :memory: veritabanı) açmak, Postgres ayağa kaldırmaktan hem daha hızlı hem daha izole.

Verinizin birden fazla makine arasında paylaşılmasına ihtiyaç yoksa, doğru cevap büyük ihtimalle SQLite'tır.

Okuma Ağırlıklı Web Siteleri için SQLite Kullanımı

SQLite, okuma işlemlerinde harikadır. Çok sayıda eşzamanlı okuyucu, sıfır çakışma, indeksli sorgularda mikrosaniyelik yanıt süreleri. Sitenizde insanlar çoğunlukla içerik okuyorsa — bloglar, dokümantasyon, tanıtım siteleri, küçük SaaS dashboard'ları — SQLite gayet iyi iş çıkarır. Hatta ağ üzerinden bağlanan bir Postgres'e göre çoğu zaman daha iyi performans verir, çünkü ortada gidip gelen bir network round-trip'i yoktur.

-- Bir blogun gönderiler tablosu.
CREATE TABLE posts (
    slug      TEXT PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT NOT NULL,
    published TEXT
);

CREATE INDEX idx_posts_published ON posts(published DESC);

INSERT INTO posts VALUES
    ('hello-world', 'Merhaba, Dünya', 'İlk gönderi.', '2024-01-01'),
    ('sqlite-rocks', 'Neden SQLite',  'Tek dosyalı veritabanı.', '2024-02-15');

SELECT slug, title FROM posts ORDER BY published DESC LIMIT 10;

İşin püf noktası yazma işlemlerinde. SQLite yazma işlemlerini sıraya sokar — kilidi aynı anda yalnızca tek bir yazıcı tutabilir. Birkaç yazarın olduğu bir blogda bunu hissetmezsiniz bile. Ama her saniye binlerce kullanıcının mesaj attığı bir sohbet uygulamasında bu ciddi bir darboğaza dönüşür.

WAL modu (write-ahead logging, ileride değineceğiz) okuyucularla yazıcının paralel çalışmasına izin verdiği için bu tavanı epey yukarı çeker. SQLite + WAL ile günde milyonlarca istek karşılayan production siteleri hiç de az değil.

Yerel Önbellek ve Geçici Veriler için SQLite

Ne zaman yapılandırılmış bir yerel depolamaya ihtiyacınız olsa — JSON dosyasından fazlasını ama tam teşekküllü bir veritabanı sunucusundan azını istediğinizde — SQLite'ın önüne geçmek zordur.

-- HTTP istemcisi için bir önbellek tablosu.
CREATE TABLE http_cache (
    url        TEXT PRIMARY KEY,
    body       BLOB NOT NULL,
    expires_at INTEGER NOT NULL
);

INSERT INTO http_cache (url, body, expires_at)
    VALUES ('https://api.example.com/users/1', x'7b2269...', 1735689600);

DELETE FROM http_cache WHERE expires_at < strftime('%s', 'now');
SELECT count(*) FROM http_cache;

Loglar, analitik buffer'ları, ETL staging tabloları, makine öğrenmesi feature store'ları, IDE indeksleri... Bunların hepsi SQLite'ın doğal yaşam alanı. Dosya taşınabilir, sorgu dili tam anlamıyla SQL ve başında bekleyeceğiniz bir sunucu yok.

SQLite eşzamanlı yazma gerektiren senaryolarda kullanılmamalı

İşte insanları en çok tökezleten sınırlama bu. SQLite veritabanı seviyesinde yazma kilidi kullanır: aynı anda tek bir yazıcı, nokta. İki process aynı anda insert yapmaya kalkarsa, biri sıraya girmek zorunda.

Çoğu uygulamada bu hiç sorun değil — yazma işlemleri seyrek ve hızlı oluyor. Ama iş yüküniz şuna benziyorsa:

• Binlerce kullanıcının aynı anda yazma yaptığı multi-tenant bir SaaS,
• Yüksek hacimli bir mesaj kuyruğu veya event log,
• Sürekli state değişikliği olan gerçek zamanlı bir oyun veya chat backend'i,

o zaman SQLite size darboğaz olur. PostgreSQL ve MySQL satır seviyesinde kilitleme kullanıyor ve tam olarak bu tür senaryolar için tasarlandılar. Bu durumlarda onlara yönelin.

-- Yazarlar üst üste biriktiğinde göreceğiniz hata:
Hata: veritabanı kilitli

Normal yük altında bunu yaşıyorsanız sorun SQLite'ta değil; SQLite zaten yanlış araç demektir — geçiştirilecek bir bug değil bu.

SQLite'ı Birden Fazla Makinede Kullanmayın

SQLite, uygulamanın içinde çalışan (in-process) bir kütüphanedir. Uygulama, dosyayı doğrudan okur ve yazar; yani dosyanın, uygulamanın normal dosya sistemi çağrılarıyla read() ve write() yapabildiği bir diskte olması gerekir.

Bu da şunları eler:

• Yük dengeleyici arkasındaki birden fazla uygulama sunucusunun tek bir veritabanını paylaşma senaryosu. (NFS gibi ağ dosya sistemleri teknik olarak çalışır ama yük altında dosyayı bozar. Bulaşmayın.)
• Serverless fonksiyonlar — her çağrı farklı bir makinede koşuyor olabilir.
• Ortak bir veritabanına ihtiyaç duyan Kubernetes pod'ları — tek pod + persistent volume kurulumu yapmıyorsanız tabii.

Mimarinizde birden fazla makinede, birden fazla süreç veritabanına yazıyorsa, istemci-sunucu mimarili bir veritabanına geçmeniz gerekir. Sınır tam burası.

Veritabanı Düzeyinde Kullanıcılara İhtiyaç Duyduğunuzda SQLite Kullanmayın

SQLite'ta kullanıcı, rol veya yetki kavramı yoktur. Veritabanı dediğimiz şey bir dosya — dosyayı okuyabilen her şeyi okur, yazabilen her şeyi yazar. Erişim kontrolü işletim sisteminin görevidir.

Tek kullanıcılı bir masaüstü uygulaması için bu yeterli. Ama farklı kişilerin veritabanı içinde farklı yetkilere sahip olması gereken çok kiracılı (multi-tenant) bir sistem kuruyorsanız, Postgres ya da MySQL'e bakın.

Hızlı Karar Listesi

Şu listeyi tek tek geçin. Hepsine "evet" diyorsanız SQLite muhtemelen harika bir seçim:

• Veritabanı, uygulamayla aynı makinede duruyor.
• Veritabanına tek bir süreç (ya da çoğu okuma yapan birkaç süreç) erişiyor.
• Toplam veri tek bir diske rahatça sığıyor — terabaytlar sorun değil ama yine de tek disk.
• Veritabanı düzeyinde kullanıcı yetkilerine ihtiyacınız yok.
• Eşzamanlı yazma işlemleri ara sıra oluyor, asıl iş yükünüz bu değil.

Cevaplardan biri bile "hayır" ise Postgres veya MySQL'e yönelin. Sonraki iki sayfada bu ikisini doğrudan karşılaştıracağız.

Cebinize Koyacaklarınız

• SQLite, veritabanının uygulamayla aynı yerde yaşadığı durumlarda doğru tercih: masaüstü, mobil, gömülü sistemler, CLI araçları, test paketleri, okuma ağırlıklı siteler, yerel önbellekler.
• Production'a uygundur — milyarlarca cihazda SQLite yüklü geliyor. Kısıtlar kalite meselesi değil, mimari meselesidir.
• Çok sayıda eşzamanlı yazıcıya, çok makineli erişime veya kullanıcı bazlı veritabanı yetkilerine ihtiyacınız varsa atlayın.

Sıradaki: SQLite Kurulumu

Teori bu kadar yeter. Sonraki sayfada SQLite'ı makinenize nasıl kuracağınızı adım adım göreceğiz — macOS ve çoğu Linux dağıtımında zaten yüklü, Windows'ta tek bir indirme yetiyor — ardından komut satırından kurulumu doğrulayacağız.