Kapan Memakai SQLite: Kegunaan, Batasan, dan Kapan Tidak

Pertanyaan Intinya

SQLite bukan versi kecil dari Postgres. SQLite adalah alat dengan bentuk yang berbeda. Seluruh database-nya adalah sebuah file di disk, dan aplikasimu berkomunikasi dengannya lewat library yang ditautkan ke proses yang sama: tanpa server, tanpa jaringan, tanpa user. Desain itu membuat SQLite luar biasa untuk sebagian pekerjaan dan kurang cocok untuk pekerjaan lain.

Pertanyaan penentunya hampir tidak pernah "apakah SQLite cukup cepat?" (biasanya cukup). Pertanyaannya adalah "apakah bentuk aplikasiku cocok dengan keunggulan SQLite?" Dua hal yang paling menentukan: di mana datanya berada, dan berapa banyak yang menulis ke sana sekaligus.

Pakai SQLite Saat Datanya Berada Bersama Aplikasi

SQLite bersinar saat database-nya milik satu aplikasi di satu mesin. File-nya berada di samping kodemu, aplikasimu membukanya langsung, dan itulah seluruh arsitekturnya.

-- A typical "data lives with the app" schema:
-- a desktop note-taking app's local store.
CREATE TABLE notes (
    id        INTEGER PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT,
    created   TEXT DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO notes (title, body) VALUES
    ('Groceries', 'milk, bread, coffee'),
    ('Ideas',     'sqlite tutorial outline');

SELECT id, title, created FROM notes;

Skema sekecil itu bisa menjadi seluruh backend sebuah aplikasi sungguhan. Beberapa kasus yang cocok secara alami dengan pola ini:

• Aplikasi desktop dan mobile. Setiap aplikasi iOS dan Android yang butuh penyimpanan lokal terstruktur memakai SQLite di baliknya. Begitu juga Firefox, Chrome, dan sebagian besar browser.
• Alat CLI. git, package manager, dan pengelola dotfile semuanya memakai database tertanam.
• Perangkat tertanam. Router, mobil, pesawat: apa pun yang butuh database dengan ukuran hanya beberapa ratus kilobyte.
• Test suite. File SQLite baru (atau database :memory:) untuk setiap pengujian lebih cepat dan lebih terisolasi daripada menyalakan Postgres.

Jika datamu tidak perlu dibagikan ke beberapa mesin, SQLite kemungkinan besar adalah jawaban yang tepat.

Pakai SQLite untuk Situs Web yang Banyak Membaca

SQLite menangani pembacaan dengan sangat baik. Banyak pembaca serentak, tanpa perebutan, waktu query dalam hitungan mikrodetik untuk pencarian yang memakai index. Jika situsmu kebanyakan berisi orang yang membaca konten, seperti blog, dokumentasi, situs marketing, atau dashboard SaaS kecil, SQLite akan bertahan dengan baik, sering kali lebih baik daripada Postgres yang terhubung lewat jaringan karena tidak ada perjalanan bolak-balik.

-- A blog's posts table.
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', 'Hello, World', 'First post.', '2024-01-01'),
    ('sqlite-rocks', 'Why SQLite',  'Single-file DB.', '2024-02-15');

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

Masalahnya ada pada penulisan. SQLite menjalankan penulisan satu per satu: hanya satu penulis yang bisa memegang kunci pada satu waktu. Untuk blog dengan beberapa penulis, itu tidak terasa. Untuk aplikasi chat dengan ribuan user yang mengirim pesan setiap detik, itu masalah.

Mode WAL (write-ahead logging, dibahas nanti) menaikkan batas itu secara signifikan dengan membiarkan pembaca dan penulis bekerja paralel. Banyak situs produksi melayani jutaan request sehari dengan SQLite + WAL.

Pakai SQLite untuk Cache Lokal dan Data Sementara

Setiap kali kamu butuh penyimpanan lokal yang terstruktur, sesuatu yang lebih dari file JSON tapi kurang dari server database penuh, SQLite sulit dikalahkan.

-- A cache table for an HTTP client.
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;

Log, buffer analitik, staging ETL, feature store machine learning, index IDE: semuanya tempat yang cocok untuk SQLite. File-nya portabel, bahasa query-nya SQL lengkap, dan tidak ada server yang perlu diawasi.

Jangan Pakai SQLite untuk Banyak Penulis Serentak

Inilah keterbatasan yang sering menjebak. SQLite memakai kunci tulis tingkat database: satu penulis, titik. Dua proses yang mencoba insert pada saat yang sama berarti salah satunya menunggu.

Untuk sebagian besar aplikasi hal itu tidak penting, karena penulisan jarang dan cepat. Tapi jika beban kerjamu seperti ini:

• SaaS multi-tenant dengan ribuan user yang menulis secara bersamaan,
• Message queue atau log peristiwa dengan throughput tinggi,
• Backend game real-time atau chat dengan perubahan state terus-menerus,

maka SQLite akan menjadi hambatan. Postgres dan MySQL memakai penguncian tingkat baris dan dibuat persis untuk ini. Pilih salah satunya.

-- The error you'll see when writers pile up:
Error: database is locked

Jika kamu melihat error itu di bawah beban normal, SQLite adalah alat yang salah, bukan bug yang perlu diakali.

Jangan Pakai SQLite di Beberapa Mesin

SQLite adalah library yang berjalan di dalam proses. Aplikasi membaca dan menulis file-nya secara langsung, artinya file itu harus berada di disk yang bisa di-read() dan di-write() oleh aplikasi dengan pemanggilan sistem file biasa.

Itu menyingkirkan:

• Beberapa server aplikasi di belakang load balancer yang semuanya ingin berbagi satu database. (Sistem file jaringan seperti NFS secara teknis bisa, tapi merusak file-nya saat bebannya tinggi. Jangan.)
• Fungsi serverless yang setiap pemanggilannya berjalan di mesin berbeda.
• Pod Kubernetes yang butuh database bersama, kecuali kamu memakai deployment satu pod dengan persistent volume.

Jika arsitekturmu punya lebih dari satu proses di lebih dari satu mesin yang menulis ke database, kamu butuh database client-server. Itulah batasnya.

Jangan Pakai SQLite Saat Kamu Butuh User di Tingkat Database

SQLite tidak mengenal konsep user, role, atau hak akses. Database-nya adalah file: siapa pun yang bisa membaca file-nya bisa membaca semuanya; siapa pun yang bisa menulisnya bisa menulis semuanya. Kontrol akses adalah tugas sistem operasi.

Untuk aplikasi desktop satu user, itu tidak masalah. Untuk sistem multi-tenant tempat orang yang berbeda butuh hak akses berbeda di dalam database, kamu butuh Postgres atau MySQL.

Daftar Periksa Singkat untuk Memutuskan

Telusuri daftar ini. Jika jawabanmu "ya" untuk semuanya, SQLite kemungkinan besar pilihan yang bagus:

• Database-nya berada di mesin yang sama dengan aplikasi.
• Satu proses (atau beberapa, yang kebanyakan membaca) berkomunikasi dengannya.
• Total datanya muat dengan nyaman di satu disk: ukuran terabyte tidak masalah, tapi tetap satu disk.
• Kamu tidak butuh hak akses user di tingkat database.
• Penulisan serentak hanya sesekali, bukan beban kerja yang dominan.

Jika ada jawaban "tidak", lihat Postgres atau MySQL. Dua halaman berikutnya membandingkan keduanya secara langsung.

Yang Perlu Kamu Ingat

• SQLite adalah pilihan yang tepat saat database-nya lokal bagi aplikasi: desktop, mobile, perangkat tertanam, alat CLI, test suite, situs yang banyak membaca, cache lokal.
• SQLite berkualitas produksi: miliaran perangkat menyertakannya. Batasannya bersifat arsitektural, bukan soal kualitas.
• Lewati SQLite saat kamu butuh banyak penulis serentak, akses dari banyak mesin, atau hak akses database per user.

Berikutnya: Memasang SQLite

Cukup teorinya. Halaman berikutnya memandu cara memasang SQLite di mesinmu (sudah tersedia di macOS dan sebagian besar distro Linux, dan cukup satu unduhan di Windows) serta memastikan pemasangannya dari command line.