Wann solltest du DynamoDB nicht verwenden?

Lass DynamoDB aus, wenn dein Workload analytisch ist oder deine Zugriffsmuster unbekannt sind. DynamoDB ist gezielt für operative (OLTP) Workloads mit bekannten, schlüsselbasierten Zugriffsmustern gebaut — es hat keine Joins und keine Aggregatfunktionen, und Ad-hoc-Abfragen fallen auf teure Full-Table-Scans zurück. Für OLAP-Reporting oder sich entwickelnde relationale Anforderungen nimm eine andere Engine.

Schlechte Passungen

Ad-hoc-Analysen und Reporting (OLAP) — es gibt kein GROUP BY, kein SUM, kein AVG; jede Auswertung ist ein Scan oder ein vorberechnetes Aggregat, das du selbst pflegst. Die Umwege stehen im Aggregations-Leitfaden.
Normalisierte relationale Schemas — DynamoDB lässt den JOIN-Operator bewusst weg; AWS' eigene Empfehlung lautet, zu denormalisieren.
Unbekannte oder sich schnell entwickelnde Zugriffsmuster — du entwirfst die Keys um die Abfragen herum. Wenn du die Abfragen noch nicht benennen kannst, riskiert jede neue eine Neugestaltung der Tabelle oder einen vollständigen Scan.
Volltextsuche und reichhaltiges Abfragen — siehe Unterstützt DynamoDB Volltextsuche?; Suche gehört in einen Suchindex.
Große Objekte — Items sind bei 400 KB gedeckelt; Medien und Dokumente gehören nach S3, mit einem Pointer in der Tabelle.

Die Auswertung: erst abgelehnt, dann bepreist

Die analytische Fehlpassung ist keine Geschmacksfrage. Frag DynamoDB in PartiQL nach einer gruppierten Zählung, und das Statement wird abgelehnt, bevor es irgendetwas liest:

SELECT status, COUNT(*) FROM "orders" GROUP BY status

ValidationException: Unsupported clause: GROUP BY
HTTP 400

Lass die Gruppierung weg und frag nach der schlichten Gesamtzahl, und es scheitert einen Schritt früher, im Parser:

SELECT COUNT(*) FROM "orders"

ValidationException: Unexpected path component at 1:8:5
HTTP 400

COUNT ist in diesem Dialekt überhaupt keine Funktion — der Parser liest es als Attributpfad und gibt an der Klammer auf.

Bleibt der Scan, den du selbst schreibst, und der hat einen Preis. Eine 50-GB-Tabelle von Anfang bis Ende zu lesen kostet 6.553.600 letztendlich konsistente Leseeinheiten, also die kumulierte gescannte Größe in 4-KB-Einheiten, halbiert. In us-east-1 On-Demand sind das 0,82 $.

Aktualisiere diese eine Zahl stündlich, und es sind 598 $ pro Monat. Den Zähler beim Schreiben mitzuführen oder in einen Analytics-Store zu exportieren ist die günstigere Antwort — und beides ist Arbeit, die DynamoDB dir nicht abnimmt.

Wo es glänzt

Die umgekehrte Liste ist genau DynamoDBs Stärke: operative Workloads mit hohem Volumen und vorhersehbaren, schlüsselbasierten Reads und Writes, die bei jeder Skalierung einstellig millisekundenschnell bleiben müssen — Warenkörbe, Sessions, Profile, Spielstände, IoT-Events. Der Leitfaden, wann man DynamoDB einsetzt macht die positive Seite auf.

Tiefer einsteigen

Wenn du unentschieden bist, lies als Nächstes wann man DynamoDB nutzt. Schon auf DynamoDB und vermisst SQL? DynoTable führt JOIN und GROUP BY gegen Live-Tabellen vom Desktop aus — und der Preisrechner sagt dir, was dein Workload kosten würde, bevor du dich festlegst.

Referenzen

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation. Die 400-KB-Angabe wurde am 2026-07-28 erneut bestätigt; AWS hat sie von der Service-Quotas-Seite nach Constraints.html verschoben.

Am 2026-07-28 gegen DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 auf Node v24.18.0 reproduziert; beide ValidationException-Meldungen sind wortgetreu. Die Scan-Kosten sind aus den us-east-1-Tarifen unserer synchronisierten AWS-Preistabelle berechnet.