Anwendungsfälle zuerst denken – dann die passende Library für Mobile, Desktop, Web und Edge auswählen
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 CE – 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 war lange der Standard-Key/Value-Store im Flutter-Ökosystem. Das Original-Package (hive) wird allerdings seit über zwei Jahren nicht mehr gepflegt. Die Community hat mit Hive CE (Community Edition) einen aktiv weiterentwickelten Nachfolger geschaffen, der WASM-ready ist und Bugs behebt, die im Original offen blieben.
Das Grundprinzip bleibt: Daten werden in Boxen organisiert – typisierte Container, die du wie Maps ansprichst. Für komplexere Objekte generiert Hive CE mit hive_ce_generator automatisch TypeAdapter.
Stärken:
- Kein nativer Code, läuft auf allen Plattformen inkl. Web (WASM-Support)
- Sehr schnelle Lese-/Schreiboperationen durch In-Memory-Caching
- Minimaler Boilerplate, intuitive API
- AES-256-Verschlüsselung optional aktivierbar
- Aktive Weiterentwicklung durch die Community
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
Wichtig: Nutze hive_ce statt hive für neue Projekte. Das Original-Package erhält keine Updates mehr.
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.
Hinweis zur Projektstabilität: Die Entwicklung von Isar v4 stagniert seit über zwei Jahren – die letzte Dev-Preview (4.0.0-dev.14) hat kein Update mehr erhalten. In der Community wird offen diskutiert, ob das Projekt weitergeführt wird. Die stabile Version 3 funktioniert, aber für neue Projekte lohnt ein Blick auf den Community-Fork Isar Plus, der Bugfixes und Weiterentwicklung liefert.
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
- Ungewisse Zukunft des Original-Projekts – Community-Fork als Alternative prüfen
- 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 über WASM (offiziell unterstützt seit
sqlite3v3.x und Drift mit Build-Hooks)
Drift vs. Floor: Drift generiert typsichere Dart-APIs und bietet reaktive Streams – inklusive offiziellem Web-Support via WASM. 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 – eingestellt, Alternativen gefragt
Status: End-of-Life seit September 2025. MongoDB hat Atlas Device Sync und die zugehörigen Mobile-SDKs (Flutter, Swift, Kotlin, React Native, .NET) offiziell eingestellt. Der Sync-Service existiert nicht mehr, die SDKs erhalten keine Updates.
Realm war jahrelang die Referenz für Offline-First mit automatischem Cloud-Sync. Die lokale Objekt-Datenbank kombiniert mit Device Sync und automatischer Konfliktlösung war ein starkes Paket. Dieses Paket gibt es nicht mehr.
Der Open-Source-Kern der lokalen Datenbank existiert weiterhin, wird aber nicht offiziell supported. Für bestehende Projekte heißt das: Migration planen.
Was stattdessen?
- Offline + Sync: PowerSync (SQLite-basiert, Backend-agnostisch) oder ObjectBox Sync
- Lokale Objekt-Datenbank ohne Sync: ObjectBox oder Isar als lokale Alternative
- Kollaboratives Sync: CRDTs mit Automerge oder Yjs, kombiniert mit einer lokalen Datenbank
Wer heute ein neues Projekt mit Offline-Sync startet, findet im Abschnitt “Local-First” weiter unten konkrete Alternativen.
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
Local-First: Die neue Generation
Seit 2024 hat sich neben den klassischen lokalen Datenbanken eine neue Kategorie etabliert: Local-First-Architekturen. Die Idee: Daten leben primär auf dem Client, werden aber nahtlos mit einem Server synchronisiert. Das überbrückt die Lücke, die Realm hinterlassen hat – mit offeneren, Backend-agnostischen Ansätzen.
PowerSync – SQLite-Sync für jedes Backend
PowerSync setzt auf SQLite als lokale Datenbank und synchronisiert bidirektional mit Postgres, MongoDB, MySQL oder Supabase. Die Sync-Regeln werden serverseitig definiert, der Client arbeitet vollständig offline-fähig mit reaktiven Queries.
Der entscheidende Vorteil gegenüber dem alten Realm-Modell: Kein Vendor Lock-in. Das Backend bleibt austauschbar, die lokale Datenbank ist Standard-SQLite. SDKs existieren für Flutter, React Native und Web.
ElectricSQL – Postgres-Sync bis in den Browser
ElectricSQL verfolgt einen radikal Postgres-zentrischen Ansatz: Daten werden als “Shapes” definiert – Teilmengen der Postgres-Datenbank, die auf Clients synchronisiert werden. Der Client arbeitet mit PGlite, einer WASM-Version von Postgres, die im Browser oder in Node.js läuft.
Das bedeutet: Dieselbe SQL-Syntax und dasselbe Datenmodell auf Server und Client. Für Teams, die bereits Postgres einsetzen, entfällt das Mapping zwischen Server- und Client-Datenbank komplett.
PGlite – Postgres im Browser
PGlite ist eine vollständige Postgres-Instanz, kompiliert zu WebAssembly. Nur 3 MB gzipped, mit Unterstützung für Extensions wie pgvector (Vektor-Suche für KI-Anwendungen). Läuft im Browser, in Node.js, Bun und Deno.
Für Web-Apps, die bisher auf Sembast oder IndexedDB gesetzt haben, ist PGlite eine Alternative mit deutlich mehr Query-Power – inklusive JOINs, Subqueries und allem, was Postgres kann.
CRDTs – Konfliktfreier Sync ohne Server
Für kollaborative Anwendungen (gemeinsame Dokumente, Whiteboards, Kanban-Boards) bieten CRDTs (Conflict-free Replicated Data Types) einen anderen Ansatz: Änderungen werden so modelliert, dass sie mathematisch garantiert konfliktfrei zusammengeführt werden können – ohne zentralen Server.
Bibliotheken wie Automerge und Yjs sind mittlerweile produktionsreif und lassen sich mit jeder lokalen Datenbank kombinieren. CR-SQLite bringt CRDT-Semantik direkt in SQLite-Tabellen.
Entscheidungshilfe
Die richtige Wahl ergibt sich aus deinem Use Case:
- Datenvolumen: Wenige KB → Hive CE/Sembast. Viele MB → ObjectBox/SQLite.
- Query-Komplexität: Simple Lookups → Hive CE. Komplexe Filter → ObjectBox. SQL-JOINs → SQLite/Drift.
- Plattformen: Nur Flutter → ObjectBox oder Isar. Multi-Language → ObjectBox. Web-First → Sembast oder PGlite.
- Sync-Bedarf: Kein Sync → alle. Automatischer Sync → PowerSync oder ObjectBox Sync. Kollaborativ → CRDTs (Automerge/Yjs).
- Team-Erfahrung: SQL-Background → Drift/Floor. NoSQL-Erfahrung → ObjectBox. Postgres-Erfahrung → ElectricSQL + PGlite.
Mit diesen Kriterien bist du in Minuten bei der richtigen Engine – ohne Experimente, die dich Tage kosten.