SQLite dalam pengembangan mobile: apa itu dan cara kerjanya

Apa itu SQLite?

SQLite adalah pustaka dalam bahasa C yang mengimplementasikan DBMS relasional tanpa server khusus. Pustaka ini tertanam langsung ke dalam aplikasi, membaca dan menulis data ke file biasa di sistem file perangkat. Ukuran pustaka sekitar 600 KB, menjadikan SQLite database SQL paling ringan yang berfungsi penuh.

SQLite mendukung sebagian besar standar SQL:1999, termasuk JOIN, subkueri, pemicu, tampilan, indeks, dan fungsi jendela. Keterbatasan terkait ALTER TABLE (dukungan terbatas) dan RIGHT/FULL OUTER JOIN penuh. Meskipun demikian, untuk aplikasi mobile, fungsionalitas SQLite cukup dalam 99% kasus penyimpanan lokal.

Menurut survei pengembang Stack Overflow (2025), SQLite adalah database paling populer untuk solusi tertanam dan menempati peringkat ketiga dalam popularitas di antara semua DBMS setelah MySQL dan PostgreSQL. Dalam pengembangan mobile, SQLite digunakan di setiap aplikasi — secara langsung atau melalui pembungkus.

Karakteristik Utama SQLite

Zero-configuration — SQLite tidak memerlukan instalasi, konfigurasi izin, pembuatan pengguna, atau memulai layanan. Pustaka dihubungkan ke proyek, dan database dibuat dengan memanggil satu fungsi. Ini secara radikal menyederhanakan penerapan dibandingkan dengan DBMS klien-server yang memerlukan instalasi server, konfigurasi port, dan konfigurasi pengguna.

File database SQLite adalah file lintas platform biasa yang dapat disalin, dianalisis, dikirim melalui jaringan, atau dipulihkan dari cadangan. Format file stabil di tingkat API: file SQLite 3 yang dibuat pada tahun 2004 dapat dibuka dengan versi pustaka saat ini, yang menjamin kompatibilitas data jangka panjang.

Bagaimana SQLite terstruktur: arsitektur dan penyimpanan

Arsitektur SQLite terdiri dari delapan mesin virtual: Tokenizer, Parser, Code Generator, VM, B-Tree, Pager, OS Interface, dan Utilities. Kueri SQL melewati Tokenizer (pemecahan menjadi token), Parser (pembangunan AST), Code Generator (konversi ke kode byte) dan dijalankan pada mesin virtual yang membaca halaman data melalui B-Tree dan Pager.

SQLite menggunakan B-Tree untuk menyimpan tabel dan indeks. Setiap tabel disimpan sebagai B-Tree terpisah, di mana simpul daun berisi baris data. Indeks juga disimpan sebagai B-Tree, tetapi dengan kunci di daun. Pager mengelola pemuatan halaman (standar 4096 byte) dari file ke memori, memastikan transaksi ACID melalui jurnal atau WAL.

Mode Pencatatan

WAL (Write-Ahead Logging) — mode yang direkomendasikan untuk aplikasi mobile. Perubahan pertama-tama ditulis ke file WAL terpisah, kemudian secara periodik dipindahkan ke database utama. WAL memungkinkan pembacaan simultan dari database (data lama) dan penulisan ke dalamnya (melalui WAL), yang meningkatkan kinerja aplikasi multi-thread. Jurnal standar (rollback journal) memblokir pembacaan selama penulisan.

Peralihan antar mode dilakukan dengan satu kueri SQL: PRAGMA journal_mode=WAL. Untuk aplikasi mobile dengan sinkronisasi latar belakang dan thread UI yang membaca data secara simultan, WAL memberikan kinerja lebih baik dan tanpa pemblokiran antarmuka.

SQLite vs database lain dalam pengembangan mobile

SQLite bukan satu-satunya opsi untuk penyimpanan data lokal, tetapi yang paling universal. Realm menawarkan kecepatan lebih tinggi dalam akses langsung ke objek di memori, tetapi menggunakan format NoSQL sendiri dan memiliki ukuran pustaka yang lebih besar. Core Data di iOS adalah lapisan ORM di atas SQLite yang menambahkan manajemen graf objek dan pembatalan operasi.

Untuk sebagian besar aplikasi, SQLite tetap menjadi pilihan optimal berkat kinerja yang dapat diprediksi, tanpa ketergantungan vendor, dan stabilitas yang teruji waktu. Realm dan Core Data dibenarkan dalam proyek dengan graf objek kompleks, kueri reaktif, atau kebutuhan sinkronisasi antar perangkat.

Pilihan antara SQLite, Realm, dan Core Data tergantung pada platform, kebutuhan model objek, dan strategi sinkronisasi. Untuk proyek lintas platform (KMP, Flutter), SQLite tetap menjadi satu-satunya pilihan universal yang berfungsi di semua platform target tanpa perubahan pada model data.

SQLite di Android: Room dan SQLiteOpenHelper

Room — pustaka dari Android Jetpack yang menyediakan lapisan ORM di atas SQLite. Room secara otomatis menghasilkan kueri SQL dari antarmuka DAO yang dianotasi, memeriksa kebenaran kueri pada tahap kompilasi, dan mendukung migrasi database saat perubahan skema. Room adalah cara yang direkomendasikan untuk bekerja dengan SQLite di Android.

SQLiteOpenHelper — API tingkat rendah untuk manajemen langsung SQLite tanpa ORM. Kelas ini mengelola pembuatan, pembukaan, dan pembaruan database. SQLiteOpenHelper cocok untuk proyek dengan kueri SQL sederhana atau ketika kontrol penuh atas logika SQL tanpa abstraksi Room diperlukan.

Contoh entitas dan DAO untuk Room

Entitas di Room dianotasi dengan @Entity, dan DAO dengan @Dao. Room menerjemahkan metode yang dianotasi menjadi kueri SQL: @Insert menghasilkan INSERT, @Query — SELECT dengan SQL yang ditentukan. Migrasi ditambahkan melalui Migration dengan menentukan versi skema lama dan baru. Room memeriksa SQL pada tahap kompilasi, yang menghilangkan kesalahan sintaks di produksi.

@Entity
data class User(
    @PrimaryKey val id: Long,
    val name: String,
    @ColumnInfo(name = "created_at")
    val createdAt: Long
)

@Dao
interface UserDao {
    @Query("SELECT * FROM user ORDER BY name ASC")
    suspend fun getAllUsers(): List<User>

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertUser(user: User)

    @Query("DELETE FROM user WHERE id = :id")
    suspend fun deleteUser(id: Long)
}

Room secara otomatis menghasilkan implementasi UserDao_Impl, yang berisi kueri runtime ke SQLite melalui RoomDatabase internal. Berkat coroutine (suspend), metode DAO dijalankan secara asinkron di thread latar belakang tanpa memblokir UI. Tipe kembalian Flow di @Query secara otomatis memperbarui hasil saat tabel berubah.

SQLite di iOS: FMDB dan GRDB

FMDB — pembungkus Objective-C di atas C API SQLite, secara historis pustaka populer pertama untuk iOS. Menyediakan objek FMDatabase dan FMResultSet untuk menjalankan kueri dan mendapatkan hasil. FMDB sederhana dan minimalis, tetapi tidak mendukung konstruksi khusus Swift — optional, Codable, async/await.

GRDB — pustaka Swift modern untuk bekerja dengan SQLite. Menyediakan API type-safe, dukungan Codable, Combine Publishers, async/await, migrasi, dan pemantauan perubahan waktu nyata. GRDB lebih disukai untuk proyek baru di Swift berkat integrasi penuh dengan Swift Concurrency dan keterbacaan kode yang lebih baik.

Contoh GRDB di Swift

GRDB mendefinisikan tabel melalui kelas Record yang sesuai dengan protokol FetchableRecord dan TableRecord. Kueri ditulis dalam Swift dengan sintaks type-safe, bukan SQL mentah. GRDB juga mendukung DatabaseMigrator untuk versi skema dan migrasi antar versi aplikasi.

struct User: Codable, FetchableRecord, TableRecord {
    var id: Int64
    var name: String
    var createdAt: Date
}

let dbPool = try DatabasePool(path: dbPath)
var migrator = DatabaseMigrator()
migrator.registerMigration("v1") { db in
    try db.create(table: "user") { t in
        t.autoIncrementedPrimaryKey("id")
        t.column("name", .text).notNull()
        t.column("createdAt", .datetime).notNull()
    }
}

let users = try await dbPool.read { db in
    try User.order(Column("name")).fetchAll(db)
}

DatabasePool menggunakan mode WAL SQLite untuk pembacaan konkuren. Banyak pembaca dapat mengakses database secara bersamaan, sementara satu penulis memperbarui data melalui WAL. GRDB secara otomatis mengelola koneksi dan transaksi, menyediakan akses thread-safe ke database dari thread mana pun tanpa sinkronisasi manual.

Optimasi kinerja SQLite

Indeks — cara paling efektif untuk mempercepat kueri SQLite. Indeks dibuat pada kolom yang berpartisipasi dalam WHERE, JOIN, dan ORDER BY. Untuk tabel dengan 100.000 catatan, pencarian pada kolom yang diindeks membutuhkan milidetik, bukan detik. Namun, indeks memperlambat INSERT dan UPDATE, sehingga jumlahnya harus seimbang dengan frekuensi penulisan.

Penyisipan batch (batch insert) dalam satu transaksi secara radikal mempercepat pemuatan data massal. Menyisipkan 1000 catatan satu per satu memberikan overhead ~1 detik. 1000 catatan yang sama dalam satu transaksi — ~5–10 milidetik. Perbedaan ini dijelaskan oleh fakta bahwa setiap INSERT terpisah membuat transaksi baru dengan penulisan sinkron ke disk.

PRAGMA kinerja

PRAGMA — perintah SQLite untuk mengonfigurasi perilaku pustaka. PRAGMA optimasi utama: PRAGMA synchronous=NORMAL (mengurangi frekuensi fsync), PRAGMA cache_size=-8000 (mengalokasikan 8 MB cache), PRAGMA temp_store=MEMORY (tabel sementara di memori). Untuk aplikasi mobile dengan volume data besar, kombinasi PRAGMA ini mempercepat kueri 2–3 kali lipat.

Optimasi penting lainnya adalah kompilasi awal kueri SQL (prepared statements). Jika kueri dijalankan berulang kali (misalnya, menyisipkan 10.000 baris), kompilasi SQL sekali dan kemudian menggunakan pernyataan tersebut mengurangi beban CPU sebesar 30–50%. Room dan GRDB secara otomatis menyimpan cache prepared statements, tetapi saat menggunakan C API SQLite secara langsung, kompilasi harus dilakukan secara manual.

class UserRepository(private val db: RoomDatabase) {

    suspend fun insertBatch(users: List<User>) {
        db.withTransaction {
            users.chunked(500).forEach { batch ->
                batch.forEach { user ->
                    insertUser(user)
                }
            }
        }
    }
}

Penyisipan batch dengan withTransaction menjamin bahwa semua INSERT dijalankan dalam satu transaksi. Pemecahan menjadi sub-batch (chunked) mencegah transaksi yang terlalu besar yang dapat memblokir thread lain untuk waktu yang lama. Untuk sinkronisasi latar belakang, ukuran sub-batch 500 catatan memberikan keseimbangan optimal antara kecepatan dan responsivitas UI.