Kita sudah mengenal wujud SQLite; pertanyaan berikutnya adalah kapan memakainya. Memilih alat penyimpanan yang tepat menentukan apakah waktu kita habis untuk menulis fitur atau untuk mengurus infrastruktur. Kabar baiknya, dokumentasi resmi SQLite memetakan dengan jelas skenario yang cocok dan yang tidak, dan peta itu bisa kita ringkas menjadi aturan praktis.

Skenario yang Cocok #

SQLite bersinar ketika data dan aplikasi yang mengaksesnya hidup di perangkat yang sama. Berikut skenario yang paling sering disebut:

SkenarioMengapa SQLite pas
Aplikasi desktop dan mobileSatu berkas data.db menggantikan format kustom yang rumit
Perangkat embedded dan IoTTidak butuh administrator; jalan di perangkat tanpa layar pun bisa
Website lalu lintas rendah hingga menengahLebih dari cukup untuk mayoritas situs; sqlite.org sendiri memakai SQLite
Analisis dataImpor data mentah, lalu olah dengan JOIN dan agregasi; hasilnya satu berkas
Pengganti fopen()Lebih cepat dan lebih aman daripada mengelola format berkas buatan sendiri
Database sementara untuk testing:memory: memberi database sungguhan tanpa meninggalkan berkas

Untuk website, dokumentasi memberi patokan konservatif: situs dengan kurang dari 100.000 permintaan per hari umumnya aman ditangani SQLite, dan angka itu bukan batas keras — situs sqlite.org sendiri, yang tentu memakai SQLite, dilaporkan melayani sekitar 400 sampai 500 ribu permintaan per hari hanya dari satu virtual machine.

Skenario yang Kurang Cocok #

Kekuatan SQLite pada arsitektur embedded sekaligus menjadi batasnya. Dokumentasi resmi mencatat tiga situasi yang lebih baik ditangani database client/server:

  • Banyak klien jaringan: bila puluhan program mengirim SQL ke database yang sama melalui jaringan secara langsung, database client/server adalah pilihan yang tepat. Selain soal performa, mekanisme file locking pada network filesystem kerap bermasalah dan berpotensi merusak berkas database.
  • Penulisan sangat serentak: SQLite mengizinkan pembaca sebanyak apa pun, tetapi hanya satu penulis pada satu saat. Penulis berikutnya menunggu antrean — lazimnya hanya beberapa milidetik, tetapi aplikasi dengan ratusan penulis serempak akan terhambat.
  • Dataset sangat besar: SQLite mendukung berkas database hingga sekitar 281 terabyte, jauh melampaui kebutuhan biasa. Namun satu berkas raksasa sulit dicadangkan dan dipindahkan; database server yang menyebarkan data lintas berkas dan volume lebih praktis.

Alur Keputusan Cepat #

Ketiga pengecualian di atas bisa kita padatkan menjadi satu alur keputusan sederhana:

Contoh Nyata: Analisis Data Singkat #

Salah satu skenario favorit pemakai SQLite adalah analisis data sekali jalan. Kita muat data penjualan ke database di memori, lalu membiarkan SQL mengerjakan agregasi:

bash 
/home/z/my-project/tools/sqlite3 :memory: "CREATE TABLE penjualan (id INTEGER PRIMARY KEY, produk TEXT, jumlah INTEGER, harga REAL); INSERT INTO penjualan (produk, jumlah, harga) VALUES ('Kopi Arabika', 12, 45000), ('Teh Hijau', 30, 15000), ('Kopi Robusta', 8, 38000), ('Gula Aren', 20, 25000), ('Kopi Arabika', 5, 45000); SELECT produk, SUM(jumlah * harga) AS total FROM penjualan GROUP BY produk ORDER BY total DESC;"

Output yang Dihasilkan:

text 
Kopi Arabika|765000.0
Gula Aren|500000.0
Teh Hijau|450000.0
Kopi Robusta|304000.0

Mari kita bedah query terakhirnya:

  1. SUM(jumlah * harga): untuk setiap kelompok produk, SQLite mengalikan jumlah dengan harga per baris, lalu menjumlahkannya.
  2. GROUP BY produk: baris dikelompokkan per nama produk, sehingga Kopi Arabika yang muncul dua kali terhitung sebagai satu kelompok (12 + 5 buah).
  3. ORDER BY total DESC: hasil diurutkan dari total terbesar agar output deterministik dan mudah dibaca.

Dengan pola yang sama kita bisa mengganti SUM menjadi AVG, menambah filter WHERE, atau memilih kolom lain — semua tanpa memasang server apa pun. Bila data disimpan di berkas biasa, laporan seperti ini harus dihitung manual oleh program kita sendiri.

Perbandingan mendalam antara kedua keluarga database ini kita bahas pada Chapter SQLite vs Database Server.