Wann du DynamoDB nutzen solltest (und wann nicht)

DynamoDB ist eine fantastische Datenbank für die Workloads, für die es gebaut ist, und eine frustrierende für alles andere. Die entscheidende Frage lautet: „Kenne ich meine Zugriffsmuster vorab, und sind sie key-basiert?“ Triffst du das richtig, gibt dir DynamoDB Lesevorgänge in einstelligen Millisekunden bei jeder Größe; triffst du es falsch, kämpfst du ewig gegen die fehlenden Joins und Ad-hoc-Abfragen.

Wann sollte ich DynamoDB nutzen?

Nutze DynamoDB, wenn deine Zugriffsmuster bekannt, key-basiert und volumenstark sind und du bei jeder Größe vorhersehbare Latenz in einstelligen Millisekunden willst, ohne einen einzigen Server zu verwalten. Meide es bei Ad-hoc-Abfragen, umfangreichen Joins oder Analytik über den ganzen Datenbestand — und wenn die Daten klein sind und sich die Abfrageformen ständig ändern.

• Nutze DynamoDB, wenn deine Zugriffsmuster bekannt, key-basiert und volumenstark sind — und du bei jeder Größe vorhersehbare Latenz willst, ohne Server zu verwalten.
• Meide es, wenn du Ad-hoc-Abfragen, umfangreiche Joins oder Analytik über den ganzen Datenbestand brauchst, oder wenn die Daten klein sind und sich die Abfrageformen ständig ändern.
• Der Kern-Handel: DynamoDB zwingt dich, vorab für deine Abfragen zu entwerfen; dafür wird es nie langsamer, während du wächst.
• Es ist keine relationale Datenbank mit anderer Syntax — sie wie eine zu modellieren ist die Schmerzquelle Nummer eins.

Die Signale, die für DynamoDB sprechen

DynamoDB glänzt, wenn das meiste davon zutrifft:

• Du kennst deine Zugriffsmuster vorab. Du kannst die genauen Abfragen aufzählen, die die App macht („einen Nutzer über die ID holen“, „Bestellungen eines Nutzers neueste zuerst auflisten“), und sie ändern sich nicht nach Laune. DynamoDB wird rund um diese Abfragen modelliert.
• Der Zugriff ist key-basiert. Du schlägst Items über einen bekannten Partition Key nach, nicht per Scan über beliebige Attributkombinationen.
• Skalierung und vorhersehbare Latenz zählen. DynamoDB liefert durchgehend einstellige Millisekunden an Performance, ob die Tabelle tausend Items hält oder eine Milliarde.
• Du willst null Betriebsaufwand. Keine Instanzen, kein Failover, kein Vacuuming — es ist vollständig verwaltet und skaliert mit On-Demand bis auf null.
• Der Schreibdurchsatz ist hoch und sprunghaft. Event-Logs, IoT-Telemetrie, Session-/Warenkorb-Zustand, Leaderboards — anhänge-lastige Workloads mit einem klaren Key.

Die Signale, die dagegen sprechen

Greif stattdessen zu einer relationalen Datenbank (oder einer Such-/Analytik-Engine), wenn:

• Deine Abfragen ad hoc sind. Analysten schneiden die Daten nach beliebigen Spalten, oder die Anforderungen ändern sich wöchentlich. Dann gewinnt die Flexibilität von SQL; DynamoDB bräuchte einen neuen Index pro Muster.
• Du echte Joins und Aggregationen über den ganzen Datenbestand brauchst. Reporting, Business Intelligence, „Umsatz je Region je Monat summieren“ — das ist eine OLAP-/relationale Aufgabe. (Die einmalige Frage an eine laufende Tabelle ist ein anderer Fall — der SQL Workbench von DynoTable führt JOIN, GROUP BY und Aggregate clientseitig über DynamoDB aus; es ist der dauerhafte BI-Workload, der woanders hingehört.)
• Der Datenbestand ist klein und traffic-arm. Ein paar tausend Zeilen in einer ruhigen Admin-App profitieren nicht von der Skalierung von DynamoDB und verlieren den Komfort von SQL.
• Du kannst die Zugriffsmuster noch nicht vorhersagen. Ein junges Produkt, das seine Form noch sucht? Ein relationales Schema, das du frei neu abfragen kannst, verzeiht mehr, bis sich die Muster gesetzt haben.

Wie sich DynamoDB mit anderen Datenbanken vergleicht

„Soll ich DynamoDB oder X nehmen?“ ist meist dieselbe Frage in anderen Kleidern: Lässt mich X die Entscheidung über die Zugriffsmuster aufschieben, und was zahle ich dafür? DynamoDB ist die Option, die dir das Aufschieben verweigert. Jeder Vergleich unten dreht sich um diesen einen Handel, nicht um Feature-Checklisten.

Relational: PostgreSQL, RDS und Aurora

Das ist die eigentliche Weggabelung, und die, bei der die meisten Teams danebenliegen. Eine relationale Datenbank lässt dich die Abfrage schreiben, nachdem du die Daten hast. DynamoDB nicht — die Tabelle wird von den Abfragen geformt, bevor ein einziges Item geschrieben ist.

Nimm relational, wenn die Abfrageformen noch in Bewegung sind, wenn du Joins oder Aggregate über den ganzen Datenbestand brauchst, oder wenn die Daten klein genug sind, dass Skalierung nicht dein Problem ist. Nimm DynamoDB, wenn die Muster gesetzt und key-basiert sind und du willst, dass sie bei einer Milliarde Items dasselbe kosten wie bei tausend.

RDS und Aurora ändern an dieser Rechnung nichts — sie sind verwaltete relationale Engines und erben damit die Flexibilität von SQL und dessen Skalierungsmodell. Was sie ändern, ist der Betriebsvergleich: Mit Aurora Serverless wird das Argument „keine Server zu verwalten“ für DynamoDB deutlich schwächer, und die Entscheidung fällt sauber auf die Zugriffsmuster zurück. Aurora skaliert Compute; DynamoDB schafft den Begriff ab.

Dokumentenorientiert: MongoDB und DocumentDB

Beide speichern JSON-artige Dokumente, aus der Ferne wirken sie mit DynamoDB also austauschbar. Sind sie nicht. MongoDB indiziert jedes Feld und führt Ad-hoc-Abfragen darauf aus; DynamoDB gibt dir den Partition Key, den Sort Key und die Indizes, die du vorab deklariert hast.

Damit passt MongoDB besser zu sich wandelnden Abfrageformen und DynamoDB besser zu bekannten bei hohem Volumen. DocumentDB sitzt auf der AWS-Seite derselben Linie — es spricht das MongoDB-API, behandle es also als „die Flexibilität von MongoDB mit dem Betriebsmodell von AWS“ und vergleiche es mit DynamoDB genau auf der Achse Flexibilität gegen Vorhersehbarkeit von oben.

Wide-Column: Cassandra

Cassandra ist der engste architektonische Verwandte von DynamoDB: Partition Key, Clustering Key und dieselbe harte Wahrheit, dass ein schlechter Partition Key ein Designfehler ist, aus dem du dich nicht per Index herausindizieren kannst. Wenn du zwischen beiden wählst, sind die entscheidenden Faktoren selten das Datenmodell — es geht darum, wer es betreibt und wie du zahlst. Cassandra betreibst du (oder kaufst es verwaltet); DynamoDB konsumierst du. Amazon Keyspaces ist der Mittelweg mit verwaltetem Cassandra.

Weil die Modelle so nah beieinander liegen, überträgt sich die Modellierungsanleitung auf dieser Seite größtenteils: Die Argumentation aus Single-Table-Design zu Partition Keys und Zugriffsmustern gilt für Cassandra fast Zeile für Zeile.

In-Memory: Redis

Redis und DynamoDB lösen verschiedene Probleme. Redis ist memory-first und für Zugriffe im Sub-Millisekunden-Bereich auf Daten optimiert, deren Verlust du verkraften oder die du neu aufbauen kannst; DynamoDB ist standardmäßig dauerhaft. Die übliche Antwort in Produktion ist beides — DynamoDB als System of Record, Redis (oder DAX, der eigene Read-Through-Cache von DynamoDB) vor den heißen Keys.

Greif nur dann allein zu Redis, wenn die Daten wirklich flüchtig sind: Rate-Limit-Zähler, kurzlebige Sessions, Leaderboards, die du neu berechnen kannst.

Suche: Elasticsearch und OpenSearch

Auch Suche und DynamoDB lösen verschiedene Probleme — aus einem schärferen Grund als bei Redis: DynamoDB hat gar keine Volltextsuche. Query trifft über Key-Gleichheit und eine schmale Menge von Sort-Key-Bedingungen. Scan mit einer FilterExpression liest jedes Item und wirft das meiste davon weg — das ist ein Tabellendurchlauf mit angeschraubtem Filter, keine Suche, und du zahlst für die gelesenen Items, nicht für die zurückgegebenen. Es gibt kein Relevanz-Ranking, keine Analyzer, kein Fuzzy Matching, kein Faceting.

Die Frage lautet also nie „DynamoDB oder eine Suchmaschine“. Sie lautet: „Braucht dieser Workload Suche, und wenn ja, was speist den Index?“ Die Standardform ist beides: DynamoDB als System of Record, ein Suchcluster daneben und DynamoDB Streams, die jede Änderung in den Index tragen. Das bringt dir echte Suche und kostet dich ein zweites System im Betrieb und einen Index, der letztendlich konsistent mit der Tabelle ist.

OpenSearch und Elasticsearch sind dieselbe Entscheidung. OpenSearch ist der AWS-Fork von Elasticsearch, 2021 bei 7.10 wegen der Lizenzänderung von Elastic abgespalten, und beide sind seither auseinandergedriftet. Nichts an dieser Drift berührt diese Frage — für „soll die Suche außerhalb von DynamoDB liegen“ verhalten sie sich identisch. Entscheide zwischen ihnen nach Lizenzierung, Hosting und danach, welchen verwalteten Dienst du betreiben willst, nicht nach irgendetwas, das mit DynamoDB zu tun hat.

Greif nur dann zu einer Suchmaschine als primärem Store, wenn Suche wirklich das Produkt ist — Log-Analytik, ein Katalog, dessen Hauptzugriffsmuster Freitext ist. Selbst dann halten die meisten Teams einen dauerhaften Store dahinter, weil ein Suchindex eine abgeleitete Sicht ist, die du neu aufbauen können musst.

Die Kostenachse, die der Modellvergleich verdeckt

Jeder Vergleich oben dreht sich um Datenmodelle, aber die Überraschung auf der Rechnung ist meist struktureller Natur: Relationale Engines rechnen Kapazität ab, die du provisionierst, DynamoDB rechnet Operationen ab, die du ausführst. Das macht DynamoDB günstig für sprunghafte und untätige Workloads und teuer für dauerhaftes Scannen — derselbe Workload kann auf der einen Engine gewinnen und auf der anderen böse verlieren, ohne eine Zeile Codeänderung dazwischen.

Der Multiplikator, den man übersieht, sind Indizes. Auf einer relationalen Engine kostet ein zusätzlicher Index Speicher und etwas Schreiblatenz; in DynamoDB ist jeder Secondary Index ein vollständiger zusätzlicher Schreibvorgang der projizierten Attribute. Die Rechnung haben wir für drei Schreibvolumen in der Indizes-Anleitung aufgemacht — eine GSI verdoppelt die Schreibrechnung, zwei verdreifachen sie. Modelliere deinen echten Lese-/Schreib-Mix im Preisrechner, bevor du dich auf eine Seite festlegst.

Die Kosten rechnen, bevor du dich festlegst

Die Preisgestaltung von DynamoDB folgt Lesevorgängen, Schreibvorgängen und Speicher — nicht Instanzstunden —, es ist also günstig für sprunghafte und Serverless-Workloads und kann bei dauerhaft schweren Scans teuer werden. Modelliere deinen echten Lese-/Schreib-Mix mit dem DynamoDB-Preisrechner, bevor du dich festlegst; ein Workload, der technisch passend aussieht, sollte auch bei den Kosten aufgehen.

Wenn du entschieden hast, dass es passt

Die Arbeit verlagert sich aufs Modellieren. DynamoDB belohnt es, die Tabelle rund um deine Abfragen zu entwerfen — siehe wie man Daten in DynamoDB modelliert und Single-Table-Design — und ausdrücklich auch, wann man nicht zu Single-Table greift.

Fallstricke + nächste Schritte

• Modelliere DynamoDB nicht wie eine relationale Datenbank — normalisierte Tabellen, die du zur Lesezeit joinst, sind das Anti-Pattern, das es am härtesten bestraft.
• Wähle es nicht für Analytik — kombiniere es fürs Reporting mit einem Analytik-Store (oder exportiere dorthin), statt zu scannen.
• Unsicher bei den Zugriffsmustern? Warte. DynamoDB einzuführen, bevor du deine Abfragen kennst, heißt, ausgerechnet die eine Datenbank zu wählen, die verlangt, dass du sie kennst.
• Verwandt: Query vs. Scan zeigt, was „key-basierter Zugriff“ dir tatsächlich bringt.

Du willst eine DynamoDB-Tabelle erkunden, bevor du deine App darauf setzt? Lade DynoTable herunter und verbinde dich direkt mit deinen Daten — sein SQL Workbench fährt die Ad-hoc-JOINs und Aggregate, die DynamoDB selbst nicht bietet.