IndexedDB

Definition: IndexedDB ist eine browserbasierte Low-Level-API zum persistenten Speichern größerer Mengen strukturierter Daten clientseitig im Browser. Im Unterschied zu LocalStorage (maximal 5–10 MB, nur Strings) unterstützt IndexedDB komplexe JavaScript-Objekte, Binärdaten (Blobs, File-Objekte), Indizes für schnelle Abfragen und vollständig asynchrone Transaktionen ohne Blockierung des Hauptthreads. Der verfügbare Speicher liegt typischerweise bei mehreren hundert Megabyte bis Gigabyte je nach Gerätespeicher. IndexedDB ist die Standardlösung für Progressive Web Apps (PWAs) die offline funktionieren müssen, sowie für Web-Anwendungen die große Datenmengen lokal cachen – etwa Produktkataloge, Mediendateien oder Nutzerpräferenzen.

Erläuterung

IndexedDB ist eine NoSQL-Datenbank im Browser: Daten werden in Object Stores (vergleichbar mit Tabellen) als Schlüssel-Wert-Paare gespeichert. Im Gegensatz zu SQL-Datenbanken gibt es keine JOIN-Operationen – Abfragen laufen über Indizes. Die native API ist event-basiert und gilt als umständlich zu nutzen. Bibliotheken wie Dexie.js oder idb abstrahieren die API deutlich und reduzieren Boilerplate-Code erheblich. Service Worker nutzen IndexedDB intensiv für Offline-Cache-Management.

IndexedDB-Grundkonzepte

Object Stores: Containers für gleichartige Datensätze (analog zu Datenbanktabellen); jeder Store hat einen Key Path (Primary Key); Beispiel: Object Store «products» mit keyPath «id»; mehrere Object Stores in einer IndexedDB-Datenbank; Schema wird in onupgradeneeded-Event definiert
Indizes: Sekundäre Schlüssel für schnelle Abfragen über Nicht-Primary-Key-Felder; createIndex('by-category', 'category', {unique: false}); Suche nach allen Produkten einer Kategorie ohne Full-Scan; deutlich performanter als manuelles Filtern aller Records
Transaktionen: Alle Lese-/Schreiboperationen laufen in Transaktionen; readonly für Lesezugriffe (schneller, parallel möglich); readwrite für Änderungen (serialisiert); Atomarität: bei Fehler werden alle Änderungen der Transaktion zurückgerollt; keine explizite COMMIT-Syntax – Transaktion schließt automatisch
Asynchrones API: Alle IndexedDB-Operationen sind asynchron (event-basiert oder Promise-basiert via Wrapper); blockiert den Hauptthread nicht; im Vergleich: LocalStorage ist synchron und kann bei großen Daten UI einfrieren; async/await mit Dexie.js macht IndexedDB-Code lesbar

Dexie.js – praktische Nutzung

Warum Dexie.js: Native IndexedDB-API erfordert viel Boilerplate für einfache Operationen; Dexie.js: Promise-basierte API, Collection-Queries, LiveQuery (reaktive Updates), TypeScript-Support; 5 KB gzip; beliebteste IndexedDB-Wrapper-Bibliothek; kein Framework-Dependency
Schema-Definition: const db = new Dexie('ShopDB'); db.version(1).stores({products: '++id, category, name', cart: '++id, productId'}); ++id = auto-increment; einzelne Datenbank-Deklaration für gesamte Anwendung; Schema-Migrationen via Versionsnummern
Typische Queries: await db.products.where('category').equals('shirts').toArray(); await db.products.orderBy('price').limit(20).toArray(); await db.cart.put({productId: 123, quantity: 2}); syntaktisch deutlich einfacher als native IndexedDB-API

Vergleich: Browserspeicher-Optionen

Cookies: Maximal 4 KB; werden mit jedem HTTP-Request gesendet; Expiry via Expires/Max-Age; für kleine Daten und Server-seitig benötigte Informationen (Session-ID, Analytics-IDs); von Safari ITP und Browser-Datenschutzmodi eingeschränkt
LocalStorage: 5–10 MB; synchron; nur Strings; kein Index; einfache Key-Value-Speicherung; für kleine UI-Präferenzen, Warenkorb-Snapshots, letzte Suchanfragen; kein Ablaufdatum – bleibt dauerhaft; wird von iOS Safari nach 7 Tagen ohne Interaktion geleert
SessionStorage: Wie LocalStorage aber nur für Session-Dauer (Tab-Schließen löscht Daten); für temporäre Formulardaten, Schritt-für-Schritt-Workflows; nicht zwischen Tabs geteilt
IndexedDB: Hunderte MB bis GB; asynchron; komplexe Objekte, Blobs; Indizes; Transaktionen; für Offline-Daten, Produktkataloge, Media-Cache; von iOS Safari ebenfalls nach 7 Tagen ohne User-Interaktion geleert (ITP-Einschränkung)

Marketing- und PWA-Anwendungsfälle

Offline-Produktkatalog: E-Commerce-PWA lädt Produktdaten in IndexedDB; Nutzer kann Produkte offline browsen; Service Worker kombiniert IndexedDB mit Cache API für vollständiges Offline-Erlebnis; Synchronisation bei Wiederherstellen der Internetverbindung
Analytics-Queue: Tracking-Events in IndexedDB puffern wenn Nutzer offline; bei Reconnect alle gespeicherten Events senden; verhindert Datenverlust bei instabiler Verbindung; Google Analytics 4 SDK macht dies intern bereits; für Custom-Tracking selbst implementierbar
Personalisierung ohne Server-Round-Trip: Nutzer-Präferenzen, zuletzt angesehene Produkte, Kategorien-Affinität in IndexedDB speichern; Personalisierungs-Logik clientseitig berechnen; schnellere Darstellung als Server-Request; kombiniert mit A/B-Testing für personalisierte Varianten

Praxistipp: Nutzen Sie IndexedDB (via Dexie.js) wenn Sie mehr als 5 MB clientseitige Daten speichern müssen oder strukturierte Abfragen benötigen – andernfalls reicht LocalStorage. Wichtig für iOS/Safari: IndexedDB-Daten werden nach 7 Tagen ohne User-Interaktion gelöscht (Apple ITP). Bauen Sie Ihre Anwendung so, dass sie fehlende IndexedDB-Daten erkennt und den Server-Fetch als Fallback triggert. Testen Sie IndexedDB-Szenarien explizit in Safari DevTools: Entwickler → Websiteressourcen → IndexedDB zeigt gespeicherte Daten direkt im Browser.