DynamoDB vs Redshift

DynamoDB und Amazon Redshift sind selten Alternativen zueinander. DynamoDB ist eine operative Datenbank — Lese- und Schreibvorgänge im einstelligen Millisekundenbereich gegen bekannte Keys, die den Live-Traffic einer Anwendung bedienen. Redshift ist „ein vollständig verwalteter Data-Warehouse-Service im Petabyte-Maßstab in der Cloud", gebaut, um große Datenmengen für Reporting und Analytics zu scannen und zu aggregieren. Teams, die beides betreiben, sind der Normalfall, und AWS liefert eine verwaltete Integration mit, die Daten in eine Richtung zwischen ihnen bewegt.

Solltest du DynamoDB oder Redshift verwenden?

Verwende DynamoDB für die Live-Daten der Anwendung: Bestellungen, die aufgegeben werden, Sessions, die gelesen werden, Datensätze, die per Key geholt werden. Verwende Redshift, wenn jemand Fragen über den gesamten Datenbestand stellen muss — Umsatz nach Region und Monat, Kohortenbindung, ein Dashboard, das mehrere Quellen verbindet. Die Frage „welches von beiden" löst sich meist auf in „DynamoDB für den Schreibpfad, Redshift für die Analysten", mit der Zero-ETL-Integration dazwischen.

DynamoDB vs Redshift auf einen Blick

Wann DynamoDB die bessere Wahl ist

• Live-Traffic der Anwendung. Vorhersehbare Lese- und Schreibvorgänge im einstelligen Millisekundenbereich gegen bekannte Keys, bei jeder Anfragerate.
• Schema, das pro Item variiert. Heterogene Items in einer Tabelle sind in DynamoDB normal; ein Warehouse will deklarierte Spalten.
• Serverless Betrieb. Kein Cluster zu dimensionieren, zu patchen oder zu pausieren.
• Schreiblastige Pfade. DynamoDB nimmt Schreibvorgänge in hohem Volumen als seine Hauptaufgabe auf; ein Warehouse ist auf Bulk-Load und Lesen optimiert.

Wann Redshift die bessere Wahl ist

• Fragen, die die ganze Tabelle betreffen. Ein Jahr Bestellungen zu aggregieren ist von Natur aus ein Scan — genau das Zugriffsmuster, das DynamoDB dich zu vermeiden bittet und für das Redshift gebaut ist.
• Joins über viele Quellen. Warehouses joinen. DynamoDB hat keinen serverseitigen Join.
• BI-Tooling. Redshift spricht SQL über JDBC/ODBC, fügt sich also in bestehende Dashboards ein und in „dieselben SQL-basierten Tools und Business-Intelligence-Anwendungen, die du heute schon nutzt".
• Analysen, die die Produktion nicht stören dürfen. Analytics gegen eine replizierte Kopie laufen zu lassen hält die Last von der Tabelle fern, die deine Nutzer bedient.

Beide zusammen einsetzen

Das Standardmuster ist einseitig gerichtet: DynamoDB bedient die Anwendung, eine Kopie landet in Redshift, Analysten arbeiten auf der Kopie. AWS unterstützt zwei Wege — den älteren COPY-Befehl, der direkt „aus Amazon S3 oder Amazon DynamoDB in Amazon Redshift" lädt, und die verwaltete Zero-ETL-Integration, die die Kopie von selbst aktuell hält.

Was die Zero-ETL-Integration tatsächlich tut

„Zero-ETL" legt eine Live-Sicht nahe. Sie ist keine, und die Details zählen, bevor du ein Dashboard darauf auslegst.

Es ist eine Replikations-Pipeline mit Zeitschaltuhr. AWS ist präzise: „Bei der Aktivierung exportiert die Integration die vollständige DynamoDB-Tabelle, um die Amazon-Redshift-Datenbank zu befüllen." Dann „repliziert die Zero-ETL-Integration Updates alle 15-30 Minuten inkrementell von DynamoDB nach Amazon Redshift, mithilfe inkrementeller DynamoDB-Exporte". Die Daten in Redshift sind also bis zu eine halbe Stunde alt. Das ist für tägliches Reporting in Ordnung und falsch für alles, was einem Nutzer seine letzte Aktion widerspiegeln soll.

Point-in-Time-Recovery ist Pflicht — und der Grund liegt jetzt auf der Hand. Die Voraussetzung ist klar formuliert: „Eine Zero-ETL-Integration zwischen Amazon DynamoDB und Amazon Redshift setzt voraus, dass für deine DynamoDB-Quelltabelle Point-in-time recovery (PITR) aktiviert ist." AWS dokumentiert die Anforderung an der einen Stelle und den Mechanismus an einer anderen und verbindet beides nicht, aber die ressourcenbasierte Policy, die du anhängen musst, verrät das Spiel — sie gewährt redshift.amazonaws.com die Aktion dynamodb:ExportTableToPointInTime. Die Integration baut auf DynamoDBs Export-nach-S3-Maschinerie auf, und diese Maschinerie liest aus dem kontinuierlichen Backup. Kein PITR, kein Export, keine Integration.

Das hat eine Budgetfolge, der man spät begegnet: PITR auf einer großen Tabelle zu aktivieren ist eine laufende Gebühr auf die Größe der Tabelle, die für die Analytics-Pipeline anfällt und nicht für die Wiederherstellung. Kalkuliere die Integration als „Redshift plus PITR", nicht als Redshift allein — der kostenlose DynamoDB-Preisrechner dimensioniert die Speicherseite davon, bevor du dich festlegst.

Zwei Einschränkungen, die bestehende Tabellen blockieren. Beide sind dokumentierte Limitierungen, und beide sind im Nachhinein unangenehm zu beheben:

• „Die DynamoDB-Tabelle und das Amazon-Redshift-Cluster müssen sich in derselben Region befinden." Ein Warehouse, das mehrere Regionen konsolidiert, kann sie über diesen Weg nicht alle hereinholen.
• „Die DynamoDB-Quelltabelle muss entweder mit einem Amazon-eigenen oder einem kundenverwalteten AWS-KMS-Schlüssel verschlüsselt sein. Von Amazon verwaltete Verschlüsselung wird für die DynamoDB-Quelltabelle nicht unterstützt." Bei Tabellen, die unter AWS-verwalteter Verschlüsselung angelegt wurden, müssen die Verschlüsselungseinstellungen geändert werden, bevor eine Integration erstellt werden kann.

Wo dich die Form deiner Daten beißt. DynamoDB-Items sind konstruktionsbedingt heterogen; Warehouse-Tabellen haben Spalten. Ein Single-Table-Design, das mehrere Entitätstypen unter einer Partition-Key-Konvention hält, wird nicht dadurch zu einem sauberen Star Schema, dass es repliziert wird. Plane Modellierungsarbeit in Redshift ein, nachdem die Daten gelandet sind — die Integration nimmt dir die Pipeline ab, nicht den Schemaentwurf.

Wann du noch kein Warehouse brauchst

Nicht jedes Aggregat ist ein Analytics-Problem. Ein großer Teil von „das sollten wir nach Redshift bringen" beginnt als eine einzelne Frage — wie viele Items sind in diesem Zustand, wie hoch ist die Summe für diesen Kunden, welche Partition Keys dominieren —, gelegentlich gestellt, von einer entwickelnden Person, gegen eine Tabelle.

Das SQL Workbench von DynoTable beantwortet diese Klasse von Fragen direkt gegen DynamoDB, auf Abruf: echtes SQL mit COUNT, SUM, AVG, MIN, MAX, GROUP BY, HAVING und DISTINCT, plus INNER/LEFT JOIN. Die Positionierung ist bewusst eng — SQL innerhalb der Access-Pattern-Regeln von DynamoDB. Es ist ein einzelnes SELECT; es gibt keine CTEs, kein UNION, keine Window Functions und keine skalaren Subqueries; ein Join-Ziel muss ein Partition Key oder ein GSI-Partition-Key sein. Ergebnisse streamen mit einem Teilergebnis-Badge und werden exakt, sobald die Abfrage bis zum Ende läuft, und die Daten zu lesen kostet weiterhin die Lesevorgänge, die es kostet.

Das ist kein Ersatz für ein Warehouse, und die obigen Grenzen sind die ehrliche Abgrenzung. Aber es ist eine schnellere Antwort als eine Replikations-Pipeline, eine PITR-Gebühr und ein Schemaentwurf — und es sagt dir, ob die Frage ein Warehouse wert war, bevor du eines baust. Workbench-Abfragen auszuführen ist eine kostenpflichtige Funktion; Editor und Autovervollständigung sind kostenlos. DynoTable ist eine Closed-Source-Kommerz-App; diese Seite beschreibt, was sie tut, nicht wie sie gebaut ist.

FAQ

Kann Redshift DynamoDB ersetzen?

Nein, nicht für Anwendungs-Traffic. Redshift ist ein Data Warehouse, gebaut zum Scannen und Aggregieren; es ist nicht darauf ausgelegt, Key-Lookups in hohem Volumen mit Latenz im einstelligen Millisekundenbereich zu bedienen. Die beiden laufen nebeneinander, wobei DynamoDB die Anwendung bedient und eine replizierte Kopie in Redshift die Analytics.

Wie aktuell sind DynamoDB-Daten in Redshift?

Mit der Zero-ETL-Integration bis zu etwa 30 Minuten alt. AWS dokumentiert, dass sie nach dem initialen vollständigen Export „Updates alle 15-30 Minuten inkrementell von DynamoDB nach Amazon Redshift repliziert, mithilfe inkrementeller DynamoDB-Exporte". Behandle es als Reporting nahe Echtzeit, nicht als Live-Sicht.

Warum verlangt die Zero-ETL-Integration PITR?

Weil sie auf DynamoDBs Point-in-Time-Export aufbaut. Die ressourcenbasierte Policy, die die Integration braucht, gewährt Amazon Redshift die Aktion dynamodb:ExportTableToPointInTime, und dieser Export liest aus dem kontinuierlichen Backup, das PITR pflegt. PITR zu aktivieren ist deshalb ein realer, laufender Kostenpunkt der Integration.

Verwandt

• Lerne, wann man DynamoDB verwendet und warum Scans teuer sind.
• Vergleiche DynamoDB und PostgreSQL für die operative relationale Frage.
• Modelliere Zugriffsmuster von Anfang an mit Single-Table-Design.
• Dimensioniere die Speicher- und Kapazitätsseite mit dem kostenlosen DynamoDB-Preisrechner.
• DynoTable herunterladen, um deine DynamoDB-Tabellen direkt abzufragen und zu aggregieren.

Referenzen

• Was ist Amazon Redshift?
• DynamoDB Zero-ETL-Integration mit Amazon Redshift
• Zero-ETL-Integrationen — Amazon Redshift Management Guide
• Point-in-Time-Recovery für DynamoDB
• Was ist Amazon DynamoDB?

Zuletzt verifiziert am 2026-08-02 anhand des offiziellen AWS Redshift Management Guide und des DynamoDB Developer Guide.