Ist DynamoDB eine NoSQL-Datenbank?

Ja. DynamoDB ist eine NoSQL-Datenbank — ein nicht relationaler, vollständig verwalteter Key-Value- und Dokumentspeicher. Er hält schemalose Items statt Zeilen in Tabellen mit festem Schema und tauscht SQL-Joins und Ad-hoc-Abfragen gegen berechenbare Antwortzeiten im einstelligen Millisekundenbereich und horizontale Skalierung auf praktisch jede Größe.

Welche Art von NoSQL

DynamoDB unterstützt sowohl das Key-Value- als auch das Dokumentmodell. Jedes Item wird über einen Primärschlüssel adressiert, und Attribute dürfen sich als Maps und Listen bis zu 32 Ebenen tief verschachteln — das ist die Dokumentseite des Modells.

Worin es sich von SQL unterscheidet

Kein festes Schema — nur der Primärschlüssel wird vorab definiert; die übrigen Attribute unterscheiden sich von Item zu Item.
Keine Joins — stattdessen denormalisierst du und modellierst entlang deiner Zugriffsmuster.
Berechenbare Performance — Reads treffen einen Partitionsschlüssel, die Latenz bleibt also flach, während die Daten wachsen.

Was die Engine mit einem JOIN macht

PartiQL lässt DynamoDB SQL-förmig aussehen, deshalb ist die Grenze leicht zu übersehen. Die von AWS dokumentierte SELECT-Syntax ist die vollständige Grammatik, und sie enthält keine JOIN-Klausel:

SELECT {{expression}}  [, ...]
FROM {{table}}[.{{index}}]
[ WHERE {{condition}} ] [ [ORDER BY {{key}} [DESC|ASC] , ...]

Schick trotzdem einen, und der Parser bleibt bei der zweiten Tabelle stehen:

await client.send(
  new ExecuteStatementCommand({
    Statement: `SELECT o.pk FROM "orders" o JOIN "customers" c ON o.pk = c.pk`
  })
);

Die tatsächliche Ausgabe:

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

Die Ablehnung passiert zur Parse-Zeit, bevor auch nur ein Datensatz gelesen wird — deshalb bringt dich kein noch so gutes Index-Design zu einem Join. Joins sind in einem NoSQL-Store Aufgabe deiner Anwendung.

Das begrenzt auch, was ein Client ehrlicherweise anbieten kann. Die SQL Workbench von DynoTable akzeptiert INNER JOIN, LEFT JOIN, GROUP BY sowie COUNT/SUM/AVG/MIN/MAX.

Sie kompiliert das zu nativen Query- und Scan-Aufrufen und verknüpft und aggregiert die Ergebnisse dann auf deinem Rechner. DynamoDB selbst sieht weiterhin nur Reads auf einer einzelnen Tabelle.

Wann es passt

DynamoDB ist für OLTP-Workloads gebaut: Reads und Writes in hoher Frequenz auf bekannte Punkte und Bereiche. Schwere Analytik gehört in einen separaten spaltenorientierten Store, den du per Export befüllst.

NoSQL-Grenzen, die du in Produktion trotzdem spürst

„NoSQL" beschreibt das Zugriffsmodell, nicht den Wegfall von Grenzen. DynamoDB deckelt dich weiterhin bei 400 KB pro Item, 25 Aktionen pro TransactWriteItems und 100 Lese- oder Schreibaktionen pro Transaktion. Ein verschachteltes Dokument darf 32 Ebenen tief sein. GSIs projizieren nur die Attribute, die du benennst; es gibt kein verborgenes Schema, auf das du zurückfallen könntest.

Diese Grenzen sind deshalb wichtig, weil du dich zur Abfragezeit nicht per Join aus ihnen herausmanövrieren kannst. Du modellierst vorab um sie herum — Sparse Indexes, denormalisierte Attribute und Single-Table-Schlüssel — und liest dann pro Partition. Der Query Builder macht aus einem Filter genau den Query- oder Scan-Request, den DynamoDB am Ende ausführt.

In DynoTable: Wenn eine relationale Frage berechtigt ist, kompiliert die SQL Workbench JOIN und GROUP BY auf deinem Rechner zu nativen Query- und Scan-Aufrufen herunter — DynamoDB sieht weiterhin nur Reads auf einer einzelnen Tabelle. Siehe SQL Workbench für die unterstützte Grammatik und die ehrlichen Grenzen.

Tiefer einsteigen

Sieh dir an, wann du DynamoDB einsetzen solltest und wie du Daten formst unter wie du Daten in DynamoDB modellierst. Lade DynoTable herunter, um deine NoSQL-Tabellen zu durchsuchen und SQL darüber auszuführen — innerhalb der Zugriffsmuster-Regeln von DynamoDB.

Referenzen

Zuletzt überprüft am 13.07.2026 anhand der oben verlinkten offiziellen AWS-Dokumentation; die PartiQL-SELECT-Grammatik wurde am 28.07.2026 erneut geprüft.

Am 28.07.2026 gegen DynamoDB Local 3.3.0 über @aws-sdk/client-dynamodb 3.1095.0 auf Node v24.18.0 reproduziert. Die ValidationException oben ist wortgetreue Ausgabe der Engine.