Ist DynamoDB ACID-konform?

Ja. DynamoDB unterstützt ACID-Transaktionen über die APIs TransactWriteItems und TransactGetItems. Sie bündeln bis zu 100 Aktionen in eine einzige Alles-oder-nichts-Operation mit Garantien für Atomarität, Konsistenz, Isolation und Dauerhaftigkeit innerhalb einer AWS-Region. Auch Einzel-Item-Writes sind atomar und dauerhaft, ACID über mehrere Items hinweg braucht aber die Transaktions-APIs.

Was ACID hier bedeutet

Eine DynamoDB-Transaktion wendet entweder jede Aktion an oder keine (Atomarität), hinterlässt die Daten in einem gültigen Zustand (Konsistenz), ist gegen gleichzeitige Transaktionen isoliert und ist dauerhaft committet, sobald sie mit Erfolg zurückkehrt. Diese Garantien gelten innerhalb der AWS-Region, in der die Transaktions-API aufgerufen wurde.

Die Transaktions-APIs

TransactWriteItems — ein synchroner, idempotenter Write, der Put-, Update-, Delete- und ConditionCheck-Aktionen bündelt.
TransactGetItems — ein atomarer, konsistenter Read mehrerer Items.

Du kannst dasselbe Item in einer Transaktion nicht zweimal ansprechen.

Das Limit ist 100, nicht 25

Die API-Referenz sagt, TransactWriteItems "groups up to 100 action requests" und dass "the aggregate size of the items in the transaction cannot exceed 4 MB" (abgerufen am 2026-07-28). Vor 2022 lag die Zahl bei 25, und der veraltete Wert wird noch so verbreitet wiederholt, dass es sich lohnt, ihn gegen die API zu prüfen statt gegen einen Blogbeitrag.

Eine Transaktion mit 100 Aktionen wird akzeptiert. Eine mit 101 wird abgelehnt:

ValidationException: Member must have length less than or equal to 100

Beachte, was in dieser Meldung nicht steht: das Wort „transaction". Es ist eine generische Beschwerde über die Array-Länge, sie taucht also bei einer Log-Suche nach Transaktionsfehlern nicht auf. Die Batch-APIs sind da weniger zurückhaltend. BatchGetItem mit 101 Keys liefert Too many items requested for the BatchGetItem call, und BatchWriteItem mit 26 liefert denselben Satz mit seinem eigenen Namen darin.

Dasselbe Item zweimal anzusprechen scheitert ebenfalls, selbst wenn jede Aktion für sich genommen erfolgreich wäre:

ValidationException: Transaction request cannot include multiple operations on one item

Das ist der Fehler, der Code erwischt, der die Aktionsliste aus einer Schleife über eingehende Events baut, ohne vorher nach Key zu deduplizieren.

Transaktionen werden außerdem doppelt abgerechnet. 100 Items zu je 1 KB transaktional zu schreiben verbraucht 200 Write-Einheiten gegenüber 100 für dieselben einzeln geschriebenen Items — Atomarität hat also einen Preis, auch wenn nichts schiefgeht.

Und Global Tables?

Eine Transaktion ist nur in der Region ACID, in der sie aufgerufen wurde. Bei Global Tables im Standardmodus Multi-Region Eventual Consistency (MREC) werden transaktionale Writes nicht als Einheit repliziert — eine andere Region kann während der Ausbreitung kurzzeitig eine teilweise replizierte Transaktion sehen. Global Tables, die auf Multi-Region Strong Consistency (MRSC) konfiguriert sind, unterstützen die Transaktions-APIs überhaupt nicht.

Tiefer einsteigen

Lerne in DynamoDB-Transaktionen, wie du das sicher modellierst, und baue die dafür nötigen Condition Expressions mit dem Expression Builder. Probier es gegen deine eigenen Tabellen aus — lade DynoTable herunter.

Referenzen

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation; die Limits von 100 Aktionen und 4 MB wurden am 2026-07-28 erneut aus der API-Referenz abgerufen.

Die Ablehnungen oben wurden am 2026-07-28 gegen DynamoDB Local 3.3.0 (amazon/dynamodb-local:latest) via @aws-sdk/client-dynamodb 3.1095.0 reproduziert. Jeder zitierte String ist wortgetreue Engine-Ausgabe.