Unterstützt DynamoDB Joins?

Nicht in der Datenbank selbst. DynamoDB ist eine nichtrelationale Datenbank und kennt keine JOIN-Operation, und PartiQL fügt keine hinzu. Für Lesevorgänge in Produktion modellierst du zusammengehörige Daten deshalb anders: Du denormalisierst sie (dupliziere oder bette sie ein, damit jedes Zugriffsmuster eine einzige Abfrage ist) oder du nutzt Single-Table-Design, um zusammengehörige Items unter einem Partition Key zusammenzulegen. Einen echten Join über deine DynamoDB-Tabellen kannst du trotzdem ausführen – aus einem Client heraus: Die SQL Workbench von DynoTable führt echte JOIN-, GROUP BY- und Aggregat-Abfragen über deine Live-Daten aus.

Warum die Datenbank kein Join kennt

DynamoDB ist auf vorhersehbare Lesevorgänge im einstelligen Millisekundenbereich ausgelegt, bei jeder Größenordnung. Würde beim Lesen gejoint, hinge die Latenz davon ab, wie viele zusammengehörige Daten es gibt – und genau diese Zusage wäre dahin. Für deine modellierten Zugriffsmuster passiert der Join deshalb beim Schreiben, und zwar durch dich.

Was passiert, wenn du es versuchst

PartiQL lehnt die Anweisung schon im Parser ab, bevor irgendetwas gelesen wird. Der explizite Join und der Komma-Cross-Join scheitern gleichermaßen:

SELECT o."total", c."name" FROM "Orders" o JOIN "Customers" c ON o."pk" = c."id"
SELECT * FROM "Orders", "Customers"

ValidationException: Only select from a single table or index is supported.
HTTP 400

Es gibt also keinen langsamen, aber funktionierenden Notweg, den man in Produktion noch entdecken könnte. Eine Anweisung, die zwei Tabellen nennt, ist ein Syntaxfehler, und die Arbeit muss woandershin: in dein Datenmodell oder in einen Client, der den relationalen Teil selbst übernimmt.

Was du für modellierte Zugriffsmuster tust

Denormalisierung – kopiere oder bette die zusammengehörigen Daten ein, die du gemeinsam liest.
Single-Table-Design – speichere mehrere Entitätstypen mit überladenen Keys in einer Tabelle, sodass eine Item-Collection sie in einer einzigen Query gemeinsam liest.
Adjazenzlisten – modelliere Viele-zu-viele-Beziehungen als Items, die du über den Key abfragst.

Damit bleibt jeder Lesevorgang in Produktion eine einzige Anfrage. Der ausführliche Weg dorthin steht unter DynamoDB-Joins.

Einen echten JOIN mit DynoTable ausführen

Für die spontane, tabellenübergreifende Frage, die du nicht modelliert hast – „welche EU-Kunden haben letzten Monat über 500 $ ausgegeben?“ über eine Tabelle Orders und eine Tabelle Customers – führt DynoTable diesen Join für dich aus. Es ist ein Desktop-Client für DynamoDB, und seine SQL Workbench führt echte JOIN-, GROUP BY- und Aggregat-Abfragen aus: Sie liest die Items über die normale DynamoDB-API und rechnet den relationalen Teil der Abfrage anschließend im Client. Deshalb funktioniert das hier, gegen Tabellen ohne definierte Beziehung und mit einer Abfrage-Engine ohne das Schlüsselwort JOIN:

SELECT   c.name, SUM(o.total) AS spend
FROM     Customers c
JOIN     Orders o ON o.customerId = c.id
WHERE    c.region = 'EU'
GROUP BY c.name

Du schreibst lieber kein SQL? Smart Tables sind die visuelle Spur derselben Join-Engine: Zieh auf einem Canvas eine Beziehungslinie zwischen zwei Tabellen und blättere durch die verbundenen Zeilen.

Der ehrliche Vorbehalt – „innerhalb von DynamoDBs Zugriffsmuster-Regeln“: Die Workbench liest weiterhin über DynamoDB, die schnellsten Joins sind also die, deren ON-Attribut oder WHERE-Klausel auf mindestens einer Seite einen Partition Key oder einen GSI trifft, sodass DynamoDB eine Query statt eines vollen Scans ausführen kann. Zum Verhalten der Workbench siehe /docs/dynamodb-sql-workbench, zum visuellen Join-Canvas /docs/smart-tables. DynoTable lässt dich die Join-Frage stellen, statt Ergebnisse im Code von Hand zusammenzunähen; die Einschränkungen von oben hebt es damit nicht auf. Unter den GUI-Clients für DynamoDB ist es das einzige „ja, du kannst joinen“, das tatsächlich stimmt: PartiQL und AWS' eigene NoSQL Workbench enden beide an der Ein-Tabellen-Wand.

Für Lesevorgänge auf einer einzigen Tabelle, die Joins ganz vermeiden, skizzierst du überladene Keys im Werkzeug für Single-Table-Design, bevor du denormalisierte Kopien zusammengehöriger Daten modellierst.

Der Kompromiss

Für Lesepfade in Produktion steckst du mehr Sorgfalt in die Schreibvorgänge, damit die Lesevorgänge billig und in konstanter Zeit laufen.

Tiefer einsteigen

Lies DynamoDB-Joins, Single-Table-Design und Eins-zu-viele-Beziehungen. Lade DynoTable herunter, um einen echten JOIN über deine Tabellen auszuführen – in SQL oder visuell mit Smart Tables.

Referenzen

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

Die ValidationException oben wurde am 28.07.2026 gegen DynamoDB Local 3.3.0 über @aws-sdk/client-dynamodb 3.1095.0 reproduziert und wird wörtlich zitiert.