Banyak orang mengira semua database SQL bekerja dengan cara yang sama, lalu kebingungan muncul ketika SQLite terasa sangat berbeda dari PostgreSQL atau MySQL. Perbedaannya bukan soal fitur SQL semata, melainkan arsitektur: SQLite adalah pustaka di dalam proses aplikasi, sedangkan database server adalah program terpisah yang diakses lewat jaringan. Setelah kedua arsitektur kita lihat berdampingan, memilih di antara keduanya menjadi jauh lebih mudah.
Dua Arsitektur yang Berbeda #
Diagram di atas memperlihatkan perbedaan mendasarnya: pada SQLite, query berjalan sebagai pemanggilan fungsi biasa di dalam proses aplikasi (in-process). Pada database server, aplikasi harus membuka koneksi jaringan ke sebuah daemon yang terus berjalan; daemon itulah yang membaca dan menulis penyimpanan. Konsekuensinya menyentuh hampir semua aspek operasional:
| Aspek | SQLite | Database server |
|---|---|---|
| Wujud | Pustaka di dalam proses aplikasi | Proses daemon terpisah |
| Instalasi | Sertakan pustaka atau CLI, selesai | Instal server, nyalakan service |
| Konfigurasi awal | Tidak ada | Berkas konfigurasi, port, alokasi memori |
| Akses jaringan | Tidak ada (memang didesain begitu) | Bawaan, lengkap dengan authentication |
| User dan permission | Mengikuti hak akses berkas OS | Sistem user/grant di dalam database |
| Penulis serentak | Satu penulis pada satu waktu | Banyak, dikoordinasi oleh server |
| Backup | Menyalin berkasnya | Alat khusus seperti pg_dump |
| Jejak resource | Pustaka kecil plus cache halaman | Instalasi server yang lengkap |
Konkurensi: Pembaca dan Penulis #
Perbedaan yang paling sering disalahpahami ada di konkurensi. SQLite mengizinkan pembaca sebanyak apa pun secara bersamaan, tetapi hanya mengizinkan satu penulis pada satu saat di satu berkas database. Penulis lain menunggu antrean; karena sebuah transaction biasanya selesai dalam hitungan milidetik, antrean ini jarang terasa pada aplikasi sehari-hari.
Database server punya koordinator pusat — proses server yang berumur panjang — sehingga mampu mengelola banyak penulis serentak dengan locking yang lebih halus. Untuk aplikasi dengan ratusan penulis aktif pada saat bersamaan, keunggulan koordinasi ini menentukan pilihan.
Tanpa Server, Tanpa Upaya #
Cara kerja serverless paling mudah dipercaya lewat percobaan. Perintah berikut membuat database berkas baru dan mengisinya — perhatikan tidak ada langkah menyalakan service:
/home/z/my-project/tools/sqlite3 toko.db "CREATE TABLE pelanggan (id INTEGER PRIMARY KEY, nama TEXT, kota TEXT); INSERT INTO pelanggan (nama, kota) VALUES ('Budi', 'Jakarta'), ('Siti', 'Bandung');"Tanpa output berarti sukses. Pada pemanggilan berikutnya — proses baru yang benar-benar terpisah — berkas yang sama langsung dapat dibaca:
/home/z/my-project/tools/sqlite3 toko.db "SELECT nama, kota FROM pelanggan ORDER BY id;"Output yang Dihasilkan:
Budi|Jakarta
Siti|BandungDan karena seluruh database berada di satu berkas, backup versi ini semurah menyalin berkas:
cp toko.db toko-backup.db
/home/z/my-project/tools/sqlite3 toko-backup.db "SELECT count(*) FROM pelanggan;"Output yang Dihasilkan:
2Urutan percobaan di atas membuktikan tiga hal: pertama, toko.db tercipta begitu perintah dijalankan, tanpa instalasi apa pun; kedua, setiap pemanggilan sqlite3 adalah proses mandiri yang membuka berkas yang sama, tanpa daemon perantara; ketiga, salinan berkas adalah database utuh yang siap dipakai, bukan hasil dump yang harus dipulihkan dulu.
Bukan Kompetitor #
Pada akhirnya kedua keluarga database ini tidak memperebutkan pekerjaan yang sama — persis seperti filosofi yang kita bahas pada Chapter Sejarah dan Filosofi SQLite: SQLite bersaing dengan fopen(), bukan dengan database client/server. Kita memilih SQLite ketika data menyertai aplikasi di perangkat yang sama, dan memilih database server ketika data dikelola terpusat untuk banyak aplikasi sekaligus.
Bagian dalam SQLite sendiri — bagaimana sebuah query diproses dari teks hingga menyentuh disk — adalah materi Chapter Arsitektur SQLite.