SQLite in der mobilen Entwicklung: Was es ist und wie es funktioniert

Was ist SQLite?

SQLite ist eine in C geschriebene Bibliothek, die ein relationales DBMS ohne dedizierten Server implementiert. Es wird direkt in die Anwendung eingebettet und liest und schreibt Daten in eine gewöhnliche Datei im Dateisystem des Geräts. Die Bibliotheksgröße beträgt etwa 600 KB, was SQLite zur leichtesten voll funktionsfähigen SQL-Datenbank macht.

SQLite unterstützt den größten Teil des SQL:1999-Standards, einschließlich JOIN, Unterabfragen, Trigger, Views, Indizes und Fensterfunktionen. Die Einschränkungen betreffen ALTER TABLE (eingeschränkte Unterstützung) und vollständige RIGHT/FULL OUTER JOIN. Dennoch ist die Funktionalität von SQLite für mobile Anwendungen in 99% der Fälle lokaler Speicherung ausreichend.

Laut der Stack Overflow-Entwicklerumfrage (2025) ist SQLite die beliebteste Datenbank für eingebettete Lösungen und belegt nach MySQL und PostgreSQL den dritten Platz in der Beliebtheit aller DBMS. In der mobilen Entwicklung wird SQLite in jeder Anwendung verwendet – entweder direkt oder über Wrapper.

Hauptmerkmale von SQLite

Null-Konfiguration – SQLite erfordert keine Installation, Berechtigungseinrichtung, Benutzererstellung oder Dienststart. Die Bibliothek wird mit dem Projekt verknüpft und die Datenbank wird durch Aufruf einer einzigen Funktion erstellt. Dies vereinfacht die Bereitstellung im Vergleich zu Client-Server-DBMS radikal, die Serverinstallation, Portkonfiguration und Benutzereinrichtung erfordern.

Die SQLite-Datenbankdatei ist eine gewöhnliche plattformübergreifende Datei, die kopiert, analysiert, über das Netzwerk gesendet oder aus einem Backup wiederhergestellt werden kann. Das Dateiformat ist auf API-Ebene stabil: SQLite 3-Dateien, die 2004 erstellt wurden, werden mit der aktuellen Version der Bibliothek geöffnet, was langfristige Datenkompatibilität gewährleistet.

Wie SQLite funktioniert: Architektur und Speicherung

Die Architektur von SQLite besteht aus acht virtuellen Maschinen: Tokenizer, Parser, Code Generator, VM, B-Tree, Pager, OS Interface und Utilities. Eine SQL-Abfrage durchläuft den Tokenizer (Aufteilung in Token), den Parser (Erstellung eines AST), den Code Generator (Umwandlung in Bytecode) und wird auf der virtuellen Maschine ausgeführt, die Daten Seiten über B-Tree und Pager liest.

SQLite verwendet B-Tree zum Speichern von Tabellen und Indizes. Jede Tabelle wird als separater B-Tree gespeichert, wobei die Blattknoten die Datenzeilen enthalten. Indizes werden ebenfalls als B-Trees gespeichert, jedoch mit Schlüsseln in den Blättern. Der Pager verwaltet das Laden von Seiten (Standard 4096 Byte) aus der Datei in den Speicher und stellt ACID-Transaktionen über ein Journal oder WAL bereit.

Journaling-Modi

WAL (Write-Ahead Logging) ist der empfohlene Modus für mobile Anwendungen. Änderungen werden zunächst in eine separate WAL-Datei geschrieben und dann regelmäßig in die Hauptdatenbank übertragen. WAL ermöglicht gleichzeitiges Lesen (alte Daten) und Schreiben (über WAL) in der Datenbank, was die Leistung von Multithread-Anwendungen verbessert. Das Standardjournal (Rollback-Journal) blockiert das Lesen während des Schreibens.

Das Umschalten zwischen den Modi erfolgt mit einer einzigen SQL-Abfrage: PRAGMA journal_mode=WAL. Für mobile Anwendungen mit Hintergrundsynchronisation und einem gleichzeitig Daten lesenden UI-Thread bietet WAL eine bessere Leistung und keine Oberflächenblockaden.

SQLite vs andere Datenbanken in der mobilen Entwicklung

SQLite ist nicht die einzige Option für die lokale Datenspeicherung, aber die vielseitigste. Realm bietet eine höhere Geschwindigkeit beim direkten Zugriff auf Objekte im Speicher, verwendet jedoch ein eigenes NoSQL-Format und hat eine größere Bibliotheksgröße. Core Data auf iOS ist eine ORM-Schicht über SQLite, die Objektgraphenverwaltung und Rückgängigmachen von Operationen hinzufügt.

Für die meisten Anwendungen bleibt SQLite aufgrund der vorhersagbaren Leistung, fehlendem Vendor Lock-in und zeitlich erprobter Stabilität die optimale Wahl. Realm und Core Data sind bei Projekten mit komplexen Objektgraphen, reaktiven Abfragen oder Synchronisierungsanforderungen zwischen Geräten gerechtfertigt.

Die Wahl zwischen SQLite, Realm und Core Data hängt von der Plattform, den Objektmodellanforderungen und der Synchronisierungsstrategie ab. Für plattformübergreifende Projekte (KMP, Flutter) bleibt SQLite die einzige universelle Wahl, die auf allen Zielplattformen ohne Änderungen am Datenmodell funktioniert.

SQLite auf Android: Room und SQLiteOpenHelper

Room ist eine Bibliothek aus Android Jetpack, die eine ORM-Schicht über SQLite bereitstellt. Room generiert automatisch SQL-Abfragen aus annotierten DAO-Schnittstellen, validiert die Korrektheit der Abfragen zur Kompilierzeit und unterstützt Datenbankmigrationen bei Schemaänderungen. Room ist die empfohlene Methode für die Arbeit mit SQLite auf Android.

SQLiteOpenHelper ist eine Low-Level-API für die direkte SQLite-Verwaltung ohne ORM. Die Klasse verwaltet das Erstellen, Öffnen und Aktualisieren der Datenbank. SQLiteOpenHelper eignet sich für Projekte mit einfachen SQL-Abfragen oder wenn die volle Kontrolle über die SQL-Logik ohne Room-Abstraktion benötigt wird.

Beispiel für Entität und DAO für Room

Eine Entität in Room wird mit @Entity annotiert, ein DAO mit @Dao. Room übersetzt annotierte Methoden in SQL-Abfragen: @Insert generiert INSERT, @Query generiert SELECT mit angegebenem SQL. Migrationen werden über Migration mit Angabe der alten und neuen Schema-Version hinzugefügt. Room validiert SQL zur Kompilierzeit, wodurch Syntaxfehler in der Produktion eliminiert werden.

@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 generiert automatisch die UserDao_Impl-Implementierung, die Laufzeit-SQLite-Abfragen über die interne RoomDatabase enthält. Dank Coroutinen (suspend) werden DAO-Methoden asynchron auf einem Hintergrundthread ausgeführt, ohne die UI zu blockieren. Flow-Rückgabetypen in @Query aktualisieren das Ergebnis automatisch, wenn sich die Tabelle ändert.

SQLite auf iOS: FMDB und GRDB

FMDB ist ein Objective-C-Wrapper über die SQLite-C-API, historisch gesehen die erste populäre Bibliothek für iOS. Sie stellt FMDatabase- und FMResultSet-Objekte zum Ausführen von Abfragen und Abrufen von Ergebnissen bereit. FMDB ist einfach und minimalistisch, unterstützt jedoch keine Swift-spezifischen Konstrukte – Optionals, Codable, async/await.

GRDB ist eine moderne Swift-Bibliothek für die Arbeit mit SQLite. Sie bietet eine typsichere API, Codable-Unterstützung, Combine Publishers, async/await, Migrationen und Echtzeit-Änderungsbeobachtung. GRDB wird für neue Swift-Projekte aufgrund der vollständigen Integration mit Swift Concurrency und besserer Lesbarkeit des Codes bevorzugt.

GRDB-Beispiel in Swift

GRDB definiert Tabellen über Record-Klassen, die den Protokollen FetchableRecord und TableRecord entsprechen. Abfragen werden in Swift mit typsicherer Syntax anstelle von rohem SQL geschrieben. GRDB unterstützt auch DatabaseMigrator für die Schema-Versionierung und Migrationen zwischen App-Versionen.

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 verwendet den WAL-Modus von SQLite für gleichzeitiges Lesen. Mehrere Leser können gleichzeitig auf die Datenbank zugreifen, während ein einzelner Schreiber Daten über WAL aktualisiert. GRDB verwaltet Verbindungen und Transaktionen automatisch und bietet thread-sicheren Datenbankzugriff von jedem Thread ohne manuelle Synchronisation.

SQLite-Leistungsoptimierung

Indizes sind die effektivste Methode, um SQLite-Abfragen zu beschleunigen. Ein Index wird auf Spalten erstellt, die in WHERE-, JOIN- und ORDER-BY-Klauseln verwendet werden. Bei einer Tabelle mit 100000 Datensätzen dauert die Suche über eine indizierte Spalte Millisekunden statt Sekunden. Allerdings verlangsamen Indizes INSERT- und UPDATE-Operationen, daher sollte ihre Anzahl mit der Schreibhäufigkeit ausbalanciert sein.

Die Stapelverarbeitung (Batch Insert) innerhalb einer einzelnen Transaktion beschleunigt das Massenladen von Daten radikal. Das Einfügen von 1000 Datensätzen einzeln verursacht einen Overhead von etwa 1 Sekunde. Dieselben 1000 Datensätze in einer einzigen Transaktion dauern etwa 5-10 Millisekunden. Der Unterschied erklärt sich dadurch, dass jedes einzelne INSERT eine neue Transaktion mit synchronem Schreiben auf die Festplatte erzeugt.

Leistungs-PRAGMAs

PRAGMA sind SQLite-Befehle zur Konfiguration des Bibliotheksverhaltens. Wichtige Optimierungs-Pragmas: PRAGMA synchronous=NORMAL (reduziert die fsync-Häufigkeit), PRAGMA cache_size=-8000 (weist 8 MB Cache zu), PRAGMA temp_store=MEMORY (temporäre Tabellen im Speicher). Für mobile Anwendungen mit großen Datenmengen beschleunigt die Kombination dieser Pragmas Abfragen um das 2- bis 3-fache.

Eine weitere wichtige Optimierung ist die Vorkompilierung von SQL-Abfragen (Prepared Statements). Wenn eine Abfrage wiederholt ausgeführt wird (z.B. Einfügen von 10000 Zeilen), reduziert das einmalige Kompilieren von SQL und die Wiederverwendung der Anweisung die CPU-Last um 30-50%. Room und GRDB cachen Prepared Statements automatisch, aber bei direkter Verwendung der SQLite-C-API muss die Kompilierung manuell erfolgen.

class UserRepository(private val db: RoomDatabase) {

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

Das Batch-Insert mit withTransaction stellt sicher, dass alle INSERT-Operationen innerhalb einer einzigen Transaktion ausgeführt werden. Die Aufteilung in Unterbatches (chunked) verhindert, dass eine einzelne Transaktion zu groß wird und andere Threads über einen längeren Zeitraum blockiert. Für die Hintergrundsynchronisation bietet eine Unterbatch-Größe von 500 Datensätzen das optimale Gleichgewicht zwischen Geschwindigkeit und UI-Reaktionsfähigkeit.