Setiap keputusan teknis pada sebuah perangkat lunak menyimpan jejak masalah yang coba diselesaikan pembuatnya. Begitu juga SQLite: sifat serverless, zero-configuration, hingga lisensi public domain-nya bukan kebetulan, melainkan buah filosofi yang dipegang konsisten sejak rilis pertama. Dengan memahami asal-usul dan prinsip tersebut, kita lebih mudah menilai kapan SQLite cocok dipakai dan kapan tidak.

Asal-usul SQLite #

SQLite dirancang oleh D. Richard Hipp dan dirilis perdana pada tahun 2000. Proyek ini lahir dari kebutuhan praktis: banyak program membutuhkan penyimpanan data terstruktur, tetapi tidak semua lingkungan sanggup — atau layak — menjalankan database server beserta administratornya. SQLite mengambil jalur berbeda dengan menjadikan seluruh engine database sebuah pustaka kecil yang tertanam langsung di dalam program.

Sejak rilis perdana itu, pengembangan SQLite tidak pernah berhenti. Versi utamanya kini berada pada garis 3.x yang terus dirawat secara aktif oleh tim kecil yang dipimpin penciptanya. Fokus pengembangannya juga tidak bergeser: database yang bisa diandalkan tanpa perlu diurus.

Filosofi Pengganti fopen() #

Dokumentasi resmi SQLite meringkas posisinya dalam satu kalimat yang sering dikutip: “Think of SQLite not as a replacement for Oracle but as a replacement for fopen()” — anggap SQLite bukan pengganti Oracle, melainkan pengganti fopen(), fungsi standar C untuk membuka berkas. SQLite memang tidak bersaing dengan database server; yang digantikannya adalah cara kita menyimpan data ke dalam berkas buatan sendiri. Kalimat ini menjelaskan hampir semua keputusan desain berikut:

  • Ekonomi: dengan seluruh fitur aktif, ukuran pustaka SQLite bisa di bawah 900 KiB — cukup ringkas untuk ponsel, router, hingga perangkat IoT.
  • Nol administrasi: tidak ada user, password, atau tugas tuning; perangkat di lapangan harus bisa hidup tanpa tenaga ahli.
  • Keandalan di atas segalanya: transaction wajib tetap ACID meski aplikasi crash atau listrik padam di tengah penulisan.
  • Format berkas stabil: format berkasnya terdokumentasi dan dijaga kompatibel antarversi, sehingga data lama selalu dapat dibuka oleh versi baru.
  • Kesederhanaan: seluruh kode sumber pustaka bahkan dapat digabungkan menjadi satu berkas sqlite3.c (disebut amalgamation) yang tinggal dimasukkan ke proyek mana pun.

Klaim keandalan itu bukan slogan. Sebelum setiap rilis, rangkaian uji otomatis menjalankan jutaan test case yang mencakup ratusan juta statement SQL dan mencapai 100% branch coverage. Ada pula test harness khusus yang mensimulasikan kegagalan listrik dan disk untuk membuktikan mekanisme pemulihannya benar-benar bekerja.

Lisensi Public Domain #

Keunikan lain SQLite ada pada lisensinya: kode sumbernya berstatus public domain — bebas dipakai, diubah, dijual, atau didistribusikan ulang untuk tujuan apa pun tanpa perlu atribusi maupun pembayaran. Status ini berbeda dari lisensi open source umum seperti MIT atau GPL yang masih memasang syarat tertentu. Praktisnya, SQLite boleh ditautkan ke aplikasi closed source, dibundel dalam firmware, atau disalin ke proyek internal tanpa urusan hukum.

Kombinasi keandalan dan kebebasan inilah yang membuat Library of Congress Amerika Serikat merekomendasikan format penyimpanan SQLite untuk arsip data jangka panjang.

Pustaka yang Bisa Disetel #

Meski menganut filosofi ringkas, SQLite tetap bisa disetel pada saat kompilasi: fitur dapat dimatikan untuk memperkecil ukuran, dan batas internal dapat diubah sesuai kebutuhan. Kita bisa mengintip konfigurasi binary yang sedang kita pakai lewat satu PRAGMA:

bash
/home/z/my-project/tools/sqlite3 :memory: "PRAGMA compile_options;"

Output yang Dihasilkan:

text
ATOMIC_INTRINSICS=1
COMPILER=gcc-13.3.0
DEFAULT_AUTOVACUUM
DEFAULT_CACHE_SIZE=-2000
DEFAULT_FILE_FORMAT=4
DEFAULT_JOURNAL_SIZE_LIMIT=-1
DEFAULT_MMAP_SIZE=0
DEFAULT_PAGE_SIZE=4096
DEFAULT_PCACHE_INITSZ=20
DEFAULT_RECURSIVE_TRIGGERS
DEFAULT_SECTOR_SIZE=4096
DEFAULT_SYNCHRONOUS=2
DEFAULT_WAL_AUTOCHECKPOINT=1000
DEFAULT_WAL_SYNCHRONOUS=2
DEFAULT_WORKER_THREADS=0
DIRECT_OVERFLOW_READ
DQS=0
ENABLE_BYTECODE_VTAB
ENABLE_DBPAGE_VTAB
ENABLE_DBSTAT_VTAB
ENABLE_EXPLAIN_COMMENTS
ENABLE_FTS3
ENABLE_FTS4
ENABLE_FTS5
ENABLE_GEOPOLY
ENABLE_MATH_FUNCTIONS
ENABLE_OFFSET_SQL_FUNC
ENABLE_PREUPDATE_HOOK
ENABLE_RTREE
ENABLE_SESSION
ENABLE_STMTVTAB
ENABLE_STMT_SCANSTATUS
ENABLE_UNKNOWN_SQL_FUNCTION
HAVE_ISNAN
MALLOC_SOFT_LIMIT=1024
MAX_ATTACHED=10
MAX_COLUMN=2000
MAX_COMPOUND_SELECT=500
MAX_DEFAULT_PAGE_SIZE=8192
MAX_EXPR_DEPTH=1000
MAX_FUNCTION_ARG=1000
MAX_LENGTH=1000000000
MAX_LIKE_PATTERN_LENGTH=50000
MAX_MMAP_SIZE=0x7fff0000
MAX_PAGE_COUNT=0xfffffffe
MAX_PAGE_SIZE=65536
MAX_SQL_LENGTH=1000000000
MAX_TRIGGER_DEPTH=1000
MAX_VARIABLE_NUMBER=32766
MAX_VDBE_OP=250000000
MAX_WORKER_THREADS=8
MUTEX_PTHREADS
SYSTEM_MALLOC
TEMP_STORE=1
THREADSAFE=1

Beberapa baris layak kita cermati lebih dekat:

  1. DEFAULT_PAGE_SIZE=4096: ukuran halaman bawaan berkas database — maknanya kita bedah pada Chapter Format Berkas Database.
  2. ENABLE_FTS5: dukungan full-text search generasi kelima ikut dikompilasi.
  3. ENABLE_RTREE: index spasial untuk query berbasis koordinat ikut tersedia.
  4. MAX_LENGTH=1000000000: panjang satu nilai string atau BLOB dibatasi sekitar satu gigabyte.
  5. THREADSAFE=1: pustaka aman dipakai banyak thread sekaligus.

Konfigurasi seperti ini menjelaskan mengapa “SQLite” di aplikasi A bisa berbeda kemampuannya dari “SQLite” di aplikasi B — mesin dasarnya sama, setelan kompilasinya yang menyesuaikan kebutuhan.

Filosofi di atas menjelaskan wujud SQLite; pertanyaan berikutnya adalah untuk pekerjaan apa wujud itu paling pas. Itulah materi Chapter Kapan Menggunakan SQLite.