SQLite Üretim Ortamında: Küçük ve Orta Ölçekli Projeler İçin Ne Zaman Yeterli?
SQLite Üretim Ortamında: Küçük ve Orta Ölçekli Projeler İçin Ne Zaman Yeterli?
Bir web projesine başlarken neredeyse refleks hâline gelmiş bir adım vardır: PostgreSQL ya da MySQL kur, bağlantı bilgilerini ayarla, bir de ORM ekle. Oysa okuduğunuz bu site dahil pek çok üretim sistemi, tek bir dosyadan ibaret olan SQLite ile yıllardır sorunsuz çalışıyor. Bu yazıda "SQLite oyuncak veritabanıdır" önyargısını kendi deneyimlerimle birlikte masaya yatırıyorum: gerçekte ne kadarını kaldırır, hangi ayarlarla kaldırır ve ne zaman gerçekten daha büyük bir sisteme geçmek gerekir.
SQLite'ın asıl gücü: ortadan kalkan her şey
SQLite bir sunucu değil, uygulamanızın içine gömülen bir kütüphanedir. Bu tek cümlenin pratik sonuçları büyüktür:
- Kurulum yok. Veritabanı, diskteki tek bir
.dbdosyası. Yeni sunucuya taşınmak, dosyayı kopyalamaktan ibaret. - Bağlantı yönetimi yok. Ağ gecikmesi, bağlantı havuzu, "connection refused" hataları — bunların hiçbiri yok; sorgu doğrudan dosyaya gider.
- Yedekleme basit. Dosyayı kopyalayın (doğru yöntemle — aşağıda), yedek hazır.
- Sıfır bakım. Güncellenecek, yeniden başlatılacak, izlenecek ayrı bir servis yok.
Küçük bir ekip ya da tek kişilik bir proje için bu, haftada saatlerce operasyon işinden kurtulmak demektir. Sunucumda PostgreSQL süreci yerine yalnızca Node.js süreci çalışıyor; izlemem gereken tek şey uygulamanın kendisi.
Sınırları dürüstçe konuşalım
SQLite'ın mimari bir sınırı vardır: aynı anda yalnızca bir yazıcı. Okumalar paralel çalışabilir, ama yazma işlemleri sıraya girer. Bunun pratikteki anlamı şudur:
- Okuma ağırlıklı siteler (blog, portfolyo, haber, katalog) için bu sınır neredeyse hiç hissedilmez. Bu sitenin trafiği de büyük oranda okumadır: paylaşım görüntülenir, proje sayfası açılır, arada bir yorum yazılır.
- Saniyede yüzlerce eşzamanlı yazma gerektiren sistemlerde (yoğun mesajlaşma, gerçek zamanlı analitik toplama) SQLite zorlanır.
İkinci sınır dağıtıklıktır: veritabanı tek dosyaysa, uygulamanızın da o dosyayla aynı makinede olması gerekir. Birden çok uygulama sunucusunun aynı veritabanına yazdığı mimarilerde SQLite doğru araç değildir.
Üretim için olmazsa olmaz: WAL modu
SQLite varsayılan ayarlarıyla değil, WAL (Write-Ahead Logging) moduyla üretime çıkmalı. Klasik modda bir yazma işlemi tüm okumaları bekletir; WAL modunda ise okuyucular yazarken bile eski tutarlı görüntüyü okumaya devam eder.
PRAGMA journal_mode = WAL;
PRAGMA busy_timeout = 5000;
PRAGMA synchronous = NORMAL;
journal_mode = WALbir kez ayarlanır, dosyada kalıcıdır.busy_timeout, "database is locked" hatasının ilacıdır: kilit doluysa hemen hata fırlatmak yerine 5 saniyeye kadar bekler. Node.js gibi eşzamanlı isteklerin geldiği ortamlarda bunu ayarlamamak, ilk trafik dalgasında kilitlenme hatalarıyla tanışmak demektir.synchronous = NORMAL, WAL ile birlikte güvenli kabul edilen ama yazma hızını belirgin artıran bir denge noktasıdır.
Bu üç satır, benim "keşke ilk gün bilseydim" listemin başındadır.
Yedekleme: dosyayı kopyalamak yetmez (ama az kalır)
Çalışan bir veritabanı dosyasını copy ile almak, tam yazma anına denk gelirseniz bozuk bir yedek üretebilir. Doğru yöntemler:
-- SQLite 3.27+ ile tek komutluk tutarlı yedek:
VACUUM INTO '/yedekler/site-2026-06-16.db';
# veya komut satırından canlı yedek:
sqlite3 database.db ".backup '/yedekler/site.db'"
İki yöntem de devam eden işlemleri bozmadan, tutarlı bir kopya üretir. Benim kurulumumda gece görevi (cron) her gün VACUUM INTO ile tarihli yedek alır ve yedi günden eskileri siler. Veritabanı birkaç yüz MB iken bu işlem saniyeler sürer.
İndeks: en ucuz performans iyileştirmesi
SQLite hızlıdır, ama indekssiz bir sorgu her satırı tek tek tarar. Hangi sorguların tablo taraması yaptığını görmek için:
EXPLAIN QUERY PLAN
SELECT * FROM shares WHERE category = 'Programlama' ORDER BY created_at DESC;
Çıktıda SCAN shares görüyorsanız indeks eksiktir:
CREATE INDEX idx_shares_category_date ON shares(category, created_at DESC);
Kendi sitemde paylaşım listeleme sorgusu, kayıt sayısı arttıkça yavaşlamaya başlamıştı; doğru bileşik indeksle sorgu süresi milisaniyenin altına indi. Kural basit: WHERE ve ORDER BY'da birlikte kullandığınız sütunlar, birlikte indekslenmeli.
Şema değişiklikleri ve göçler (migrations)
SQLite'ın ALTER TABLE desteği sınırlıdır (sütun ekleme kolay, sütun silme/değiştirme dolambaçlı). Küçük projelerde karmaşık bir migration aracı yerine şu pragmatik desen yeterli olur:
// Açılışta: sütun yoksa ekle, varsa sessizce geç
db.run("ALTER TABLE shares ADD COLUMN view_count INTEGER DEFAULT 0", () => {});
Daha düzenli bir yaklaşım isterseniz, PRAGMA user_version ile veritabanına bir sürüm numarası yazıp açılışta sıralı göç dosyaları çalıştırabilirsiniz. Önemli olan ilkedir: şema değişikliği koddan, elle değil. Elle değiştirilen üretim şeması, er ya da geç geliştirme ortamından sapar.
Ne zaman PostgreSQL'e geçmeli?
Şu işaretlerden birkaçı aynı anda beliriyorsa geçiş vaktidir:
- Yazma trafiği sürekli ve yoğunsa (kilit bekleme süreleri loglarda görünmeye başladıysa),
- Birden fazla uygulama sunucusuna ölçeklenmeniz gerekiyorsa,
- Satır düzeyi yetkilendirme, gelişmiş tam metin arama, JSON sorguları gibi motor özelliklerine ihtiyaç duyuyorsanız,
- Veritabanı boyutu onlarca GB'a dayandıysa ve analitik sorgular ağırlaştıysa.
Buraya kadar gelmediyseniz, geçiş çoğu zaman erken optimizasyondur. Benim tavsiyem: SQL'inizi standartlara yakın tutun (SQLite'a özel numaralardan kaçının), böylece gün geldiğinde taşınmak sancısız olur.
Sonuç
SQLite "gerçek projeler için yetersiz" değildir; doğru sınıf problem için en az dertli çözümdür. Tek sunucuda çalışan, okuma ağırlıklı, küçük-orta ölçekli bir web uygulamasında WAL modu, makul indeksler ve düzenli VACUUM INTO yedekleriyle SQLite, üzerine düşeni sessizce yapar — bu sitenin yıllardır yaptığı gibi. Veritabanı seçiminde dogma yerine iş yüküne bakın: en iyi veritabanı, sizi geceleri uyandırmayandır.
Ek Görseller
