SQLite in mobiele ontwikkeling: wat is het en hoe werkt het

Wat is SQLite?

SQLite is een bibliotheek in de programmeertaal C die een relationeel DBMS implementeert zonder toegewijde server. Het wordt direct in de applicatie ingebed, leest en schrijft gegevens naar een gewoon bestand in het bestandssysteem van het apparaat. De bibliotheekgrootte is ongeveer 600 KB, wat SQLite de lichtste volledig functionele SQL-database maakt.

SQLite ondersteunt het grootste deel van de SQL:1999-standaard, inclusief JOIN, subquery’s, triggers, views, indexen en vensterfuncties. Beperkingen hebben betrekking op ALTER TABLE (beperkte ondersteuning) en volledige RIGHT/FULL OUTER JOIN. Desalniettemin is de functionaliteit van SQLite voor mobiele applicaties in 99% van de lokale opslaggevallen voldoende.

Volgens de Stack Overflow-ontwikkelaarsenquête (2025) is SQLite de populairste database voor embedded oplossingen en staat het op de derde plaats qua populariteit onder alle DBMS’en na MySQL en PostgreSQL. In mobiele ontwikkeling wordt SQLite in elke applicatie gebruikt — direct of via wrappers.

Belangrijkste kenmerken van SQLite

Zero-configuration — SQLite vereist geen installatie, configuratie van rechten, aanmaken van gebruikers of het starten van een service. De bibliotheek wordt aan het project gekoppeld en de database wordt aangemaakt door het aanroepen van één functie. Dit vereenvoudigt de implementatie radicaal in vergelijking met client-server DBMS’en, waar installatie van de server, configuratie van poorten en gebruikersconfiguratie vereist zijn.

Het SQLite-databasebestand is een gewoon cross-platform bestand dat kan worden gekopieerd, geanalyseerd, via het netwerk verzonden of hersteld vanuit een back-up. Het bestandsformaat is stabiel op API-niveau: SQLite 3-bestanden die in 2004 zijn gemaakt, worden geopend met de huidige versie van de bibliotheek, wat langdurige gegevenscompatibiliteit garandeert.

Hoe is SQLite gestructureerd: architectuur en opslag

De architectuur van SQLite bestaat uit acht virtuele machines: Tokenizer, Parser, Code Generator, VM, B-Tree, Pager, OS Interface en Utilities. Een SQL-query doorloopt Tokenizer (opsplitsing in tokens), Parser (bouw van AST), Code Generator (conversie naar bytecode) en wordt uitgevoerd op de virtuele machine die gegevenspagina’s leest via B-Tree en Pager.

SQLite gebruikt B-Tree voor het opslaan van tabellen en indexen. Elke tabel wordt opgeslagen als een afzonderlijke B-Tree, waarin de bladknooppunten de gegevensrijen bevatten. Indexen worden ook opgeslagen als B-Tree, maar met sleutels in de bladeren. Pager beheert het laden van pagina’s (standaard 4096 bytes) uit het bestand in het geheugen, waarbij ACID-transacties worden gegarandeerd via journal of WAL.

Journaliseringsmodi

WAL (Write-Ahead Logging) — de aanbevolen modus voor mobiele applicaties. Wijzigingen worden eerst naar een apart WAL-bestand geschreven en vervolgens periodiek overgebracht naar de hoofd database. WAL maakt gelijktijdig lezen uit de database (oude gegevens) en schrijven ernaar (via WAL) mogelijk, wat de prestaties van multi-threaded applicaties verbetert. Het standaard journaal (rollback journal) blokkeert lezen tijdens het schrijven.

Het schakelen tussen modi gebeurt met één SQL-query: PRAGMA journal_mode=WAL. Voor mobiele applicaties met achtergrondsynchronisatie en een UI-thread die gelijktijdig gegevens leest, biedt WAL betere prestaties en geen interfaceblokkering.

SQLite versus andere databases in mobiele ontwikkeling

SQLite is niet de enige optie voor lokale gegevensopslag, maar wel de meest universele. Realm biedt een hogere snelheid van directe toegang tot objecten in het geheugen, maar gebruikt zijn eigen NoSQL-formaat en heeft een grotere bibliotheekomvang. Core Data op iOS is een ORM-laag bovenop SQLite die objectgraafbeheer en het ongedaan maken van bewerkingen toevoegt.

Voor de meeste applicaties blijft SQLite de optimale keuze vanwege voorspelbare prestaties, geen vendor lock-in en in de loop der tijd bewezen stabiliteit. Realm en Core Data zijn gerechtvaardigd in projecten met complexe objectgrafen, reactieve queries of synchronisatievereisten tussen apparaten.

De keuze tussen SQLite, Realm en Core Data hangt af van het platform, de vereisten voor het objectmodel en de synchronisatiestrategie. Voor cross-platform projecten (KMP, Flutter) blijft SQLite de enige universele keuze die op alle doelplatforms werkt zonder wijzigingen in het gegevensmodel.

SQLite op Android: Room en SQLiteOpenHelper

Room — een bibliotheek uit Android Jetpack die een ORM-laag bovenop SQLite biedt. Room genereert automatisch SQL-queries uit geannoteerde DAO-interfaces, controleert de correctheid van queries in de compilatiefase en ondersteunt databasemigraties bij schemawijzigingen. Room is de aanbevolen manier om met SQLite op Android te werken.

SQLiteOpenHelper — een low-level API voor direct beheer van SQLite zonder ORM. De klasse beheert het aanmaken, openen en bijwerken van de database. SQLiteOpenHelper is geschikt voor projecten met eenvoudige SQL-queries of wanneer volledige controle over de SQL-logica zonder Room-abstrahering nodig is.

Voorbeeld van entiteit en DAO voor Room

De entiteit in Room wordt geannoteerd met @Entity en DAO met @Dao. Room vertaalt geannoteerde methoden naar SQL-queries: @Insert genereert INSERT, @Query — SELECT met opgegeven SQL. Migraties worden toegevoegd via Migration met opgave van de oude en nieuwe schemaversie. Room controleert SQL in de compilatiefase, wat syntaxisfouten in productie elimineert.

@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 genereert automatisch de implementatie van UserDao_Impl, die runtime-queries naar SQLite bevat via de interne RoomDatabase. Dankzij coroutines (suspend) worden DAO-methoden asynchroon op de achtergrondthread uitgevoerd zonder de UI te blokkeren. Flow-retourtypen in @Query werken het resultaat automatisch bij bij wijziging van de tabel.

SQLite op iOS: FMDB en GRDB

FMDB — een Objective-C-wrapper bovenop de SQLite C API, historisch gezien de eerste populaire bibliotheek voor iOS. Het biedt FMDatabase- en FMResultSet-objecten voor het uitvoeren van queries en het verkrijgen van resultaten. FMDB is eenvoudig en minimalistisch, maar ondersteunt geen Swift-specifieke constructies — optionals, Codable, async/await.

GRDB — een moderne Swift-bibliotheek voor het werken met SQLite. Het biedt een type-safe API, ondersteuning voor Codable, Combine Publishers, async/await, migraties en real-time wijzigingsregistratie. GRDB heeft de voorkeur voor nieuwe Swift-projecten vanwege volledige integratie met Swift Concurrency en betere codeleesbaarheid.

GRDB-voorbeeld in Swift

GRDB definieert tabellen via Record-klassen die voldoen aan de protocollen FetchableRecord en TableRecord. Queries worden geschreven in Swift met type-safe syntax, niet in ruwe SQL. GRDB ondersteunt ook DatabaseMigrator voor schema-versiebeheer en migraties tussen applicatieversies.

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 gebruikt de WAL-modus van SQLite voor gelijktijdig lezen. Meerdere lezers kunnen tegelijkertijd toegang krijgen tot de database, terwijl één schrijver gegevens bijwerkt via WAL. GRDB beheert automatisch verbindingen en transacties, wat thread-safe toegang tot de database vanuit elke thread biedt zonder handmatige synchronisatie.

Prestatieoptimalisatie van SQLite

Indexen — de meest effectieve manier om SQLite-queries te versnellen. Een index wordt aangemaakt op kolommen die deelnemen aan WHERE, JOIN en ORDER BY. Voor een tabel met 100.000 records duurt zoeken op een geïndexeerde kolom milliseconden in plaats van seconden. Indexen vertragen echter INSERT en UPDATE, dus hun aantal moet in evenwicht zijn met de schrijffrequentie.

Batchinvoeging (batch insert) in het kader van één transactie versnelt massaal gegevens laden radicaal. Het invoegen van 1000 records één voor één geeft een overhead van ~1 seconde. Dezelfde 1000 records in één transactie — ~5–10 milliseconden. Het verschil wordt verklaard doordat elke afzonderlijke INSERT een nieuwe transactie creëert met synchrone schrijfactie naar schijf.

Prestatie-PRAGMA’s

PRAGMA — SQLite-commando’s voor het configureren van het bibliotheekgedrag. Belangrijke optimalisatie-PRAGMA’s: PRAGMA synchronous=NORMAL (vermindert fsync-frequentie), PRAGMA cache_size=-8000 (wijst 8 MB cache toe), PRAGMA temp_store=MEMORY (tijdelijke tabellen in geheugen). Voor mobiele applicaties met grote gegevensvolumes versnelt de combinatie van deze PRAGMA’s queries 2–3 keer.

Een andere belangrijke optimalisatie is voorcompilatie van SQL-queries (prepared statements). Als een query meerdere keren wordt uitgevoerd (bijvoorbeeld het invoegen van 10.000 rijen), vermindert eenmalige compilatie van SQL en vervolgens gebruik van de statement de CPU-belasting met 30–50%. Room en GRDB cachen automatisch prepared statements, maar bij direct gebruik van de SQLite C API moet compilatie handmatig worden uitgevoerd.

class UserRepository(private val db: RoomDatabase) {

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

Batchinvoeging met withTransaction garandeert dat alle INSERTs binnen één transactie worden uitgevoerd. Opsplitsing in subbatches (chunked) voorkomt een te grote transactie die andere threads langdurig zou kunnen blokkeren. Voor achtergrondsynchronisatie biedt een subbatchgrootte van 500 records de optimale balans tussen snelheid en UI-responsiviteit.