MMKV vs. AsyncStorage: schnellerer lokaler Key-Value-Speicher

1. Wie AsyncStorage funktioniert: asynchrone Bridge-Aufrufe pro Zugriff

AsyncStorage speichert Daten je nach Plattform unterschiedlich, auf Android traditionell in einer SQLite-Datenbank, auf iOS in einer Sammlung von Property-List-Dateien, und jeder einzelne Zugriff, ob Lesen oder Schreiben, läuft über einen asynchronen Aufruf, der früher über die klassische Bridge und heute über ein TurboModule abgewickelt wird. Selbst das Lesen eines einzigen kleinen Strings erzeugt dabei einen kompletten asynchronen Round-Trip mit Promise-Auflösung.

Für gelegentliche Zugriffe, etwa das einmalige Speichern eines Auth-Tokens beim Login, ist dieser Overhead unproblematisch. Sobald eine App aber viele kleine Werte häufig liest oder schreibt, etwa Formularzustände, UI-Präferenzen oder Feature-Flags, die bei jedem Render geprüft werden, summiert sich die asynchrone Natur von AsyncStorage zu spürbarer Latenz und einer wachsenden Anzahl paralleler Promises.

2. Wie MMKV funktioniert: synchron, C++-basiert und mmap-gestützt

MMKV wurde ursprünglich von Tencent für WeChat entwickelt und basiert auf einer C++ Kernbibliothek, die Daten über memory-mapped files direkt in den Prozessspeicher einblendet, statt bei jedem Zugriff eine Datei zu öffnen, zu lesen oder zu schreiben. Über JSI wird MMKV direkt aus JavaScript synchron angesprochen, ganz ohne Promise, Bridge-Serialisierung oder Thread-Wechsel, was bei kleinen, häufigen Zugriffen einen fundamentalen Unterschied macht.

Da MMKV auf derselben nativen Ebene arbeitet, die auch von den Betriebssystemen für effizienten Dateizugriff genutzt wird, entfällt der Umweg über eine separate Datenbank-Engine wie SQLite komplett. Änderungen werden inkrementell in die zugrunde liegende Datei geschrieben, ohne dass jeder einzelne Schreibvorgang eine komplette Datei neu serialisieren muss.

3. Benchmark-Vergleich: Lese- und Schreibzeiten bei kleinen Werten

In öffentlich verfügbaren Benchmarks, unter anderem von der MMKV-Bibliothek selbst veröffentlicht, zeigt sich bei kleinen Werten wie einzelnen Strings oder Zahlen ein Geschwindigkeitsunterschied im Bereich von etwa dem Zehn- bis Dreißigfachen zugunsten von MMKV gegenüber AsyncStorage, insbesondere bei vielen aufeinanderfolgenden Einzelzugriffen. Der Unterschied fällt umso deutlicher aus, je kleiner die einzelnen Werte und je häufiger die Zugriffe sind.

Bei sehr großen, seltenen Schreibvorgängen, etwa dem einmaligen Ablegen eines mehrere Megabyte großen JSON-Blobs, relativiert sich der Unterschied etwas, da hier die reine Datenmenge stärker ins Gewicht fällt als der Protokoll-Overhead pro Aufruf. Für den typischen Anwendungsfall kleiner, häufiger Key-Value-Zugriffe bleibt MMKV aber in jedem realistischen Szenario klar im Vorteil.

4. API-Vergleich: von AsyncStorage-Promises zu MMKV-Synchronaufrufen

Der API-Unterschied zeigt sich direkt im Code: AsyncStorage erfordert für jeden Zugriff await oder eine .then()-Kette, während MMKV synchrone Methoden bereitstellt, die sofort einen Wert zurückgeben, ohne dass die aufrufende Funktion selbst asynchron sein muss. Das vereinfacht insbesondere Code, der Werte während des Renderns lesen möchte, was mit einer rein asynchronen API nur über Umwege wie initiale Lade-States möglich ist.

Das folgende Beispiel stellt beide APIs für denselben Anwendungsfall, das Speichern und Lesen eines Auth-Tokens, direkt gegenüber.

// AsyncStorage: jeder Zugriff ist asynchron
import AsyncStorage from "@react-native-async-storage/async-storage";

async function saveToken(token: string) {
  await AsyncStorage.setItem("auth_token", token);
}

async function loadToken(): Promise<string | null> {
  return AsyncStorage.getItem("auth_token");
}

// MMKV: synchrone Zugriffe ohne Promise
import { MMKV } from "react-native-mmkv";

const storage = new MMKV();

function saveTokenSync(token: string) {
  storage.set("auth_token", token);
}

function loadTokenSync(): string | undefined {
  return storage.getString("auth_token");
}

5. Migration bestehender AsyncStorage-Daten zu MMKV

Eine Migration lässt sich in der Praxis meist als einmaliger Schritt beim App-Start umsetzen: Alle vorhandenen Keys werden über AsyncStorage.getAllKeys() ermittelt, die zugehörigen Werte per multiGet gelesen und anschließend synchron in eine neue MMKV-Instanz geschrieben. Nach erfolgreicher Migration markiert eine eigene Flag-Property, dass der Vorgang abgeschlossen ist, damit er bei künftigen App-Starts nicht wiederholt wird.

Wichtig ist, die Migration idempotent zu gestalten und Fehlerfälle wie einen fehlgeschlagenen Einzelwert nicht die gesamte Migration abbrechen zu lassen, da sonst Nutzer mit teilweise migrierten, teilweise noch in AsyncStorage liegenden Daten enden könnten. Ein bewährtes Muster ist, AsyncStorage nach der Migration nicht sofort zu löschen, sondern erst nach einigen erfolgreichen App-Starts, um im Fehlerfall einen Rückweg zu behalten.

6. Verschlüsselungsoption von MMKV

MMKV unterstützt eine eingebaute Verschlüsselung, die beim Erzeugen einer Instanz über einen Encryption-Key aktiviert wird und alle Daten transparent mit AES verschlüsselt, bevor sie in die zugrunde liegende Datei geschrieben werden. Für sensible Daten wie Session-Tokens oder persönliche Nutzerinformationen ist das ein spürbarer Vorteil gegenüber AsyncStorage, das standardmäßig keinerlei Verschlüsselung mitbringt und dafür auf zusätzliche Bibliotheken angewiesen ist.

Der Encryption-Key selbst sollte nicht im Klartext im Code stehen, sondern über einen sicheren Secure-Storage-Mechanismus wie das iOS Keychain oder den Android Keystore verwaltet werden, damit die Verschlüsselung nicht durch einen leicht auslesbaren, hartkodierten Schlüssel ausgehebelt wird. MMKV selbst kümmert sich nicht um die Verwaltung dieses Schlüssels, das bleibt Aufgabe der App.

7. Multi-Instance- und Multi-Process-Unterstützung

Anders als eine einzelne globale AsyncStorage-Instanz erlaubt MMKV mehrere unabhängige, benannte Instanzen innerhalb derselben App, was sich gut eignet, um unterschiedliche Datenkategorien wie Nutzerpräferenzen, Cache-Daten und Auth-Informationen sauber voneinander zu trennen, ohne Namenskollisionen bei Keys befürchten zu müssen. Jede Instanz kann dabei ihre eigene Verschlüsselungskonfiguration erhalten.

MMKV unterstützt außerdem Multi-Process-Zugriff, was relevant wird, sobald eine App Erweiterungen wie einen iOS Share Extension oder einen Android Widget-Prozess besitzt, die auf dieselben Daten zugreifen müssen wie der Hauptprozess. AsyncStorage bietet dafür keinen eingebauten Mechanismus und würde eine eigene Interprozesskommunikation erfordern.

8. Grenzen von MMKV: große Datenmengen und komplexe Queries

MMKV ist als reiner Key-Value-Speicher konzipiert und bietet keine Möglichkeit für strukturierte Abfragen wie Filtern, Sortieren oder Verknüpfen mehrerer Datensätze, wie es eine relationale Datenbank leisten würde. Für Anwendungsfälle wie eine durchsuchbare Liste von tausenden Datensätzen mit komplexen Filterkriterien ist MMKV deshalb die falsche Wahl, hier eignet sich eher SQLite oder eine spezialisierte Lösung wie WatermelonDB.

Auch bei sehr großen Einzelwerten, etwa dem Zwischenspeichern kompletter API-Antworten mit mehreren Megabyte, verliert MMKV einen Teil seines Geschwindigkeitsvorteils, da der mmap-basierte Ansatz vor allem bei vielen kleinen, häufigen Zugriffen glänzt. MMKV bleibt in seinem Kern ein Ersatz für AsyncStorage, keine vollwertige Datenbank für komplexe, relationale Anforderungen.

9. Einbindung im Projekt: Installation und New-Architecture-Kompatibilität

Die Installation von react-native-mmkv erfolgt über den üblichen Paketmanager, gefolgt von einem nativen Build-Schritt, da MMKV auf nativem C++ Code basiert und nicht rein in JavaScript ausgeliefert wird. Auf iOS ist ein pod install nötig, auf Android greift Autolinking automatisch, sofern die Projektkonfiguration aktuell ist.

Aktuelle Versionen von react-native-mmkv sind explizit für die New Architecture mit JSI gebaut und funktionieren nicht im reinen Legacy-Modus ohne aktivierte New Architecture, da die synchrone API direkt auf JSI HostObjects aufsetzt. Projekte, die noch komplett auf der alten Architektur laufen, müssen entweder auf eine ältere MMKV-Version zurückgreifen oder zuerst auf die New Architecture umstellen, bevor sie MMKV einsetzen können.

10. Zusammenfassung

11. FAQ: MMKV vs. AsyncStorage: Das Wichtigste auf einen Blick