Ist DynamoDB eine relationale Datenbank?

Nein. DynamoDB ist keine relationale Datenbank — es ist ein NoSQL-Key-Value- und Dokumentspeicher. Es gibt keine Tabellen mit festen Schemas, keine Fremdschlüssel und keine Joins. Du modellierst Daten um die Zugriffsmuster deiner Anwendung herum und denormalisierst, statt wie in einer relationalen (SQL-) Datenbank über verwandte Tabellen hinweg zu normalisieren. Wenn dir der relationale Workflow fehlt: DynoTable holt einen Teil davon auf dem Client zurück — eine SQL Workbench, die echte JOINs und GROUP BY ausführt, und Smart Tables, die Tabellen visuell zusammenführen.

Warum es nicht relational ist

Relationale Datenbanken erzwingen ein Schema, normalisieren Daten über viele Tabellen und joinen sie beim Lesen. DynamoDB macht das Gegenteil: Es speichert schemalose Items und erwartet, dass du vorab joinst, indem du verwandte Daten duplizierst oder einbettest.

Was relationale Features ersetzt

Joins → Denormalisierung und Single-Table-Design.
Normalisierte Tabellen → Item Collections, unter einem Partition Key gruppiert.
Ad-hoc-SQL → schlüsselbasierte Query und Scan oder PartiQL (eine SQL-kompatible Teilmenge, weiterhin ohne Joins).

PartiQL schließt die Lücke übrigens nicht. Sein Parser lehnt ein SELECT über zwei Tabellen ab und lehnt GROUP BY ab, beides bevor irgendetwas gelesen wird; die genauen Ablehnungen sind unter Unterstützt DynamoDB Joins und Unterstützt DynamoDB SQL zitiert.

Was dich das Denormalisieren tatsächlich kostet

Der Kompromiss wird meist als „Daten duplizieren statt joinen" beschrieben, was nach einer Speicher-Entscheidung klingt. In Wahrheit ist es eine Entscheidung über Writes und Atomarität — und genau den Teil verbergen relationale Engines vor dir.

Nimm einen Kunden mit 5.000 Bestellungen, und der Kunde ändert seinen Anzeigenamen. In einem relationalen Schema ist das ein UPDATE auf einer Zeile, und jeder Join greift sofort den neuen Wert auf. In DynamoDB denormalisiert lebt der Name auf allen 5.000 Bestell-Items — die Umbenennung sind also 5.000 Item-Writes: 5.000 Schreibeinheiten, rund 0,003 $ in us-east-1 On-Demand bei 1 KB pro Item.

Das Geld ist nichts. Das Problem ist, dass es keine einzige Operation sein kann. TransactWriteItems ist bei 100 Aktionen gedeckelt — 5.000 Items sind also mindestens 50 separate Transaktionen, und zwischen ihnen gibt es keine Isolation. Solange dieses Fan-out läuft, widersprechen sich deine eigenen Daten, und jeder Read, der mittendrin landet, sieht eine Mischung aus altem und neuem Namen.

Genau das kaufst du dir mit relationalen Datenbanken: eine atomare Änderung an einer maßgeblichen Kopie. Das aufzugeben ist der eigentliche Eintrittspreis — und deshalb verdient „welche Attribute werden dupliziert" mehr Design-Aufmerksamkeit als „welche werden indiziert".

Tiefer einsteigen

Lies wie man Daten in DynamoDB modelliert und Single-Table-Design. Lade DynoTable herunter, um dein Datenmodell visuell zu erkunden — und mit der SQL Workbench relational geformte JOIN-/GROUP BY-Abfragen darüber auszuführen.

Referenzen

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation; die Obergrenze von 100 Aktionen pro Transaktion wurde am 2026-07-28 erneut aus der API-Referenz abgerufen.