Pola Penggunaan SQLite di Produksi

Produksi tidak selalu berarti ruang server dengan administrator siaga. Miliaran salinan SQLite berjalan saat ini di perangkat di sekitar kita — ponsel, router, televisi, browser — tanpa seorang pun yang mengurusnya sebagai “database”. Chapter ini memetakan pola-pola penerapan nyata yang terbukti bekerja di lapangan, lalu menutup dengan satu model mental yang menjadi benang merah semuanya.

Perangkat Embedded dan IoT #

SQLite berjalan di tempat yang tidak mengizinkan administrator: sensor industri, set-top box, router, mesin penjual otomatis. Seluruh database berupa satu berkas tanpa proses server, sehingga tidak ada layanan yang harus dipasang, diamankan, atau dimulai ulang. Dokumentasi resmi menyebut SQLite terpasang di setiap ponsel dan mayoritas komputer di dunia (sqlite.org/about.html).

Makna “produksi” pada pola ini ekstrem: perangkat ditinggal di lapangan bertahun-tahun tanpa sentuhan manusia. Konsekuensi desainnya jelas — setiap perangkat memegang datanya sendiri secara lokal, tanpa database pusat. Bukan keterbatasan yang disesali, melainkan persis alasan SQLite dipilih.

Aplikasi Mobile dan Desktop #

Sistem operasi mobile sudah menyertakan SQLite, sehingga aplikasi iOS dan Android menyimpan data lokal tanpa membawa mesin database sendiri. Contoh paling terkenal ada di desktop: Firefox menyimpan riwayat penjelajahan dan bookmark di berkas places.sqlite, sementara Chrome menyimpan riwayatnya di berkas History — keduanya berkas SQLite biasa.

Ciri pola ini: satu aplikasi adalah pemilik data sekaligus satu-satunya penulis. Ribuan baris riwayat per hari masuk dari satu proses, dan query-nya melayani layar aplikasi yang sama. Tidak ada koneksi jaringan, tidak ada autentikasi — data dan kode hidup bersama dalam satu perangkat.

Website Lalu Lintas Rendah sampai Menengah #

Chapter Kapan Menggunakan SQLite sudah memetakan patokannya dari dokumentasi resmi (sqlite.org/whentouse.html): situs dengan kurang dari 100.000 hit per hari umumnya aman ditangani SQLite, dan angka itu konservatif. Bentuk penerapannya sederhana: satu berkas database di server aplikasi, tanpa server database terpisah.

Pola ini paling cocok untuk beban baca dominan — katalog produk, blog, wiki internal, dashboard. Tulisan yang pendek seperti sesi login atau komentar tetap nyaman karena transaksinya berlangsung milidetik. Batas polanya juga jelas: satu server. Begitu beberapa mesin aplikasi harus menulis ke data yang sama, kita berada di wilayah Chapter Kapan Pindah dari SQLite.

Format Berkas Aplikasi #

Pola yang kurang dikenal namun didokumentasikan khusus oleh sqlite.org (appfileformat.html): memakai berkas SQLite sebagai format berkas aplikasi — pengganti format biner buatan sendiri atau tumpukan berkas JSON/XML. Konfigurasi, dokumen proyek, dan berkas simpanan game masuk dalam pola ini.

Dokumentasi yang sama menyediakan PRAGMA application_id: empat byte di header berkas yang bisa kita isi magic number milik aplikasi, agar berkas mudah dikenali oleh alat lain. Kita buktikan langsung:

sqlite3 pengaturan.db "CREATE TABLE pengaturan (kunci TEXT PRIMARY KEY, nilai TEXT NOT NULL);
INSERT INTO pengaturan VALUES ('tema','gelap'),('bahasa','id'),('stok_minimum','10');
PRAGMA application_id = 0x41505031;"

sqlite3 pengaturan.db "PRAGMA application_id; SELECT kunci, nilai FROM pengaturan ORDER BY kunci;"

Output yang Dihasilkan:

1095782449
bahasa|id
stok_minimum|10
tema|gelap

Mari kita bedah keluaran di atas:

1. Baris 1095782449: nilai balikan PRAGMA application_id pada pemanggilan kedua — angka desimal dari 0x41505031, magic number yang byte-nya mengeja APP1 dalam ASCII (0x41=A, 0x50=P, 0x50=P, 0x31=1). Nilai ini tersimpan permanen di header berkas yang dibahas pada Chapter Format Berkas Database.
2. Bertahannya nilai: pemanggilan kedua berjalan lewat koneksi baru setelah koneksi pertama ditutup — berbeda dari busy_timeout, ini bagian dari berkasnya, bukan pengaturan per-koneksi.
3. Tiga baris terakhir: konfigurasi kini bisa dikueri dengan SQL — WHERE, ORDER BY, dan JOIN tersedia tanpa menulis parser format sendiri.

Analisis Data dan Format Pertukaran #

Satu berkas .db juga berfungsi sebagai paket data yang siap dikirim: hasil ekspor analitik dikirim sebagai satu berkas, dan penerima langsung bisa meng-query-nya tanpa langkah import. CSV kehilangan tipe dan relasi antar tabel; JSON harus di-parse seluruhnya ke memori. Ragam perintah ekspor dan import dibahas pada Chapter Export dan Import Data.

Pola serumpun dipakai sebagai lapisan cache: hasil komputasi yang mahal disimpan ke database SQLite lokal, lengkap dengan kolom masa berlaku untuk dibersihkan berkala. Aplikasi utama bebas membaca cache tanpa menambah beban database pusat.

Satu Model Mental untuk Semuanya #

Kelima pola di atas ternyata memakai benang merah yang sama. Data dimiliki satu aplikasi di satu perangkat; pembacanya bisa banyak, tetapi jalur penulisnya tunggal.

Kalau sistem yang sedang kita bangun menempati salah satu baris tabel itu, memilih SQLite bukan keputusan berani — melainkan keputusan default yang masuk akal. Batas satu penulisnya tidak hilang, tetapi menjadi mudah dikelola dengan strategi yang dibahas pada Chapter Strategi Concurrency.