SQLite Adalah: Cara Kerja, Kelebihan & Kapan Dipakai

Hampir setiap program yang Anda tulis pada akhirnya perlu menyimpan sesuatu — daftar catatan, riwayat transaksi, atau pengaturan pengguna. Cara paling sederhana adalah menuliskannya ke sebuah berkas biasa, entah .txt, .csv, atau .json. Pendekatan ini bekerja dengan baik sampai kebutuhannya bertambah.

Masalahnya muncul bertahap. Mencari satu baris di antara ribuan berarti membaca seluruh berkas dari awal. Dua proses yang menulis bersamaan bisa saling menimpa. Dan kalau listrik padam tepat di tengah penulisan, yang tersisa adalah berkas separuh jadi yang tidak terbaca oleh siapa pun.

SQLite adalah mesin basis data yang menyelesaikan ketiga masalah itu sekaligus, tanpa menuntut Anda memasang server apa pun. Ia bukan aplikasi yang dijalankan, melainkan pustaka kode yang menyatu ke dalam program Anda. Artikel ini membahas apa itu SQLite, cara kerjanya, kelebihan dan kekurangannya, serta ambang yang jelas untuk memutuskan kapan ia cukup dan kapan Anda perlu pindah.

SQLite Adalah Mesin Basis Data di Dalam Aplikasi Anda

Secara teknis, SQLite adalah pustaka berbahasa C yang menyediakan mesin basis data SQL lengkap. Anda tidak menjalankannya sebagai program terpisah. Ia dikompilasi bersama aplikasi Anda dan hidup di ruang memori yang sama.

Dokumentasi resminya merangkum empat sifat utama:

1. Serverless: tidak ada proses server yang berjalan di latar belakang. Aplikasi Anda membaca dan menulis langsung ke berkas basis data.
2. Zero-configuration: tidak ada instalasi, tidak ada berkas konfigurasi, tidak ada layanan yang perlu dinyalakan atau dimatikan.
3. Self-contained: seluruh mesin basis data berada dalam satu pustaka yang nyaris tidak bergantung pada pustaka luar. Dengan semua fitur diaktifkan, ukurannya masih di bawah 900 KB.
4. Transaksional: perubahan bersifat ACID (Atomicity, Consistency, Isolation, Durability), dan tetap aman bahkan ketika sistem mati mendadak di tengah penulisan.

Namanya sering ditulis keliru, jadi perlu diluruskan sekali: penulisan yang benar adalah SQLite, bukan "sql lite" atau "sqllite".

Satu berkas basis data SQLite memuat seluruh isinya: tabel, indeks, trigger, dan view. Konsep tabel, baris, dan relasi antar-tabel di sini sama persis dengan database relasional lain. SQLite memang termasuk RDBMS (Relational Database Management System), hanya bentuk pengemasannya yang berbeda.

Kenapa SQLite Bukan Pesaing MySQL

Ini bagian yang paling sering disalahpahami. Dokumentasi resmi SQLite menyatakan posisinya dengan tegas: SQLite tidak bersaing dengan MySQL atau Oracle, melainkan dengan fopen() — fungsi standar bahasa C untuk membuka berkas.

Pernyataan itu bukan permainan kata. Ia menjelaskan untuk masalah apa SQLite dirancang. MySQL dan PostgreSQL menjawab pertanyaan bagaimana banyak aplikasi di banyak mesin berbagi satu kumpulan data secara aman. SQLite menjawab pertanyaan yang sama sekali lain: bagaimana satu aplikasi menyimpan datanya sendiri secara terstruktur dan tahan mati listrik.

Karena keduanya menjawab pertanyaan berbeda, pertanyaan "SQLite atau MySQL, mana yang lebih baik" sebenarnya salah bentuk. Yang tepat adalah menanyakan apakah data Anda perlu dibagi ke banyak mesin. Kalau tidak, SQLite hampir selalu lebih sederhana.

Istilah teknis untuk kategori ini adalah embedded database — basis data yang tertanam di dalam aplikasi, bukan berdiri sendiri sebagai layanan. SQLite adalah contoh yang paling banyak dipakai di kategori tersebut.

Cara Kerja SQLite: Satu Berkas, Tanpa Server

Pada basis data model client-server, aplikasi Anda menyusun perintah SQL, mengirimkannya lewat jaringan ke proses server, lalu menunggu jawaban kembali. Server itulah yang benar-benar menyentuh berkas data di disk.

Diagram alur client-server basis data dengan aplikasi, server, dan berkas data di disk.

SQLite memangkas lapisan tengah itu. Pustaka SQLite berada di dalam aplikasi Anda, sehingga menjalankan sebuah query sama saja dengan memanggil sebuah fungsi. Tidak ada perjalanan pesan bolak-balik, tidak ada koneksi yang perlu dibuka, tidak ada port yang perlu didengarkan.

Diagram alur aplikasi dan pustaka SQLite yang mengakses satu berkas basis data.

Perbedaan ini punya akibat praktis. Pada basis data client-server, menjalankan banyak query kecil berturut-turut adalah pemborosan, sebab tiap query membayar ongkos perjalanan jaringan. Pola tersebut dikenal sebagai N+1 query problem. Di SQLite, ongkos itu nyaris tidak ada. Dokumentasi resminya mencontohkan halaman berisi lima puluh entri dengan lebih dari dua ratus pernyataan SQL, dan seluruhnya selesai di bawah 25 milidetik.

Akibat kedua menyangkut kemudahan operasional. Format berkasnya bersifat lintas platform: berkas yang dibuat di mesin 32-bit langsung terbaca di mesin 64-bit dengan arsitektur prosesor berbeda. Untuk keperluan backup, Anda menyalin satu berkas dan pekerjaan selesai.

Lahir di Kapal Perang, Kini Ada di Mana-mana

SQLite dirancang D. Richard Hipp pada musim semi tahun 2000, ketika ia bekerja untuk General Dynamics dalam kontrak dengan Angkatan Laut Amerika Serikat. Perangkat lunak yang ia kerjakan adalah sistem kendali kerusakan untuk kapal perusak berpeluru kendali. Sistem itu bergantung pada basis data Informix yang berjalan di HP-UX.

Kebergantungan itulah masalahnya. Di tengah laut, tidak ada administrator basis data yang bisa dipanggil ketika server bermasalah. Hipp membutuhkan mesin basis data yang tidak pernah butuh dijaga siapa pun. Versi 1.0 dirilis Agustus 2000, dan versi 3.0 menyusul pada Juni 2004. Versi terbaru saat artikel ini ditulis adalah 3.53.4, dirilis 24 Juli 2026.

Dua puluh enam tahun kemudian, hasilnya kemungkinan besar sudah ada di saku Anda. SQLite berjalan di setiap perangkat Android dan iOS, di macOS dan Windows, serta di dalam Chrome, Firefox, dan Safari. Python menyertakan modul sqlite3 secara bawaan, dan PHP mendukungnya lewat PDO tanpa tambahan apa pun. Pengembang Flutter memakainya lewat paket sqflite, sementara pengembang Android mengaksesnya lewat pustaka Room. Perangkat lunak penerbangan Airbus A350 XWB pun memakainya.

Menimbang jumlah ponsel pintar aktif di dunia dan jumlah basis data yang dibawa masing-masing, pengembangnya memperkirakan ada lebih dari satu triliun basis data SQLite yang aktif hari ini. Seluruh kodenya berada di domain publik — bukan sekadar open source, melainkan tanpa hak cipta sama sekali. Artinya ia bebas dipakai untuk produk komersial tanpa syarat atribusi.

Kelebihan SQLite

1. Nol konfigurasi dan nol perawatan: tidak ada layanan yang perlu dinyalakan, tidak ada kata sandi yang perlu diatur, tidak ada port yang perlu dibuka. Berkas basis data dibuat sendiri saat pertama kali dipakai.
2. Seluruh basis data dalam satu berkas: menyalin, memindahkan, atau mencadangkan basis data setara dengan menangani satu berkas biasa.
3. Cepat untuk akses lokal: pengujian resmi memakai 100.000 objek biner berukuran 8–12 KB. Membaca dari SQLite tercatat sekitar 35% lebih cepat dibanding membaca berkas terpisah dari sistem berkas di Android, dan sekitar lima kali lebih cepat di Windows 10.
4. Keandalan yang bisa diperiksa angkanya: pustaka intinya sekitar 156 ribu baris kode, sementara kode pengujiannya mencapai sekitar 92 juta baris — kira-kira 590 kali lipat. Cakupan cabang dan MC/DC pengujian itu mencapai 100%, standar yang lazim di perangkat lunak penerbangan.
5. Gratis tanpa syarat apa pun: status domain publik berarti tidak ada lisensi yang perlu dipatuhi, bahkan untuk produk komersial tertutup.
6. Format arsip jangka panjang: Library of Congress Amerika Serikat memasukkan format berkas SQLite sebagai format yang direkomendasikan untuk penyimpanan data jangka panjang.

Infografis empat kelebihan SQLite: nol konfigurasi, satu berkas, domain publik, dan teruji ketat.

Kekurangan SQLite yang Perlu Anda Ketahui

Sifat yang membuat SQLite ringan juga yang membatasinya. Berikut hal-hal yang perlu Anda perhitungkan sebelum memilihnya.

1. Hanya satu penulis pada satu waktu: pembaca boleh sebanyak apa pun secara bersamaan, tetapi proses menulis dijalankan bergiliran. Pada beban tulis yang padat, antrean ini terasa.
2. Tidak dirancang untuk diakses lewat jaringan: menaruh berkas SQLite di network share lalu mengaksesnya dari beberapa mesin adalah resep kerusakan data. Penguncian berkas di sistem berkas jaringan tidak dapat diandalkan.
3. Tidak ada manajemen pengguna maupun enkripsi bawaan: tidak ada konsep pengguna, kata sandi, atau hak akses per tabel, dan data tersimpan sebagai teks biasa. Siapa pun yang bisa membaca berkasnya bisa membaca seluruh isinya.
4. Tidak ada stored procedure: logika yang di basis data lain bisa dititipkan ke server harus berada di dalam kode aplikasi Anda.
5. Perintah ALTER TABLE terbatas: SQLite hanya mendukung sebagian kecil operasi pengubahan struktur tabel. Perubahan yang lebih rumit dilakukan dengan membuat tabel baru lalu memindahkan datanya.
6. Kunci asing mati secara bawaan: penegakan foreign key harus dinyalakan sendiri lewat PRAGMA foreign_keys = ON; pada setiap koneksi, demi menjaga kecocokan dengan basis data lama.

Batas ukuran sendiri jarang menjadi persoalan nyata. Satu berkas SQLite secara teoretis sanggup menampung 281 terabyte — jauh melampaui titik ketika menyimpan segalanya dalam satu berkas berhenti masuk akal karena alasan lain.

Tipe Data yang Longgar dan Cara Mengencangkannya

Inilah perilaku yang paling sering mengejutkan pendatang dari MySQL atau PostgreSQL. Di SQLite, tipe kolom bersifat anjuran, bukan kewajiban. Dokumentasi resminya menyebut mekanisme ini type affinity.

Perhatikan apa yang terjadi ketika teks dimasukkan ke kolom bertipe INTEGER:

CREATE TABLE nilai (
    id    INTEGER PRIMARY KEY,
    skor  INTEGER
);

INSERT INTO nilai (skor) VALUES ('delapan puluh');

SELECT id, skor, typeof(skor) FROM nilai;

Perintah di atas berjalan mulus tanpa satu pun pesan kesalahan, dan hasil SELECT mengembalikan 1|delapan puluh|text. SQLite tidak menolak, tidak memotong, dan tidak mengubah nilainya — ia menyimpan teks tersebut apa adanya di dalam kolom yang Anda deklarasikan sebagai angka. Perilaku serupa berlaku pada VARCHAR(50) yang dengan senang hati menerima 2.000 karakter.

Sejak versi 3.37.0 yang dirilis 27 November 2021, ada jalan keluar resmi berupa STRICT tables. Cukup tambahkan kata kunci STRICT di akhir definisi tabel:

CREATE TABLE nilai_ketat (
    id    INTEGER PRIMARY KEY,
    skor  INTEGER
) STRICT;

INSERT INTO nilai_ketat (skor) VALUES ('delapan puluh');

Kali ini SQLite menolak dengan pesan yang jelas:

Error: stepping, cannot store TEXT value in INTEGER column nilai_ketat.skor (19)

Kalau Anda datang dari basis data yang menegakkan tipe secara ketat, biasakan menambahkan STRICT sejak awal. Kebiasaan ini menutup satu kelas kesalahan yang biasanya baru ketahuan berbulan-bulan kemudian.

Satu keanehan lain yang perlu diketahui: pada tabel biasa, kolom PRIMARY KEY masih dapat menerima nilai NULL. Ini kelalaian historis yang sudah dipakai begitu banyak basis data beredar sehingga tidak bisa diperbaiki tanpa merusak data lama. Tabel STRICT menolaknya dengan benar.

Satu Penulis pada Satu Waktu dan Peran Mode WAL

Pada aplikasi yang cukup sibuk, cepat atau lambat Anda akan bertemu pesan database is locked atau kode SQLITE_BUSY. Pesan itu bukan kerusakan, melainkan cara SQLite mengatakan bahwa proses lain sedang menulis dan giliran Anda belum datang.

Secara bawaan, SQLite memakai rollback journal. Saat menulis, ia menyalin isi lama ke berkas jurnal, lalu mengubah berkas utama. Selama proses itu berlangsung, pembaca harus menunggu.

Di sinilah WAL (Write-Ahead Logging) mengubah keadaan. Pada mode WAL, berkas utama dibiarkan utuh dan perubahan ditambahkan ke berkas terpisah. Hasilnya: pembaca tidak lagi memblokir penulis, dan penulis tidak memblokir pembaca.

Mengaktifkannya cukup satu perintah:

PRAGMA journal_mode=WAL;

Setelan ini permanen: setelah dijalankan sekali, basis data tetap berada dalam mode WAL meskipun ditutup dan dibuka kembali. Anda akan melihat dua berkas pendamping muncul di sebelahnya, yaitu namadb.db-wal dan namadb.db-shm. Keduanya normal.

Yang perlu Anda pahami adalah batas perbaikannya. Mode WAL tidak menghilangkan aturan satu penulis pada satu waktu — dua proses tetap tidak bisa menulis bersamaan. Mode ini juga tidak berjalan di sistem berkas jaringan, karena mekanismenya menuntut memori bersama antar-proses pada mesin yang sama. Untuk transaksi berukuran sangat besar, di atas sekitar 100 MB, performanya justru menurun.

Kapan SQLite Cukup, Kapan Anda Perlu Pindah

Bagian ini yang paling menentukan. Dokumentasi resmi SQLite memberi ambang yang bisa dipegang: situs dengan kurang dari 100 ribu kunjungan per hari umumnya berjalan baik di atas SQLite. Sebagai pembanding nyata, situs sqlite.org sendiri melayani 400 sampai 500 ribu permintaan HTTP per hari. Sekitar 15–20% di antaranya halaman dinamis yang menyentuh basis data.

Angka itu jauh di atas kebutuhan sebagian besar website. Blog, situs perusahaan, portofolio, dan aplikasi internal satu tim semuanya berada jauh di bawah ambang tersebut.

Pohon keputusan memilih SQLite atau basis data server dari kebutuhan akses dan beban tulis.

Empat kondisi berikut menandakan Anda sudah melewati wilayah SQLite:

1. Aplikasi dan data berada di mesin berbeda. Ini alasan paling menentukan. Begitu keduanya terpisah jaringan, keunggulan utama SQLite hilang dan risikonya bertambah.
2. Banyak penulis bersamaan sepanjang waktu. Aplikasi yang didominasi pembacaan tetap nyaman, tetapi beban tulis yang padat dan terus-menerus akan menabrak batas satu penulis.
3. Anda membutuhkan hak akses per pengguna. Kalau beberapa pihak harus punya kewenangan berbeda atas data yang sama, SQLite tidak menyediakan lapisan itu.
4. Anda membutuhkan replikasi bawaan. PostgreSQL dan MySQL menyediakannya sejak awal, SQLite tidak.

Kalau dirangkum berdampingan, perbedaan SQLite dan MySQL terletak pada bentuk pengemasannya, bukan pada model datanya:

Khusus untuk kebutuhan replikasi, ada jalan tengah sebelum bermigrasi penuh. Litestream mereplikasi berkas SQLite secara berkelanjutan ke penyimpanan objek dengan mengalirkan perubahan dari berkas WAL. Satu server tunggal jadi punya cadangan yang selalu mutakhir, tanpa berpindah ke model client-server. Kalau kebutuhan Anda melampaui itu dan menuntut kendali penuh, memasang basis data sendiri di atas VPS Indonesia adalah langkah lanjutan yang wajar.

Menaruh Berkas Basis Data di Hosting: Kesalahan yang Mahal

Ada satu kesalahan yang berulang kali terjadi saat SQLite dipakai untuk website, dan akibatnya berat. Seluruh basis data berupa satu berkas. Menaruhnya di dalam public_html berarti berkas itu bisa diunduh utuh oleh siapa pun yang menebak namanya lewat browser. Nama seperti data.db atau database.sqlite termasuk yang paling mudah ditebak. Sekali berhasil diunduh, seluruh isi basis data Anda berpindah tangan, sebab tidak ada enkripsi bawaan yang menghalangi.

Dua panel: berkas basis data SQLite di dalam public_html bisa diunduh browser, di luar public_html terhalang.

Tiga langkah berikut menutup risiko tersebut:

Langkah #1: Taruh berkas di luar document root

Simpan berkas basis data satu tingkat di atas public_html, misalnya di /home/namauser/data/aplikasi.db. Skrip PHP Anda tetap bisa membacanya lewat jalur berkas di server, sementara browser tidak punya cara untuk mencapainya. Ini pertahanan yang paling menentukan dan paling murah.

Langkah #2: Batasi izin berkas dan pastikan foldernya bisa ditulis

Atur izin berkas ke 0600 supaya hanya pemiliknya yang bisa membaca dan menulis. Perlu diperhatikan bahwa folder tempat berkas berada juga harus bisa ditulis, bukan hanya berkasnya. SQLite membuat berkas jurnal dan berkas WAL di direktori yang sama. Folder yang hanya bisa dibaca akan memunculkan galat menulis meskipun izin berkas basis datanya sudah benar. Ini penyebab kebingungan yang sering muncul saat aplikasi dipindahkan ke hosting.

Langkah #3: Selalu pakai parameterized query

Jangan pernah menyusun perintah SQL dengan menyambung string masukan pengguna. SQLite sama rentannya terhadap SQL injection seperti basis data lain. Pakai prepared statement dengan penanda parameter, dan serahkan penanganan nilainya kepada pustaka.

Selama ketiga langkah itu dijalankan, SQLite berjalan nyaman di shared hosting biasa, karena dukungan PDO SQLite umumnya sudah tersedia di PHP tanpa konfigurasi tambahan.

Mencoba SQLite dalam Beberapa Menit

Di macOS dan sebagian besar distribusi Linux, perintah sqlite3 sudah tersedia tanpa perlu memasang apa pun. Pengguna Windows dapat mengunduh precompiled binaries dari halaman unduhan resmi di sqlite.org, lalu menjalankannya langsung tanpa instalasi.

Buat basis data baru dengan menyebut nama berkasnya. Berkas dibuat otomatis saat tabel pertama ditulis:

sqlite3 catatan.db

Setelah masuk ke prompt sqlite>, buat sebuah tabel dan isi beberapa baris. Operasi dasar ini sama dengan yang Anda kenal sebagai CRUD:

CREATE TABLE catatan (
    id     INTEGER PRIMARY KEY,
    judul  TEXT NOT NULL,
    isi    TEXT
);

INSERT INTO catatan (judul, isi) VALUES ('Belanja', 'Beras, telur, minyak');
INSERT INTO catatan (judul, isi) VALUES ('Rapat', 'Senin pukul 10.00');

SELECT * FROM catatan;

Perhatikan kolom id. Deklarasi INTEGER PRIMARY KEY menjadikannya alias bagi nomor baris internal, sehingga nilainya terisi sendiri secara berurutan tanpa kata kunci tambahan.

Empat perintah titik yang paling sering dipakai: .tables menampilkan daftar tabel, .schema menampilkan struktur tabel, .mode box merapikan hasil menjadi tabel bergaris, dan .quit keluar dari prompt.

Kalau Anda lebih nyaman dengan antarmuka grafis, DB Browser for SQLite adalah pilihan paling umum dan gratis untuk Windows, macOS, dan Linux. Bagi yang sudah memakai DBeaver untuk basis data lain, aplikasi tersebut juga membuka berkas SQLite tanpa driver terpisah. Untuk percobaan cepat tanpa memasang apa pun, tersedia pula editor SQLite online yang berjalan langsung di dalam browser.

Pertanyaan yang Sering Diajukan

Apakah SQLite gratis untuk produk komersial? Ya, sepenuhnya. Kodenya berada di domain publik, sehingga tidak ada lisensi yang perlu dipatuhi dan tidak ada kewajiban mencantumkan atribusi. Ini berlaku pula untuk perangkat lunak berbayar yang kodenya tertutup.

Apakah SQLite termasuk RDBMS? Ya. SQLite adalah sistem manajemen basis data relasional yang menyimpan data dalam tabel dan diakses dengan SQL. Yang membedakannya dari MySQL atau PostgreSQL bukan model datanya, melainkan cara pengemasannya sebagai pustaka tanpa server.

Seberapa besar data yang sanggup ditangani SQLite? Batas teoretisnya 281 terabyte per berkas. Dalam praktiknya, yang lebih dulu menjadi kendala adalah pola aksesnya — jumlah penulis bersamaan dan kebutuhan berbagi data antar-mesin.

Apakah SQLite bisa dipakai untuk website? Bisa, dan untuk sebagian besar website justru memadai. Panduan resminya menyebut situs di bawah 100 ribu kunjungan per hari umumnya berjalan baik. Yang perlu dijaga adalah penempatan berkasnya di luar document root.

Bagaimana cara membuka berkas .db atau .sqlite? Lewat perintah sqlite3 namaberkas.db di terminal, atau lewat aplikasi grafis seperti DB Browser for SQLite dan DBeaver. Berkasnya lintas platform, sehingga berkas dari perangkat Android bisa dibuka di komputer Windows.

Apakah SQLite sama dengan MySQL versi kecil? Tidak. Keduanya memang sama-sama basis data relasional, tetapi dirancang untuk masalah berbeda. MySQL dibuat agar banyak aplikasi berbagi satu kumpulan data lewat jaringan, sedangkan SQLite dibuat agar satu aplikasi menyimpan datanya sendiri secara terstruktur dan andal.

Kesimpulan

SQLite adalah mesin basis data relasional yang tertanam di dalam aplikasi, tanpa server terpisah, dengan seluruh isinya berada dalam satu berkas. Kekuatannya terletak pada kesederhanaan operasional dan keandalan yang teruji ketat, sementara batasannya berpusat pada satu hal: ia dirancang untuk dipakai satu aplikasi di satu mesin.

Pakai SQLite kalau data Anda tidak perlu dibagi ke banyak mesin dan beban tulisnya tidak padat. Untuk aplikasi desktop, aplikasi mobile, alat internal, serta website di bawah 100 ribu kunjungan per hari, ia lebih dari cukup. Pindah ke MySQL atau PostgreSQL kalau aplikasi dan data harus terpisah mesin, penulis bersamaannya banyak, atau Anda membutuhkan hak akses per pengguna dan replikasi bawaan.

Kalau masih ragu, mulai saja dari SQLite. Memindahkan data ke basis data yang lebih besar di kemudian hari jauh lebih mudah daripada mengurus server yang sejak awal tidak Anda butuhkan.

Semoga artikel ini membantu.