IndexedDB in der Praxis: Große-Datei-Speicherung und Offline-Architektur im Browser

Warum IndexedDB?

Die Browser-Speicheroptionen haben jeweils klare Grenzen:

Option	Kapazität	Datentypen	Sync-API	Anwendungsfall
Cookie	~4KB	String	✅	Sitzungskennungen
localStorage	~5MB	String	✅	Einfache Einstellungen
sessionStorage	~5MB	String	✅	Temporärer Zustand
IndexedDB	Hunderte MB–GB	Beliebige strukturierte Daten	❌ Async	Große Dateien, Offline-Apps

Für Tool-Seiten, die PDF-Verarbeitungszwischenergebnisse, WASM-Module oder den Upload-Verlauf der Benutzer im Browser zwischenspeichern müssen, ist IndexedDB die einzig tragfähige Wahl.

Kernkonzepte

Datenbank → Object Store → Datensatz

Database: "toolsku-cache"
  ├── ObjectStore: "wasm-modules"     (key: moduleName)
  ├── ObjectStore: "file-cache"       (key: fileHash, index: timestamp)
  └── ObjectStore: "user-preferences" (key: settingKey)

Transaktionen und Nebenläufigkeit

IndexedDB-Transaktionen werden auto-committed, und pro Object Store ist jeweils nur eine Lese-/Schreibtransaktion gleichzeitig erlaubt:

const tx = db.transaction(['file-cache'], 'readwrite');
const store = tx.objectStore('file-cache');
await store.put({ hash: 'abc123', data: arrayBuffer, timestamp: Date.now() });
await tx.done; // Wait for transaction to complete

IndexedDB in ToolsKu

WASM-Modul-Caching

ffmpeg.wasm ist etwa 30 MB groß und benötigt beim Laden jedes Mal 3–5 Sekunden. Nach dem Caching in IndexedDB sind nachfolgende Besuche nahezu augenblicklich:

async function getWasmModule(name: string): Promise<ArrayBuffer> {
  const cached = await idb.get('wasm-modules', name);
  if (cached) return cached;

  const response = await fetch(`/wasm/${name}.wasm`);
  const buffer = await response.arrayBuffer();
  await idb.put('wasm-modules', buffer, name);
  return buffer;
}

Gechunkte Speicherung für große Dateien

Dateien über 50 MB auf einmal in IndexedDB zu speichern, ist nicht ideal. Eine Chunking-Strategie:

File (200MB) → split into 4MB chunks → store each in IndexedDB
key: "file:{hash}:chunk:{index}"
Read in order and concatenate → restore full file

Versionsmigration

Wenn sich das Datenbankschema ändert, erfolgt die Migration in onupgradeneeded:

const request = indexedDB.open('toolsku-cache', 2); // version 2

request.onupgradeneeded = (event) => {
  const db = event.target.result;
  if (event.oldVersion < 2) {
    db.createObjectStore('processing-history', { keyPath: 'id' });
  }
};

Beste Praxis: Fügen Sie nur ObjectStores hinzu — entfernen Sie sie niemals. Erhöhen Sie die Versionsnummer, um die Migration auszulösen, und vermeiden Sie das Löschen von Benutzerdaten.

IndexedDB vs. OPFS

Merkmal	IndexedDB	OPFS (Origin Private File System)
API-Reife	Breite Unterstützung	Chrome 86+ / Safari 15.2+
Lese-/Schreibmodell	Key-Value-Speicher	Echtes Dateisystem
Leistung	Mäßig	Höher (besonders synchroner Zugriff)
Am besten für	Strukturiertes Cache	Große Datei-E/A

ToolsKu verwendet in erster Linie IndexedDB, mit OPFS als Leistungsoptimierung unter Chrome.

Zusammenfassung

IndexedDB ist wesentliche Infrastruktur für offline-fähige Browser-Tools. Gut gestaltete ObjectStores, WASM-Caching und gechunkte Speicherstrategien ermöglichen es ToolsKu, auch in langsamen Netzwerken reaktionsfähig zu bleiben.