Kann man DynamoDB lokal betreiben?

Ja. AWS liefert DynamoDB Local aus, eine kostenlose herunterladbare Version von DynamoDB, die als Docker-Image, ausführbare Java-Anwendung oder Apache-Maven-Abhängigkeit auf deinem eigenen Rechner läuft. Sie stellt dieselbe API bereit wie der Webdienst — du kannst also offline entwickeln und testen und deinen Code danach einfach auf AWS richten.

Drei Wege, sie zu betreiben

Docker-Image — die häufigste Wahl: ein docker run, und der Endpoint läuft auf einem lokalen Port.
Herunterladbares Archiv — eine Java-Anwendung, die du direkt startest (braucht ein JRE).
Apache-Maven-Abhängigkeit — zum Einbetten in JVM-Testsuiten.

Warum lokal entwickeln

Die Datenbank ist auf deinem Computer in sich abgeschlossen, du sparst also Gebühren für Durchsatz, Datenspeicherung und Datentransfer — und du brauchst beim Entwickeln keine Internetverbindung. Wenn du bereit fürs Deployment bist, entfernst du den lokalen Endpoint aus dem Code, und er zeigt auf den DynamoDB-Webdienst.

Achte auf die Unterschiede

DynamoDB Local emuliert die API, ist aber nicht die Produktions-Engine — AWS dokumentiert Verhaltensunterschiede in seinen Usage Notes (Durchsatz wird zum Beispiel nicht erzwungen). Behandle es als funktionalen Dev-/Test-Doppelgänger, nicht als Performance-Modell.

Drei Abweichungen, die wir gemessen haben

Wir halten einen DynamoDB-Local-Container am Laufen, um die auf unseren Fehlerseiten zitierten Fehler zu reproduzieren — wir stoßen also regelmäßig an seine Kanten. Drei davon lohnt es zu kennen, bevor du einem grünen lokalen Test vertraust.

Provisionierter Durchsatz wird überhaupt nicht erzwungen. Wir haben eine Tabelle mit 1 RCU angelegt, ein 3,5-KB-Item abgelegt und es in einer Schleife stark konsistent zurückgelesen, mit abgeschalteten SDK-Retries (maxAttempts: 1):

reads=5000 ok=5000 errors=0 elapsed=2.5s rate=1997/s

Fünftausend Reads, null Drosselungen, dauerhaft rund 2.000 Read-Einheiten pro Sekunde gegen eine Tabelle, die für eine provisioniert ist. Dieselbe Schleife gegen den Live-Dienst wirft bei Read 49 eine ProvisionedThroughputExceededException. Ein Kapazitätsbug kann lokal gar nicht auffallen.

Ein Fehler wechselt seinen Namen. Führe dasselbe PartiQL-INSERT zweimal aus, und DynamoDB Local antwortet mit DuplicateItem und der Meldung Duplicate primary key exists in table. Der Dienst antwortet mit DuplicateItemException und There was an attempt to insert an item with the same primary key as an item that already exists in the DynamoDB table. Fehlerbehandlung, die auf den Namen verzweigt, besteht lokal und greift in der Produktion daneben.

Manche APIs fehlen schlicht. ExportTableToPointInTime antwortet:

UnknownOperationException: An unknown operation was requested.

Das ist nicht der Fehler des Dienstes für denselben Aufruf — ein Codepfad, der auf PointInTimeRecoveryUnavailableException absichert, lässt sich lokal also ebenfalls nicht durchspielen.

Tiefer einsteigen

Der DynamoDB-Local-Leitfaden geht das Setup Schritt für Schritt durch, und der Leitfaden zur lokalen & LocalStack-Verbindung zeigt, wie du eine GUI darauf richtest — DynoTable verbindet sich mit lokalen Endpoints genauso wie mit AWS. Teste deine erste Abfrage mit dem Expression Builder.

Referenzen

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.

Die drei Abweichungen wurden am 2026-07-28 gegen DynamoDB Local 3.3.0 (amazon/dynamodb-local, Corretto 17.0.17) mit @aws-sdk/client-dynamodb 3.1095.0 auf Node v24.18.0 reproduziert. Jede Ausgabezeile oben stammt unbearbeitet von der Engine selbst.