VPS üzerinde SQLite kullanımı ve üretim ortamı ayarları

SQLite, bir VPS üzerinde ne zaman doğru üretim veritabanıdır

Bir VPS üzerinde üretim ortamında SQLite çalıştırmak, çoğu küçük uygulama için doğru tercihtir; nedeni basittir: tek bir makinede tek bir dosyaya yazan tek bir süreç, bir veritabanı sunucusuna ihtiyaç duymaz. Denetlenecek bir daemon, güvenlik duvarı ile korunacak bir port, değiştirilecek bir parola veya ayakta tutulacak ikinci bir makine yoktur. Bir sorgu, ağ üzerinden gidiş-dönüş yapmak yerine bir fonksiyon çağrısıdır; bu nedenle kırk sorgu çalıştıran bir sayfa size kırk fonksiyon çağrısına mal olur.

Maliyet sınırlı ve gerçektir. SQLite, tüm veritabanı dosyası üzerinde aynı anda tek bir yazma işlemine izin verir ve dosya iki makine arasında paylaşılamaz. Her iki sınırlama da tek bir uygulama çalıştıran tek bir VPS için uygundur. Ancak bu yapının dışına çıktığınız anda her iki sınırlama da ölümcüldür. Bu kılavuz, SQLite'ı bir sunucuda güvenli hale getiren ayarları, Litestream ile sürekli yedeklemeyi ve durmanız gereken noktayı ele almaktadır.

Önce komut satırı aracını yükleyin. Aşağıdaki her şey Ubuntu 24.04 üzerinde çalıştırılmıştır.

sudo apt update
sudo apt install -y sqlite3
sqlite3 --version

Bu komut, 3. ile başlayan bir sürüm, ardından bir derleme tarihi ve kaynak hash değeri yazdırır. Ubuntu 24.04, Ekim 2026 itibarıyla SQLite 3.45.1 sürümünü sunmaktadır. Uygulamanız muhtemelen bu binary dosyasını kullanmaz: çoğu dil çalışma zamanı, genellikle daha yeni olan kendi SQLite kütüphanesini paketler; bu nedenle yeni bir özelliğe güvenmeden önce veritabanı sürücünüzün bildirdiği sürümü kontrol edin.

WAL modunun neden ilk değiştirilmesi gereken ayar olduğu

SQLite varsayılan olarak bir rollback journal kullanır. Bir sayfayı değiştirmeden önce, orijinal sayfayı bir -journal dosyasına kopyalar ve ardından veritabanını yerinde düzenler. Bunu güvenli bir şekilde yapmak için tüm dosya üzerinde özel (exclusive) bir kilit alır; bu nedenle herhangi bir yazma işlemi sürerken tüm okuyucular bekler. Bir dizüstü bilgisayarda bunu kimse fark etmez. Bir web sunucusunda ise yavaş bir yazma işlemi, veritabanına erişen her isteği durdurur.

WAL (write-ahead log) modu bu sırayı tersine çevirir. Yazıcı, yeni sayfaları ayrı bir -wal dosyasına ekler ve ana veritabanına dokunmaz. Okuyucular ana dosyayı başladıkları andaki anlık görüntü (snapshot) üzerinden okumaya devam ederler; böylece okuyucular yazıcıyı, yazıcı da okuyucuları engellemez. Daha sonra bir checkpoint işlemi, biriken WAL sayfalarını ana veritabanına geri kopyalar. Bu tek değişiklik, SQLite'ın bir web uygulamasının arkasında kullanılabilir olmasını sağlayan temel unsurdur.

WAL modunu etkinleştirin ve kalıcı olduğunu doğrulayın

mkdir -p ~/app
sqlite3 ~/app/app.db "PRAGMA journal_mode=WAL;"

Komut wal çıktısını verir. Bu çıktı sadece bir süs değildir. PRAGMA journal_mode, veritabanının halihazırda bulunduğu modu döndürür; dolayısıyla delete yanıtı, değişikliğin başarısız olduğunu ve hala rollback journal modunda olduğunuzu gösterir.

WAL modu kalıcıdır. Bu, bir bağlantı ayarından ziyade veritabanı başlığındaki bir bayraktır; bu nedenle her veritabanı dosyası için bir kez çalıştırırsınız ve sonraki tüm bağlantılar, yeniden başlatma sonrasında bile bunu devralır. Bunu yeni bir bağlantı ile kanıtlayın.

sqlite3 ~/app/app.db "PRAGMA journal_mode;"

Şimdi bir tablo oluşturun ve diskte nelerin göründüğüne bakın.

sqlite3 ~/app/app.db <<'SQL'
CREATE TABLE IF NOT EXISTS notes (id INTEGER PRIMARY KEY, body TEXT NOT NULL);
INSERT INTO notes (body) VALUES ('first row');
SQL
ls -l ~/app/

Artık üç dosya var: app.db, app.db-wal ve app.db-shm. -wal dosyası, henüz checkpoint işlemi yapılmamış olan commit edilmiş sayfaları tutar. -shm dosyası, tüm bağlantıların WAL içeriği üzerinde mutabık kalması için eşlediği paylaşımlı bir bellek dizinidir. Her ikisi de veritabanına aittir ve geçici dosyalar değildir. Uygulama çalışırken sadece app.db dosyasını kopyalarsanız, yakın zamanda yapılan tüm commit işlemlerinin eksik olduğu bir dosya elde edersiniz. app.db dosyasını silip diğer ikisini yerinde bırakırsanız, SQLite bu eski WAL sayfalarını o isim altında beliren yeni dosyaya uygular; insanlar bir veritabanını sıfırlamaya çalışırken yeni bir veritabanını bu şekilde bozar.

Her üretim uygulaması için gereken bağlantı ayarları

Veritabanında yalnızca journal_mode saklanır. Aşağıdaki diğer tüm ayarlar bağlantı bazlıdır; bu da uygulamanızın, bir havuzun arka planda oluşturduğu her bağlantı dahil olmak üzere, açtığı her bağlantıda bu ayarları çalıştırması gerektiği anlamına gelir.

PRAGMA journal_mode = WAL;
PRAGMA busy_timeout = 5000;
PRAGMA synchronous = NORMAL;
PRAGMA foreign_keys = ON;

busy_timeout = 5000, SQLite'a kilitli bir veritabanı için database is locked hatası döndürmeden önce 5000 milisaniyeye kadar yeniden deneme yapmasını söyler. Varsayılan değer 0'dır, bu nedenle varsayılan olarak SQLite, iki yazma işlemi çakıştığında ilk seferde başarısız olur. Bu tek değeri ayarlamak, genellikle SQLite'ın kendisine atfedilen kilit hatalarının çoğunu ortadan kaldırır.

synchronous = NORMAL, WAL modunda doğru ayardır ve bu değiş tokuşun anlaşılması gerekir. FULL seviyesinde SQLite, her commit işleminde WAL üzerinde fsync çağrısı yapar. NORMAL seviyesinde ise senkronizasyonu kontrol noktalarında (checkpoint) gerçekleştirir. SQLite belgeleri, bu işlemden vazgeçtikleriniz konusunda nettir: Bir elektrik kesintisi veya ani bir yeniden başlatma sonrasında işlemler artık kalıcı (durable) değildir. Veritabanı bu güç kaybı nedeniyle bozulmaz, yalnızca diske ulaşmamış olan son commit işlemleri kaybolur. Bir VPS üzerinde bu genellikle doğru bir tercihtir, çünkü her yazma işleminin yolundan bir fsync yükünü kaldırır.

foreign_keys = ON, geriye dönük uyumluluk nedeniyle varsayılan olarak kapalıdır ve bağlantı bazlıdır. REFERENCES ifadeleriyle dolu bir şema, her bağlantı bu özelliği açana kadar hiçbir şeyi zorunlu kılmaz.

Yalnızca daha sonra önem kazanan bir ayar daha vardır. SQLite, WAL boyutu 1000 sayfayı aştığında otomatik olarak kontrol noktası oluşturur ve bu işlem, o anda işlemini tamamlayan herhangi bir bağlantı tarafından gerçekleştirilir. Bu durum kendi başına bir sorun teşkil etmez. Ancak Litestream çalışıyorsa, kontrol noktalarının ne zaman gerçekleşeceği üzerinde kontrol sahibi olmak istediği için bu bir soru işareti haline gelir.

busy_timeout ayarından sonra database is locked hatası neden devam eder

Bu hata, kullanıcıları Postgres kullanmaya yönelten temel sorundur ve tek bir spesifik nedeni vardır.

Busy timeout bir busy handler kurar ancak SQLite bunu her zaman çağıracağını garanti etmez.

SQLite, busy handler çağrılmasının kilitlenmeye (deadlock) yol açabileceğini tespit ederse, busy handler'ı çağırmak yerine uygulamaya doğrudan SQLITE_BUSY döner.

Kaçınılan bu kilitlenme, işlem (transaction) yükseltme sırasında gerçekleşir. SQLite'ta yalın bir BEGIN, BEGIN DEFERRED anlamına gelir. Eğer bu ifadeden sonraki ilk komut bir SELECT ise, okuma işlemi (read transaction) içindesiniz demektir. Aynı işlem içerisinde daha sonra gelen bir UPDATE, yazma işlemine dönüşmek zorunda kaldığında ve okumanız başladığından beri başka bir bağlantı yazma yaptıysa, SQLite sizi bekletemez. Çünkü snapshot'ınız zaten güncelliğini yitirmiştir ve beklemek, iki bağlantının birbirini kilitlemesine neden olur. Dokümantasyon sonucu doğrudan belirtir:

Sonraki yazma ifadeleri, mümkünse işlemi yazma işlemine yükseltir veya SQLITE_BUSY döner.

5000 milisaniyelik zaman aşımı süreniz hiçbir zaman dikkate alınmaz. Hata anında döner, bu yüzden ayarın hiçbir işe yaramadığı izlenimi oluşur.

Çözüm tek bir kelimedir.

BEGIN IMMEDIATE;
UPDATE notes SET body = 'edited' WHERE id = 1;
COMMIT;

BEGIN IMMEDIATE, herhangi bir okuma yapmadan önce yazma kilidini en başta alır. Yükseltme işlemi olmadığı için kaçınılması gereken bir kilitlenme de oluşmaz; bu nedenle busy handler devreye girer ve bağlantı hata vermek yerine sırasını bekler. Sadece okuma yapılan işlemleri deferred olarak bırakın. Yazma içeren her işlem immediate olmalıdır.

Kilit hatalarının ikinci nedeni tespit edilmesi daha zor olanıdır: yazma işlemini yavaş işlemler boyunca açık tutmak. SQLite yazıcıları sıraya koyar; bu nedenle bir işlem açan, ağ üzerinden harici bir API çağıran ve ardından commit eden bir yapı, o çağrı süresince diğer tüm yazıcıları engeller. İhtiyacınız olan veriyi okuyun, işlemi kapatın, yavaş olan işi yapın ve ardından sonucu kaydetmek için kısa bir yazma işlemi açın.

Litestream ile sürekli yedekleme

Gece yapılan bir kopyalama işlemi, bir güne kadar olan yazma işlemlerinin kaybına neden olur; canlı bir SQLite veritabanı üzerinde cp çalıştırmak ise açılamayan bir kopya oluşturabilir. İki yöntem güvenlidir. sqlite3 app.db ".backup /path/to/backup.db", SQLite'ın çevrimiçi yedekleme arayüzünü kullanır ve kullanımda olan bir veritabanı üzerinde çalışır. Litestream daha ileri gider: WAL dosyasını izler ve değişiklikleri sürekli olarak nesne depolama alanına gönderir; bu da en kötü durumdaki veri kaybınızı bir günden yaklaşık bir saniyeye indirir.

Litestream, uygulamanızın yanında çalışan tek bir Go ikili dosyasıdır. Uygulama ile veritabanı arasında konumlanmaz. Uygulamanız SQLite'a her zamanki gibi yazar, Litestream ise WAL dosyasını okur ve değişen kısımları yükler.

cd /tmp
curl -fsSL -O https://github.com/benbjohnson/litestream/releases/download/v0.5.14/litestream-0.5.14-linux-x86_64.deb
sudo dpkg -i litestream-0.5.14-linux-x86_64.deb
litestream version

v0.5.14, Ekim 2026 itibarıyla resmi Linux kurulum sayfasında belgelenen sürümdür. Daha yeni sürümler yayınlanmıştır: 21 Temmuz 2026'da v0.5.15 ve 31 Ağustos 2026'da en yeni etiket olan v0.5.17. Her iki satırdaki sürümü, yayın sayfasındaki güncel etiketle eşleşecek şekilde değiştirin; VPS'niz arm64 ise ilgili arm64 paketini kullanın.

Yapılandırma dosyası /etc/litestream.yml konumunda bulunur. Bulut kimlik bilgilerine ihtiyaç duymadan tüm döngüyü kanıtladığı için yerel bir dosya replikası ile başlayın.

dbs:
  - path: /home/appuser/app/app.db
    replica:
      type: file
      path: /var/backups/litestream/app

Alan adının tekil olan replica olduğuna dikkat edin. Litestream 0.5, 0.3 serisindeki replicas dizisini tek bir replica bloğu ile değiştirmiştir; iki girdi içeren bir yapılandırma başlangıçta hata verir. Birçok üçüncü taraf kılavuz hala eski diziyi göstermektedir, bu nedenle arama motorlarında çıkan ilk örneği değil, yukarıdaki yapıyı kopyalayın. 0.5 serisi ayrıca litestream wal alt komutunu litestream ltx olarak yeniden adlandırmıştır, çünkü disk üzerindeki yedekleme formatı değişmiştir.

Herhangi bir şeyi etkinleştirmeden önce yapılandırmanın ayrıştırıldığını doğrulayın.

sudo litestream databases -config /etc/litestream.yml

Ardından gidiş-dönüş işlemini manuel olarak kanıtlayın. Bu biçim, yapılandırma dosyasını atlar ve bir veritabanını bir yola replike eder.

mkdir -p /tmp/replica
litestream replicate ~/app/app.db file:///tmp/replica/app

Bu komut ön planda çalışır ve çalışmaya devam eder. İkinci bir kabukta bir satır yazın ve replikayı yeni bir dosyaya geri yükleyin.

sqlite3 ~/app/app.db "INSERT INTO notes (body) VALUES ('written after replication started');"
litestream restore -o /tmp/restored.db file:///tmp/replica/app
sqlite3 /tmp/restored.db "SELECT count(*) FROM notes;"

Sayım, yeni satırı içerir. İçermiyorsa, değişiklik henüz senkronize edilmemiştir: Litestream, varsayılan olarak 1 saniye olan bir sync-interval süresinde gönderim yapar, bu yüzden bekleyin ve tekrar geri yükleyin. O bir saniye aynı zamanda kurtarma noktanızdır. Bir çökme durumunda en fazla son senkronizasyon aralığındaki yazma işlemleri kaybolur ve hiçbir yapılandırma bunu sıfıra indiremez.

Gerçek depolama için replica bloğunu bir S3 URL'si ile değiştirin. Bu, Amazon S3 ve diğer sağlayıcıların S3 uyumlu nesne depolama hizmetleri ile çalışır.

dbs:
  - path: /home/appuser/app/app.db
    replica:
      url: s3://your-bucket-name/app
      region: us-east-1

snapshot:
  interval: 24h
  retention: 24h

Kimlik bilgilerini bu dosyada tutmayın. Litestream, LITESTREAM_ACCESS_KEY_ID ve LITESTREAM_SECRET_ACCESS_KEY değerlerini ortam değişkenlerinden okur, bu nedenle bunları root kullanıcısına ait ve 600 modundaki bir systemd drop-in dosyasına yerleştirin.

Yukarıdaki snapshot değerleri varsayılanlardır ve varsayılan saklama süresi (retention) kullanıcıları şaşırtabilir. Saklama süresi, Litestream'in snapshot'ları ve bunlara ait dosyaları ne kadar süre tutacağını belirler; bu da ne kadar geriye dönük geri yükleme yapabileceğinizi gösterir. Yirmi dört saat, Çarşamba sabahı fark ettiğiniz hatalı bir taşıma işleminin, Pazartesi günkü durumundan kurtarılamayacağı anlamına gelir. Litestream 0.5'te saklama süresi, replica bazlı değil, kök snapshot bloğundaki küresel bir ayardır. Bir hafta için bu bloğu retention: 168h olarak değiştirin ve ek depolama alanı için ödeme yapın. Replica bloğu içindeki bir retention: satırı, 0.3 serisi sözdizimidir. Litestream 0.5 bunu hata vermeden yok sayar ve 24 saatlik varsayılanda kalır.

Geri yükleme işlemini ihtiyaç duymadan önce doğrulayın

litestream restore -o /tmp/check.db /home/appuser/app/app.db
sqlite3 /tmp/check.db "PRAGMA integrity_check;"
sqlite3 /tmp/check.db "SELECT count(*) FROM notes;"

Bir veritabanı yolu verildiğinde, litestream restore komutu /etc/litestream.yml içindeki eşleşen kopyayı bulur ve indirir. PRAGMA integrity_check komutu, sağlam bir dosya üzerinde ok çıktısını verir; bunun dışındaki herhangi bir çıktı, geri yüklenen kopyanın kullanılamaz olduğunu gösterir. Bu işlemi bir systemd servisi ve zamanlayıcısı ile düzenli olarak çalıştırın ve çıktıları inceleyin. Bir yedeği başarıyla geri yükleyene kadar, yedeğin çalıştığından emin olamazsınız.

Litestream'i systemd altında çalıştırma

Debian paketi, /etc/litestream.yml dosyasını okuyan bir litestream birimi kurar.

sudo systemctl enable litestream
sudo systemctl start litestream
sudo journalctl -u litestream -f

Sağlıklı bir çıktı, yapılandırmadaki her veritabanını listeler ve ardından periyodik eşitleme satırları dışında sessiz kalır. Veritabanı yolunuzda no such file or directory hatası almanız, yapılandırmadaki yolun yanlış olduğu veya sürecin bu dosyayı okuyamadığı anlamına gelir. Birim varsayılan olarak root yetkileriyle çalışır; bu, söz konusu görev için gerekenden daha fazla ayrıcalıktır. Litestream, veritabanı dosyasıyla birlikte dizini de okuyup yazabilmelidir; çünkü veritabanınızın yanında -wal ve -shm dosyalarıyla işlem yapar. Bu nedenle, bu örneklerde appuser olarak belirtilen, uygulamanızın halihazırda çalıştığı kullanıcı hesabını atayın.

# /etc/systemd/system/litestream.service.d/override.conf
[Service]
User=appuser
Group=appuser

Bunu sudo systemctl daemon-reload ve sudo systemctl restart litestream ile uygulayın. En az ayrıcalığa sahip özel bir servis hesabı oluşturmak birkaç dakika sürer; bu, bir yedekleme aracısı ile sunucuda çalışan ikinci bir root süreci arasındaki farktır.

Makineyi sıfırdan yeniden oluşturmanız durumunda bir sıralama detayı önem kazanır. Uygulama başlamadan önce veritabanının geri yüklenmesini istersiniz. litestream restore, dosya zaten mevcut olduğunda 0 koduyla çıkan -if-db-not-exists parametresini kabul eder; bu nedenle her açılışta çalıştırılması güvenlidir. Bunu uygulamanızın birim dosyasındaki bir ExecStartPre satırına ekleyin; böylece yeni bir VPS veritabanını indirirken, mevcut olan hiçbir işlem yapmaz. Eğer her şeyi tek bir yerde tutmak isterseniz, litestream replicate aracının buna uygun bir -restore-if-db-not-exists bayrağı da mevcuttur.

SQLite'ın bir VPS üzerinde yetersiz kaldığı durumlar

Ağ dosya sistemleri. Bu, yapılandırma ile aşamayacağınız bir sınırdır. WAL modu, veritabanını kullanan her sürecin küçük bir bellek bölgesini paylaşmasını gerektirir; -shm dosyası da tam olarak bunu sağlar. SQLite belgeleri bu kuralı hiçbir istisna olmaksızın belirtir:

Bir veritabanını kullanan tüm süreçler aynı ana bilgisayar üzerinde olmalıdır; WAL, ağ dosya sistemi üzerinde çalışmaz.

Bu nedenle, mount edilmiş bir NFS (ağ dosya sistemi) veya SMB paylaşımı üzerindeki bir veritabanı bozulabilir ve hiçbir pragma bunu engelleyemez. Burada insanların gözden kaçırdığı bir ayrım vardır. Çoğu VPS sağlayıcısının ek depolama olarak bağladığı ağ tabanlı blok cihazları, Linux'a sıradan bir dosya sistemine sahip sıradan bir disk gibi görünür ve bu bir sorun teşkil etmez. Ancak mount edilmiş bir dosya paylaşımı böyle değildir.

İkinci bir uygulama sunucusu. Hiçbir ayar bunu çalışır hale getiremez. Aynı veriye hizmet veren iki makineye ihtiyaç duyduğunuz anda, ağ üzerinden konuşabilen bir veritabanına geçmeniz gerekir. Bu geçiş kararını, planlama yapmak için vaktiniz varken verin.

Yazma yoğunluklu iş yükleri. Aynı anda tek bir yazıcı (writer) olması, ayarlanabilir bir parametre değil, dosya biçiminin bir özelliğidir. Kısa yazma işlemleri maliyetsizdir çünkü her commit işlemi WAL dosyasına bir eklemedir; bu nedenle verim, CPU gücünüzden ziyade diskinizin küçük yazma gecikmesine bağlıdır. Bu farkın nasıl göründüğü hakkında bilgi için VPS üzerinde NVMe ve SATA SSD depolama karşılaştırması bölümüne bakın. Uzun süren işlemler asıl sorundur, çünkü diğer tüm yazma işlemlerini kuyruğa alırlar.

Analitik sorgular. SQLite, işlemler (transactions) için oluşturulmuş bir satır tabanlı depolama (row store) sistemidir. Yüz milyon satırı tarayan bir gösterge paneli, farklı bir araç gerektiren farklı bir iştir; Sunucu işlerinde DuckDB ve SQLite karşılaştırması bölümü bu sınırın nerede olduğunu açıklar.

Replikasyon altında VACUUM. Tam bir VACUUM işlemi tüm veritabanı dosyasını yeniden yazar; bu da Litestream'in dayandığı sayfa düzeyindeki takibi geçersiz kılar. Litestream belgeleri, replikasyon aktifken bu işlemin yerinde (in-place) çalıştırılmamasını tavsiye eder. Bunun yerine, sıkıştırılmış bir kopyayı ayrı bir dosyaya yazan ve orijinal dosyaya dokunmayan VACUUM INTO komutu önerilir. Eğer yerinde vacuum yapmanız gerekiyorsa, izlenmesi gereken prosedür bir yeniden başlatmadan daha uzundur: replikatörü durdurun, vacuum işlemini yapın, veritabanının yanındaki Litestream gizli takip dizinini ve mevcut uzak replika verilerini silin, ardından replikatörü yeniden başlatarak yeni bir tam snapshot ile başlamasını sağlayın. Bu son adım, sahip olduğunuz geri yükleme geçmişini siler.

Tek bir veritabanı üzerinde iki replikatör. Asla aynı veritabanı veya aynı replika hedefi üzerinde iki Litestream süreci çalıştırmayın. Belgeler, bunu önlemenin sizin sorumluluğunuz olduğunu açıkça belirtir; aksi takdirde geri yükleyemeyeceğiniz bir replika ile karşılaşırsınız.

Litestream'in kapsamadığı durumlar

Litestream yalnızca veritabanı dosyasını korur, başka hiçbir şeyi değil. Yüklenen dosyalar, uygulama yapılandırması, TLS (transport layer security) sertifikaları ve unit dosyalarının yönetimi tamamen sizin sorumluluğunuzdadır. Bunu, restic kullanarak şifreli ve sunucu dışı yedekleme ile belirli bir takvime göre eşleştirirseniz her iki tarafı da güvence altına almış olursunuz. Eğer makine yeniyse, yeni bir VPS üzerinde ilk on dakika rehberi, bu kılavuzda halihazırda yapıldığı varsayılan kullanıcı hesabı ve güvenlik duvarı işlemlerini kapsar.

FAQ

SQLite üretim ortamındaki bir uygulama için yeterli midir?

Tek bir sunucuda çalışan tek bir uygulama için, WAL modunu etkinleştirdiğiniz, bir busy timeout süresi belirlediğiniz ve sürekli yedekleme yaptığınız sürece evet. Önemli olan yapısal sınırlar şunlardır: aynı anda tek bir yazıcı ve tek bir ana makine. Bu sınırlar dahilindeki bir uygulama, ağ trafiği veya izlenmesi gereken ayrı bir süreç gerektirmeyen bir veritabanına sahip olur. Bu sınırlara uymayan bir uygulama ise istemci-sunucu mimarisinde bir veritabanına ihtiyaç duyar ve hiçbir optimizasyon bunu değiştiremez.

busy_timeout ayarını yapmama rağmen neden hala database is locked hatası alıyorum?

Çünkü SQLite, beklemenin kilitlenmeye (deadlock) yol açabileceği durumlarda busy handler mekanizmasını atlar. Doğrudan BEGIN ile başlayan bir işlem ertelenmiş (deferred) kabul edilir: bir açılış SELECT komutu işlemi bir okuma işlemine sokar ve daha sonraki bir yazma işlemi yükseltme gerektirir. Eğer bu sırada başka bir bağlantı yazma işlemi gerçekleştirirse, okuma anlık görüntünüz (snapshot) geçersiz kaldığı için SQLite, busy handler'ı çağırmak yerine doğrudan SQLITE_BUSY hatasını döndürür. Yazma işlemi yapacak her türlü işlemi BEGIN IMMEDIATE ile başlatın; böylece yazma kilidi en başta alınır ve zaman aşımı süresi geçerli olur.

SQLite veritabanımı ağ depolama biriminde tutabilir miyim?

NFS veya SMB gibi ağ dosya sistemlerinde tutulamaz. WAL modu, tüm süreçlerin -shm dosyası üzerinden belleği paylaşmasını gerektirir ve SQLite belgeleri, veritabanını kullanan her sürecin aynı ana bilgisayarda olması gerektiğini belirtir. Sağlayıcınız tarafından bağlanan bir ağ blok aygıtı (network block device) farklı bir durumdur: Linux bunu normal bir dosya sistemine sahip normal bir disk olarak görür ve SQLite burada çalışır.

Zaten günlük yedekleme yapıyorsam Litestream kullanmama gerek var mı?

Bu, ne kadar veri kaybını göze alabileceğinize bağlıdır. Günlük bir yedekleme işi, yirmi dört saate kadar olan yazma işlemlerini kaybetmek anlamına gelir. Litestream saniyede yaklaşık bir kez eşitleme yapar, bu nedenle bir çökme durumunda yaklaşık son bir saniyelik veriyi kaybedersiniz. Ayrıca, veritabanını yazma işlemi sırasında kopyalayabilen cp komutu ile dosya kopyalamaktan daha güvenlidir. Litestream yalnızca veritabanını kapsar, bu nedenle yanında genel bir dosya yedekleme sistemi çalıştırmaya devam edin.