Welche lokale Datenbank passt zu deiner App? Ein praxisnaher Überblick

Lokale Datenbanken sind heute Standard – egal ob Mobile App, Desktop-Tool, Edge-Device oder Browser-App. Die Frage ist selten ob du lokal speichern willst, sondern was du genau brauchst: Performance, Sync, SQL-Kontrolle, Web-Support oder absolute Einfachheit?

Der schnellste Weg zur Entscheidung führt über konkrete Szenarien. Finde deinen Use Case – die passende Library ergibt sich daraus fast von selbst.

Hive – Key/Value für kleine Datenmengen

Dein Szenario: Du speicherst Einstellungen, Theme-Präferenzen, kleine User-Profile oder cached API-Responses. Die Datenstruktur ist überschaubar, Relationen spielen keine Rolle.

Hive ist ein leichtgewichtiger Key/Value-Store, der in reinem Dart geschrieben ist. Daten werden in Boxen organisiert – typisierte Container, die du wie Maps ansprichst. Für komplexere Objekte generiert Hive mit hive_generator automatisch TypeAdapter.

Stärken:

Kein nativer Code, läuft auf allen Plattformen inkl. Web
Sehr schnelle Lese-/Schreiboperationen durch In-Memory-Caching
Minimaler Boilerplate, intuitive API
AES-256-Verschlüsselung optional aktivierbar

Grenzen:

Keine Queries – du holst Daten per Key oder iterierst
Keine Relationen zwischen Objekten
Bei vielen tausend Einträgen wird die Performance spürbar schlechter
Schema-Migrationen erfordern manuelle Logik

Isar – Performance für große Offline-Datenmodelle

Dein Szenario: Deine App arbeitet mit einem großen Offline-Datenmodell. Finanz- oder Produktivitäts-Apps, die häufig lesen und schreiben. Geräte, die tagelang ohne Internet laufen müssen.

Isar ist eine NoSQL-Datenbank, die speziell für Flutter entwickelt wurde. Der Kern ist in Rust geschrieben und nutzt Zero-Copy-Deserialisierung – Objekte werden direkt aus dem Speicher gelesen, ohne sie zu kopieren.

Stärken:

Extrem schnelle Lese- und Schreiboperationen (Benchmarks zeigen 2-10x schneller als SQLite)
Reactive Queries mit Streams für Live-UI-Updates
Volltext-Suche eingebaut
Compound Indexes und komplexe Filter möglich
Automatische Schema-Migrationen

Grenzen:

Nur für Dart/Flutter verfügbar
Kein SQL – Umdenken nötig, wenn du aus der SQL-Welt kommst
Relativ jung, Community kleiner als bei SQLite
Keine eingebaute Sync-Lösung

SQLite – Der Embedded-Standard mit voller SQL-Power

Dein Szenario: Du brauchst echte Tabellen, Relationen und die volle Ausdrucksstärke von SQL. Vielleicht für Reporting-Features in der App, oder weil dein Team serverseitig bereits SQL nutzt.

SQLite ist die meistgenutzte Datenbank der Welt – auf praktisch jedem Smartphone vorinstalliert. In Flutter arbeitest du meist mit Wrappern wie sqflite, oder typsicheren ORMs wie Drift (ehemals Moor) oder Floor.

Stärken:

Bewährt seit 2000, extrem stabil und gut dokumentiert
Volle SQL-Syntax: JOINs, Subqueries, Views, Triggers
Transaktionen mit ACID-Garantien
Riesige Community, unzählige Tools und Ressourcen
Datenbank-Dateien sind portabel und können inspiziert werden

Grenzen:

Mehr Boilerplate als NoSQL-Alternativen
Schema-Migrationen müssen manuell verwaltet werden (Drift hilft hier)
Nicht optimal für hochfrequente Schreiboperationen
Web-Support nur mit WebAssembly-Workarounds

Drift vs. Floor: Drift generiert typsichere Dart-APIs und bietet reaktive Streams. Floor folgt dem Room-Pattern aus Android und fühlt sich für Java/Kotlin-Entwickler vertrauter an.

ObjectBox – Multi-Plattform mit Geschwindigkeit

Dein Szenario: Dein Core läuft nicht nur in Dart oder JavaScript. Du hast einen gemeinsamen Kern für Mobile, Desktop und Backend – vielleicht sogar Hardware-nahe Komponenten in C++, Rust oder Go.

ObjectBox ist eine objektorientierte NoSQL-Datenbank mit Fokus auf Performance und Portabilität. Der Kern ist in C++ geschrieben, Bindings existieren für Dart, Java, Kotlin, Swift, Go und Python.

Stärken:

Sehr hohe Geschwindigkeit, vergleichbar mit Isar
Echte Multi-Language-Unterstützung mit konsistenter API
ObjectBox Sync als optionaler Sync-Service (On-Premise oder Cloud)
Relations zwischen Objekten eingebaut
Data Browser App zum Debuggen

Grenzen:

Closed-Source-Kern (Bindings sind Open Source)
Sync-Service ist kostenpflichtig für kommerzielle Nutzung
Kleinere Community als SQLite
Kein Web-Support

Realm – Offline-First mit eingebautem Sync

Dein Szenario: Deine App sammelt Daten offline und synchronisiert sie später – Team-To-Do-Listen, Sensor-Tracking, Health-Apps. Der Sync soll automatisch und konfliktfrei funktionieren.

Realm (jetzt MongoDB Realm) kombiniert eine lokale Objekt-Datenbank mit Device Sync. Die Konfliktlösung basiert auf Operational Transformation – Änderungen werden automatisch zusammengeführt.

Stärken:

Vollautomatischer bidirektionaler Sync mit MongoDB Atlas
Eingebaute Konfliktlösung, auch bei Offline-Edits
Reactive Objects – Änderungen propagieren automatisch zur UI
Gute Performance bei komplexen Objektgraphen
SDKs für Flutter, Swift, Kotlin, React Native, .NET

Grenzen:

Vendor Lock-in: Sync nur mit MongoDB Atlas Backend
Kostenmodell kann bei vielen Sync-Operationen teuer werden
Realm-Objekte sind nicht reine Dart-Klassen (erben von RealmObject)
Debugging komplexer Sync-Konflikte kann schwierig sein

Sembast – Einfach, Web-kompatibel, keine nativen Dependencies

Dein Szenario: Du baust für den Browser oder Desktop-Web. Native Module sind keine Option, oder du willst einen Prototyp mit minimalem Setup.

Sembast ist eine JSON-basierte NoSQL-Datenbank, komplett in Dart geschrieben. Daten werden als JSON in einer einzelnen Datei gespeichert. Kein nativer Code, keine Kompilierung, läuft überall.

Stärken:

Zero native Dependencies – funktioniert auf Web, Mobile, Desktop
Einfache API mit Stores und Records
Transaktionen und Queries eingebaut
Gut für Prototypen und kleinere Apps
Datenbank-Datei ist menschenlesbar (JSON)

Grenzen:

Nicht für große Datenmengen optimiert (alles wird in Memory geladen)
Keine echten Indizes, Queries scannen sequentiell
Langsamer als native Alternativen
Keine Verschlüsselung eingebaut

Schnellauswahl

Bedarf	Empfehlung
Kleine Datenmengen, Key/Value	Hive
Hohe Performance, große Offline-Daten	Isar
SQL-Abfragen, Relationen, Reporting	SQLite / Drift
Multi-Plattform, mehrere Sprachen	ObjectBox
Offline + automatischer Cloud-Sync	Realm
Web-Unterstützung, kein Native	Sembast

Entscheidungshilfe

Die richtige Wahl ergibt sich aus deinem Use Case:

Datenvolumen: Wenige KB → Hive/Sembast. Viele MB → Isar/ObjectBox/SQLite.
Query-Komplexität: Simple Lookups → Hive. Komplexe Filter → Isar. SQL-JOINs → SQLite/Drift.
Plattformen: Nur Flutter → Isar. Multi-Language → ObjectBox. Web-First → Sembast.
Sync-Bedarf: Kein Sync → alle. Automatischer Sync → Realm. DIY-Sync → SQLite + eigene Logik.
Team-Erfahrung: SQL-Background → Drift/Floor. NoSQL-Erfahrung → Isar/ObjectBox.

Mit diesen Kriterien bist du in Minuten bei der richtigen Engine – ohne Experimente, die dich Tage kosten.