SQLite i mobil utveckling: vad är det och hur fungerar det

Vad är SQLite?

SQLite är ett bibliotek i programmeringsspråket C som implementerar ett relations-DBMS utan dedikerad server. Det är direkt inbäddat i applikationen, läser och skriver data till en vanlig fil i enhetens filsystem. Biblioteksstorleken är cirka 600 KB, vilket gör SQLite till den lättaste fullt funktionella SQL-databasen.

SQLite stödjer större delen av SQL:1999-standarden, inklusive JOIN, underfrågor, utlösare, vyer, index och fönsterfunktioner. Begränsningarna gäller ALTER TABLE (begränsat stöd) och fullständiga RIGHT/FULL OUTER JOIN. Ändå är SQLites funktionalitet tillräcklig för mobila applikationer i 99% av fallen av lokal lagring.

Enligt Stack Overflow-utvecklarenkäten (2025) är SQLite den mest populära databasen för inbäddade lösningar och rankas trea i popularitet bland alla DBMS efter MySQL och PostgreSQL. Inom mobil utveckling används SQLite i varje applikation — direkt eller genom omslag.

Nyckelegenskaper hos SQLite

Zero-configuration — SQLite kräver ingen installation, konfiguration av behörigheter, skapande av användare eller start av tjänst. Biblioteket kopplas till projektet och databasen skapas genom att anropa en funktion. Detta förenklar driftsättningen radikalt jämfört med klient-server-DBMS som kräver serverinstallation, portkonfiguration och användarkonfiguration.

SQLite-databasfilen är en vanlig plattformsoberoende fil som kan kopieras, analyseras, skickas över nätverket eller återställas från en säkerhetskopia. Filformatet är stabilt på API-nivå: SQLite 3-filer skapade 2004 öppnas med aktuell biblioteksversion, vilket garanterar långsiktig datakompatibilitet.

Hur är SQLite strukturerat: arkitektur och lagring

Arkitekturen i SQLite består av åtta virtuella maskiner: Tokenizer, Parser, Code Generator, VM, B-Tree, Pager, OS Interface och Utilities. En SQL-fråga går igenom Tokenizer (uppdelning i token), Parser (byggande av AST), Code Generator (omvandling till bytekod) och exekveras på den virtuella maskinen som läser datasidor via B-Tree och Pager.

SQLite använder B-Tree för lagring av tabeller och index. Varje tabell lagras som ett separat B-Tree, där bladnoderna innehåller datarader. Index lagras också som B-Tree, men med nycklar i bladen. Pager hanterar inläsning av sidor (standard 4096 byte) från filen till minnet, vilket säkerställer ACID-transaktioner genom journal eller WAL.

Journalföringsmetoder

WAL (Write-Ahead Logging) — rekommenderat läge för mobila applikationer. Ändringar skrivs först till en separat WAL-fil och överförs sedan periodiskt till huvuddatabasen. WAL möjliggör samtidig läsning från databasen (gamla data) och skrivning till den (via WAL), vilket förbättrar prestandan för flertrådade applikationer. Standardjournalen (rollback journal) blockerar läsning under skrivning.

Växling mellan lägena görs med en SQL-fråga: PRAGMA journal_mode=WAL. För mobila applikationer med bakgrundssynkronisering och en UI-tråd som samtidigt läser data ger WAL bättre prestanda och inget blockerande av gränssnittet.

SQLite jämfört med andra databaser i mobil utveckling

SQLite är inte det enda alternativet för lokal datalagring, men det är det mest universella. Realm erbjuder högre hastighet för direkt åtkomst till objekt i minnet, men använder ett eget NoSQL-format och har större biblioteksstorlek. Core Data på iOS är ett ORM-lager ovanpå SQLite som lägger till objekthanthantering och ångring av operationer.

För de flesta applikationer förblir SQLite det optimala valet tack vare förutsägbar prestanda, ingen inlåsningseffekt och tidsprövad stabilitet. Realm och Core Data är motiverade i projekt med komplexa objektdiagram, reaktiva frågor eller synkroniseringskrav mellan enheter.

Valet mellan SQLite, Realm och Core Data beror på plattform, objektmodellkrav och synkroniseringsstrategi. För plattformsoberoende projekt (KMP, Flutter) förblir SQLite det enda universella valet som fungerar på alla målplattformar utan ändringar i datamodellen.

SQLite på Android: Room och SQLiteOpenHelper

Room — ett bibliotek från Android Jetpack som tillhandahåller ett ORM-lager ovanpå SQLite. Room genererar automatiskt SQL-frågor från annoterade DAO-gränssnitt, kontrollerar frågornas korrekthet vid kompilering och stödjer databasmigreringar vid schemaändringar. Room är det rekommenderade sättet att arbeta med SQLite på Android.

SQLiteOpenHelper — ett lågnivå-API för direkt hantering av SQLite utan ORM. Klassen hanterar skapande, öppnande och uppdatering av databasen. SQLiteOpenHelper är lämpligt för projekt med enkla SQL-frågor eller när full kontroll över SQL-logiken utan Room-abstraktion behövs.

Exempel på entitet och DAO för Room

Entiteten i Room annoteras med @Entity och DAO med @Dao. Room översätter annoterade metoder till SQL-frågor: @Insert genererar INSERT, @Query — SELECT med angiven SQL. Migreringar läggs till via Migration med angivande av gammal och ny schemaversion. Room kontrollerar SQL vid kompilering, vilket eliminerar syntaxfel i produktion.

@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 genererar automatiskt implementeringen UserDao_Impl, som innehåller körningsfrågor till SQLite via den interna RoomDatabase. Tack vare korutiner (suspend) körs DAO-metoder asynkront på bakgrundstråden utan att blockera UI. Flow-returtyper i @Query uppdaterar automatiskt resultatet när tabellen ändras.

SQLite på iOS: FMDB och GRDB

FMDB — ett Objective-C-omslag ovanpå SQLites C-API, historiskt det första populära biblioteket för iOS. Det tillhandahåller FMDatabase- och FMResultSet-objekt för att köra frågor och hämta resultat. FMDB är enkelt och minimalistiskt men stödjer inte Swift-specifika konstruktioner — optionals, Codable, async/await.

GRDB — ett modernt Swift-bibliotek för arbete med SQLite. Det erbjuder type-safe API, stöd för Codable, Combine Publishers, async/await, migreringar och realtidsövervakning av ändringar. GRDB föredras för nya Swift-projekt tack vare full integration med Swift Concurrency och bättre kodläsbarhet.

GRDB-exempel i Swift

GRDB definierar tabeller via Record-klasser som följer protokollen FetchableRecord och TableRecord. Frågor skrivs i Swift med type-safe syntax, inte i rå SQL. GRDB stödjer även DatabaseMigrator för versionshantering av schemat och migreringar mellan appversioner.

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 använder SQLites WAL-läge för samtidig läsning. Flera läsare kan samtidigt komma åt databasen medan en skribent uppdaterar data via WAL. GRDB hanterar automatiskt anslutningar och transaktioner, vilket ger trådsäker åtkomst till databasen från vilken tråd som helst utan manuell synkronisering.

Prestandaoptimering av SQLite

Index — det effektivaste sättet att snabba upp SQLite-frågor. Ett index skapas på kolumner som deltar i WHERE, JOIN och ORDER BY. För en tabell med 100 000 poster tar sökning på en indexerad kolumn millisekunder istället för sekunder. Index saktar dock ner INSERT och UPDATE, så deras antal måste balanseras med skrivfrekvensen.

Batchinsättning (batch insert) inom en enda transaktion snabbar upp massiv datainläsning radikalt. Att infoga 1000 poster en och en ger en overhead på cirka 1 sekund. Samma 1000 poster i en transaktion — cirka 5–10 millisekunder. Skillnaden förklaras av att varje enskild INSERT skapar en ny transaktion med synkron skrivning till disk.

Prestanda-PRAGMA

PRAGMA — SQLite-kommandon för att konfigurera bibliotekets beteende. Viktiga optimerings-PRAGMA: PRAGMA synchronous=NORMAL (minskar fsync-frekvens), PRAGMA cache_size=-8000 (allokerar 8 MB cache), PRAGMA temp_store=MEMORY (temporära tabeller i minnet). För mobila applikationer med stora datavolymer snabbar kombinationen av dessa PRAGMA upp frågor 2–3 gånger.

En annan viktig optimering är förkompilering av SQL-frågor (prepared statements). Om en fråga körs upprepade gånger (t.ex. insättning av 10 000 rader) minskar en engångskompilering av SQL och sedan användning av statement CPU-belastningen med 30–50%. Room och GRDB cachar automatiskt prepared statements, men vid direkt användning av SQLite C-API måste kompileringen göras manuellt.

class UserRepository(private val db: RoomDatabase) {

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

Batchinsättning med withTransaction garanterar att alla INSERT körs inom en enda transaktion. Uppdelning i underbatchar (chunked) förhindrar en alltför stor transaktion som skulle kunna blockera andra trådar under längre tid. För bakgrundssynkronisering ger en underbatchstorlek på 500 poster optimal balans mellan hastighet och UI-svarstid.