Ist DynamoDB In-Memory?

Nein. DynamoDB ist keine In-Memory-Datenbank — jeder Write wird dauerhaft gespeichert und automatisch über drei Availability Zones repliziert. Wenn du In-Memory-Tempo brauchst, ergänzt DynamoDB Accelerator (DAX) einen vollständig verwalteten In-Memory-Cache, der eventually consistent Reads von einstelligen Millisekunden auf Mikrosekunden drückt.

Dauerhaft von Grund auf

DynamoDB ist eine dauerhafte operative Datenbank: Writes landen auf dauerhaften Medien und werden standardmäßig über drei Availability Zones repliziert, was ein Verfügbarkeits-SLA von 99,99 % trägt. Das ist der umgekehrte Kompromiss zu einem reinen In-Memory-Store, in dem die Daten im RAM liegen und Dauerhaftigkeit optional ist.

Auch ohne Cache ist es schnell

DynamoDB liefert schon im Grundzustand konstante Lese- und Schreibzeiten im einstelligen Millisekundenbereich, egal wie groß die Tabelle wird, weil jeder Read direkt einen Partitionsschlüssel ansteuert, statt zu scannen. Die meisten Workloads brauchen überhaupt keinen Cache.

Das eine In-Memory-DynamoDB ist der Emulator

Die Verwirrung beginnt meist bei DynamoDB Local, denn das hat tatsächlich einen In-Memory-Modus. Starte es, und das Banner sagt es dir:

docker run -p 8000:8000 amazon/dynamodb-local -jar DynamoDBLocal.jar -inMemory -sharedDb

Initializing DynamoDB Local with the following configuration:
Port:	8000
InMemory:	true
Version:	3.3.0

Schreib ein Item, starte den Container neu und such es dann wieder:

after write:            {"total":{"N":"42"},"pk":{"S":"ORDER#1"}}
tables after restart:   []
read after restart:     ResourceNotFoundException | Cannot do operations on a non-existent table

Nicht nur das Item ist weg, die ganze Tabelle ist mitgegangen. Dieses Flag gehört zum Test-Emulator. Der verwaltete Dienst hat keine Entsprechung dafür und keinen Modus, in dem ein bestätigter Write nur im RAM liegt.

DAX: die In-Memory-Schicht

Wenn Mikrosekunden zählen — Real-Time Bidding, Gaming-Leaderboards, heiße Produktseiten — ist DAX die Antwort von AWS: ein DynamoDB-kompatibler Write-Through-In-Memory-Cache, der die Performance von eventually consistent Reads mit minimalen Codeänderungen um eine Größenordnung verbessert. Für stark konsistente Reads oder schreibintensive Workloads lässt du ihn weg.

Reads bezahlen oder einen Cache davorsetzen

DAX spart Leselatenz auf heißen Schlüsseln; er verkleinert weder die darunterliegende Tabelle noch ändert er die Dauerhaftigkeit von Writes. Jedes bestätigte PutItem landet weiterhin auf Platte in drei Availability Zones, ob DAX davorsitzt oder nicht. Auf einer 10 GB großen Tabelle rechnet ein stark konsistenter Scan in us-east-1 On-Demand grob 2,5 Millionen Read-Request-Einheiten ab — miss dein eigenes Muster mit dem Preisrechner, bevor du einen Cache-Cluster dimensionierst.

In DynoTable: Die Query-Vorschau kennzeichnet Scan gegenüber Query und zeigt eine RCU-Schätzung, sobald die Tabellen-Metadaten das hergeben — du siehst also die Kosten eines vollen Reads, bevor du ihn ausführst. Gewöhnliche Query-Aufrufe über den Partitionsschlüssel zeigen keine RCU-Zeile. Siehe SQL Workbench — Abfragekosten vorab ansehen.

Tiefer einsteigen

Verstehe die Konsistenz-Kompromisse im Konsistenz-Guide, sieh dir Lässt sich DynamoDB als Cache nutzen? für die umgekehrte Frage an, schätze Lesekosten mit dem Preisrechner und lade DynoTable herunter, um deine Tabellen zu inspizieren.

Referenzen

Zuletzt überprüft am 13.07.2026 anhand der oben verlinkten offiziellen AWS-Dokumentation.

Am 28.07.2026 gegen DynamoDB Local 3.3.0 über @aws-sdk/client-dynamodb 3.1095.0 auf Node v24.18.0 reproduziert. Das Banner und die drei Ausgabezeilen sind wortgetreu.