SQLite vs MySQL: Hangi Veritabanını Seçmeli?

Veritabanının İki Farklı Hâli

SQLite ve MySQL ikisi de SQL konuşur, ikisi de verileri tablolarda satır satır tutar; ama bir sisteme nasıl oturdukları taban tabana farklıdır. SQLite bir kütüphanedir — uygulamanız onu içine alır (link eder) ve diskteki bir dosyadan okur. MySQL ise bir sunucudur — soket ya da ağ üzerinden bağlandığınız ayrı bir süreçtir.

İşte bu tek fark, geri kalan her şeyi belirliyor: nasıl kurulduklarını, aynı anda kaç yazıcının çalışabileceğini, yedeklemenin nasıl yapıldığını, deploy süreçlerini... SQLite mi MySQL mi sorusunun arkasında aslında çoğu zaman gömülü (embedded) mi yoksa istemci-sunucu (client-server) mimari mi tartışması yatar.

-- SQLite: bir dosya aç, artık bir veritabanın var.
sqlite3 app.db

-- MySQL: çalışan bir sunucuya bağlan.
mysql -h localhost -u root -p

SQLite komutu bir dosyayı açar (ya da yoksa oluşturur). MySQL komutu ise zaten çalışıyor, yapılandırılmış ve girişlere izin veren bir sürece bağlantı açar.

Mimari: Gömülü mü, istemci-sunucu mu?

SQLite ile yazılmış bir uygulamada veritabanı motoru doğrudan programınızın içinde çalışır. Port yok, daemon yok, systemctl start yok. Bir sqlite3 kütüphane çağrısı, diskteki dosyadan sayfaları okuyup yazar — o kadar.

MySQL'de ise işler tam tersi. Veriyi mysqld sunucusu tutar; bağlantıları yönetir, yetkileri uygular, sorgu planlayıcısını çalıştırır ve kilitlemeyi üstlenir. Sizin uygulamanız bir istemcidir; SQL metinlerini ağ üzerinden gönderir, karşılığında sonuç satırlarını alır.

Bunun pratikteki sonuçları şöyle:

• Dağıtım. SQLite uygulamanızla birlikte gelir — tek binary, tek dosya. MySQL için ayrı bir sunucu kurmanız, güvenliğini sağlamanız, izlemeniz ve yedeklemeniz gerekir.
• Ağ erişimi. MySQL bir port açar; böylece birden fazla uygulama sunucusu aynı veritabanına bağlanabilir. SQLite ise tek bir süreç (ya da aynı makinede iş birliği yapan birkaç süreç) varsayar.
• Yetkiler. MySQL'de kullanıcılar, roller ve GRANT ifadeleri vardır. SQLite'ta tek yetki mekanizması, veritabanı dosyasının işletim sistemi izinleridir.

Hiçbiri diğerinden "daha iyi" değil. Farklı problemleri çözüyorlar.

Eşzamanlılık ve yazma işlemleri

İki veritabanının asıl ayrıştığı yer burası. MySQL'in InnoDB motoru satır seviyesinde kilitleme yapar — birçok bağlantı, birbirini bloklamadan farklı satırlara aynı anda yazabilir.

SQLite ise yazma işlemlerini veritabanı seviyesinde sıraya sokar. Aynı anda yalnızca tek bir yazar olabilir, nokta. Okuyucular yazarla birlikte çalışabilir (özellikle WAL modunda), ama ikinci bir yazar sırasını beklemek zorundadır.

-- SQLite: aynı anda birçok okuyucu, tek yazıcı için sorunsuz çalışır.
PRAGMA journal_mode = WAL;

-- MySQL: birçok yazıcı, ince ayrıntılı kilitleme.
-- (Özel kurulum gerekmez — InnoDB bunu varsayılan olarak yapar.)

Tek ya da iki süreçle ölçülü yazma yapan uygulamalar için — masaüstü araçlar, mobil uygulamalar, küçük bir CMS — SQLite'ın seri yazma davranışı genelde fark bile etmeyeceğiniz kadar hızlıdır. Ama yüzlerce bağlantının aynı anda sipariş eklediği, oturum güncellediği yoğun bir web servisinde MySQL'in satır bazlı kilitlemesi, "her şey yolunda" ile "her şey tek bir kilidin arkasında kuyruğa girmiş" arasındaki farkı belirler.

Veri Tipleri

MySQL'in uzun ve katı bir tip listesi vardır: TINYINT, INT, BIGINT, VARCHAR(n), DATETIME, DECIMAL(p,s), BLOB, JSON ve dahası. Bir sütunu INT olarak tanımladığınızda MySQL oraya string yazmanıza izin vermez.

SQLite ise bunun yerine tip yakınlığı (type affinity) kullanır. Sütun tipleri kuraldan çok birer ipucudur, zorlayıcı değildir. INTEGER tanımlı bir sütuna string koyabilirsiniz; SQLite bunu sorunsuz saklar (3.37 sürümüyle gelen STRICT tabloları açıkça tercih etmediğiniz sürece).

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    name TEXT,
    price REAL
);

INSERT INTO products (name, price) VALUES ('Kahve', 3.50);
INSERT INTO products (name, price) VALUES ('Çay', '2.75');  -- REAL sütununda string

SELECT id, name, price, typeof(price) FROM products;

Her iki satır da sorunsuz şekilde eklenir. Bu esneklik prototip aşamasında işinizi kolaylaştırır, ama veritabanı seviyesinde tip güvenliği bekliyorsanız sizi şaşırtabilir. SQLite'ta MySQL tarzı katı kontrol istiyorsanız STRICT tabloları kullanın.

Pratikte Karşılaşacağınız Söz Dizimi Farkları

Temel SQL'in büyük kısmı — SELECT, JOIN, WHERE, GROUP BY — iki tarafta da aynı. Farklar birkaç noktada toplanıyor:

• Otomatik artan birincil anahtarlar. SQLite'ta INTEGER PRIMARY KEY kullanılır (varsayılan olarak otomatik artar). MySQL'de ise INT AUTO_INCREMENT PRIMARY KEY yazılır.
• String tırnaklama. MySQL, tanımlayıcılar için ters tırnağa izin verir (`table`). SQLite ise SQL standardına uyar ve çift tırnak kullanır ("table").
• Tarih fonksiyonları. MySQL'de NOW(), CURDATE(), DATE_ADD() var. SQLite'ta bunların karşılığı datetime('now'), date('now') ve datetime('now', '+1 day') şeklinde.
• LIMIT söz dizimi. İkisi de LIMIT n OFFSET m destekliyor, yani bu konuda sorun yok.
• Boolean değerler. MySQL'de BOOLEAN var (aslında TINYINT(1) için bir takma ad). SQLite ise boolean'ları INTEGER sütunlarında 0 ve 1 olarak tutar.

-- MySQL
CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    created_at DATETIME DEFAULT NOW()
);

-- SQLite
CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    created_at TEXT DEFAULT (datetime('now'))
);

Aynı amaç, farklı anahtar kelimeler. Zihinsel model olduğu gibi geçerli; sadece sözdiziminde ufak ayarlamalar gerekiyor.

Performans: Cevap Soruya Bağlı

"SQLite, MySQL'den daha mı hızlı?" sorusunun tek bir cevabı yok.

Yerelde okuma ve yazma yapan tek bir süreç söz konusuysa SQLite çoğu zaman daha hızlıdır — ortada ne ağ atlaması, ne süreçler arası iletişim, ne de ayrı bir adres alanında çalışan sorgu çözümleyici var. SQLite'taki bir SELECT, neredeyse bir fonksiyon çağrısı kadar basittir.

Aynı veritabanına yazan çok sayıda eşzamanlı bağlantı söz konusu olduğundaysa MySQL satır seviyesinde kilitleme sayesinde öne geçer. SQLite'ın tek yazar modeli, bu tür yüklerde çekişmenin hızla baş göstermesine yol açar.

Okuma ağırlıklı yüklerde ve WAL modu açıkken SQLite şaşırtıcı derecede iyi ölçeklenir — okuyucular ne birbirini ne de tek yazarı bloklar. Gerçek trafiği SQLite üzerinden hizmet veren bir sürü production sitesi var.

İnternette okuduğunuz benchmark'lara bakarak karar vermeyin. Kendi gerçek erişim deseninize bakarak karar verin.

Hangisini Ne Zaman Seçmeli?

Şu durumlarda SQLite'a yönelin:

• Veritabanı tek bir uygulamanın yanında yaşıyorsa (mobil uygulama, masaüstü aracı, CLI, küçük bir web sitesi).
• Sıfır yapılandırmayla dağıtım istiyorsanız — tek bir dosyayı göndermek yetiyor.
• Okumalar yazmaları açık ara geçiyorsa veya yazmalar çok seyrekse.
• Production'daki SQL'i birebir taklit eden gömülü bir test veritabanına ihtiyacınız varsa.
• Prototip aşamasındaysanız ve henüz bir sunucu kurmakla uğraşmak istemiyorsanız.

Şu durumlarda MySQL'e yönelin:

• Birden fazla uygulama sunucusunun tek bir veritabanını paylaşması gerekiyorsa.
• Çok sayıda eşzamanlı yazıcınız varsa.
• İnce ayar gerektiren kullanıcı izinleri ve rol yönetimine ihtiyacınız varsa.
• MySQL'i varsayan bir yığın üzerinde çalışıyorsanız (LAMP, yaygın managed cloud kurulumları).
• Replikasyon, point-in-time recovery, izleme gibi operasyonel araçlar olmazsa olmazsa.

Pratik bir kural: depolama ihtiyacınızı "tek uygulama, tek disk" diye özetleyebiliyorsanız SQLite büyük ihtimalle yeter. Ama "bir servis, üstelik operatörleri olan" diye tarif ediyorsanız MySQL'e (ya da PostgreSQL'e) bakın.

İkisi Arasında Geçiş Yapmak

SQLite ile başlayıp sonra MySQL'e geçmek çok yaygın bir yol — ve gayet makul bir plan. Şemalar küçük ayarlamalarla taşınıyor, veriyi de SQLite CLI'daki .dump ile temiz biçimde dışa aktarabiliyorsunuz. Düzeltmeniz gereken şeyler genelde auto-increment sözdizimi, tarih fonksiyonları ve MySQL'de doğrudan karşılığı olmayan SQLite'a özgü özellikler (acayip biçimli partial indeksler, WITHOUT ROWID, STRICT tablolar) olur.

Ters yönde — MySQL'den SQLite'a — geçmek daha nadir ama o da mümkün; genelde çevrimdışı analiz, verinin bir alt kümesinin gömülü kopyaları veya test fixture'ları için yapılır.

Sonuç şu: bugün SQLite'ı seçmek sizi kilitlemiyor. Yazdığınız SQL de, edindiğiniz kavrayış da taşınabilir.

Sırada: SQLite vs PostgreSQL

En sık yapılan kıyaslama MySQL ile olsa da, SQLite'ın karşısına çıkarılan diğer veritabanı PostgreSQL'dir — ve oradaki farklar bambaşka bir hikâye. Bir sonraki sayfanın konusu bu.