DynamoDB vs Redis
DynamoDB und Redis werden beide als NoSQL bezeichnet, sitzen aber auf unterschiedlichen Ebenen des Stacks. DynamoDB ist eine vollständig verwaltete, serverless Datenbank als System of Record, die Daten dauerhaft auf Festplatte über eine gesamte AWS-Region hinweg vorhält. Redis ist ein In-Memory-Datenstrukturspeicher — meist eingesetzt als Cache, Session-Store oder Message Broker vor einer dauerhaften Datenbank. Für viele Systeme lautet die Antwort nicht entweder/oder, sondern DynamoDB als Speicher, Redis (oder DAX) als Cache.
Solltest du DynamoDB oder Redis verwenden?
Verwende DynamoDB als dein dauerhaftes System of Record: strukturierte Items, die du nicht verlieren darfst und die per Key im großen Maßstab gelesen und geschrieben werden. Verwende Redis als In-Memory-Schicht für Lesezugriffe im Mikrosekundenbereich, reichhaltige Datenstrukturen (Sorted Sets, Streams, Zähler), Caching, Rate Limiting oder Pub/Sub. Sie werden häufig kombiniert — Redis (oder DynamoDBs eigener DAX-Cache) sitzt vor DynamoDB, statt es zu ersetzen.
DynamoDB vs Redis auf einen Blick
| Merkmal | DynamoDB | Redis |
|---|---|---|
| Datenmodell | NoSQL Key-Value und Dokument; typisierte Items bis zu 400 KB, gruppiert in Tabellen | In-Memory Key-Value mit typisierten Werten — Strings, Hashes, Listen, Sets, Sorted Sets, Streams und mehr |
| Primäre Rolle | Dauerhafte Datenbank als System of Record | In-Memory-Cache, Session-/Rate-Limit-Store, Message Broker; kann mit aktivierter Persistenz auch primärer Speicher sein |
| Abfragesprache / API | Native API (GetItem, Query, Scan, PutItem, …) plus PartiQL, eine SQL-kompatible Sprache | Befehle pro Datenstruktur (GET, HSET, ZADD, XADD, …); keine allgemeine Abfragesprache oder Ad-hoc-Joins |
| Dauerhaftigkeit | Daten auf Festplatte persistiert und über Availability Zones einer Region repliziert | Standardmäßig In-Memory; Dauerhaftigkeit optional über RDB-Snapshots und/oder AOF-Append-only-Logging |
| Konsistenz | Standardmäßig letztendlich konsistent; stark konsistente Lesevorgänge pro Anfrage verfügbar | Ein einzelner Node ist stark konsistent für seine Keys; Replikate sind asynchron, sodass Replikat-Lesevorgänge nachhinken können |
| Skalierungsmodell | Automatische Partitionierung durch AWS verwaltet; serverless, skaliert Durchsatz und Speicher | Vertikal (RAM-gebunden) plus Redis Cluster für horizontales Sharding über Nodes; Kapazität durch Speicher begrenzt |
| Latenzprofil | Lese-/Schreibvorgänge im einstelligen Millisekundenbereich bei jeder Skalierung | Operationen im Mikrosekundenbereich, weil die Daten im RAM liegen |
| Preis- / Ops-Modell | Serverless Pay-per-Request oder Provisioned-Kapazität plus Speicher; nur AWS, keine Server zu betreiben | Open Source (self-hosted) oder verwaltet (z. B. Redis Cloud, ElastiCache); typischerweise nach Node-Speicher/Durchsatz abgerechnet |
| Am besten geeignet für | Dauerhafte Datensätze mit vorhersehbarem Key-Zugriff, die konsistente Latenz im großen Maßstab benötigen | Caching, Ranglisten, Zähler, Rate Limiting, Warteschlangen, Pub/Sub, kurzlebige Session-Daten |
Wann DynamoDB die bessere Wahl ist
- Die Daten müssen erhalten bleiben. DynamoDB persistiert jeden Schreibvorgang auf Festplatte und repliziert ihn über Availability Zones. Redis ist zuerst In-Memory; ohne RDB/AOF-Persistenz gehen bei einem Neustart Daten verloren, und selbst mit Persistenz ist es eher auf Geschwindigkeit als auf garantierte Dauerhaftigkeit ausgelegt.
- Du brauchst ein System of Record auf AWS. DynamoDB integriert sich nativ mit IAM, Lambda und Streams und bietet Point-in-Time-Recovery sowie Backups als Konfiguration.
- Dein Working Set ist größer als der Speicher. DynamoDB speichert Daten auf Festplatte, sodass die Kosten mit dem Speicher statt mit dem RAM skalieren. Die Kapazität von Redis ist durch den bereitgestellten Speicher begrenzt.
- Du willst serverless Skalierung. On-Demand-Kapazität skaliert mit dem Traffic, ohne dass etwas dimensioniert oder gepatcht werden muss.
Wann Redis die bessere Wahl ist
- Du brauchst Latenz im Mikrosekundenbereich. Redis hält Daten im RAM, sodass Operationen in Mikrosekunden abgeschlossen werden — eine Stufe unter DynamoDBs einstelligem Millisekundenprofil.
- Du brauchst reichhaltige In-Memory-Datenstrukturen. Sorted Sets für Ranglisten, atomare Zähler, Listen für Warteschlangen und Streams für Event-Fan-out sind erstklassige Redis-Operationen, nicht etwas, das du in einem dauerhaften Speicher modellierst.
- Die Daten sind kurzlebig oder cache-artig. Session-Token, Rate-Limit-Fenster und berechnete Ergebnisse, die neu erzeugt werden können, passen zu Redis' In-Memory-Modell, oft mit einer kurzen TTL.
- Du brauchst Pub/Sub oder einen leichtgewichtigen Message Broker. Redis bietet Publish/Subscribe- und Stream-Primitive out of the box.
Beide zusammen einsetzen
Das häufigste Produktionsmuster ist nicht, eines zu wählen — es besteht darin, sie zu schichten:
- Halte die dauerhaften Datensätze in DynamoDB als Single Source of Truth.
- Setze Redis davor als Read-Cache für heiße Keys, oder nutze es für Ranglisten, Zähler und Rate Limiting neben DynamoDB.
- Wenn du Caching willst, ohne Redis selbst zu betreiben, bietet DynamoDB den DynamoDB Accelerator (DAX) — einen vollständig verwalteten, DynamoDB-API-kompatiblen In-Memory-Cache, der die Latenz letztendlich konsistenter Lesevorgänge ohne Anwendungsänderungen von Millisekunden auf Mikrosekunden reduziert. DAX arbeitet Read-through/Write-through und cached Items nach Primärschlüssel.
DAX gegenüber Redis ist selbst ein Trade-off: DAX ist DynamoDB-spezifisch und drop-in, während Redis ein universeller Datenstrukturspeicher ist, den du über viele Datenquellen hinweg nutzen kannst, aber selbst betreiben oder einen verwalteten Anbieter dafür bezahlen musst.
Arbeiten mit DynamoDB
Sobald DynamoDB dein dauerhafter Speicher ist, ist DynoTable ein nativer Desktop-Client zum Durchsuchen, Bearbeiten und Abfragen deiner Tabellen unter macOS, Windows und Linux. Er liest deine standardmäßige AWS-Credential-Chain, sodass es nichts zu migrieren gibt — richte ihn auf deine Region und Tabellen aus, und deine Daten bleiben in DynamoDB. Sein SQL Workbench drückt relational geformte Abfragen innerhalb der Access-Pattern-Regeln von DynamoDB aus, und sein KI-Assistent läuft mit deinen eigenen AWS-Bedrock-Credentials.
Für den Aufbau der Key Conditions, Filter und Update-Expressions, die dein Caching- und Record-Keeping-Code braucht, generiert der kostenlose DynamoDB Expression Builder fertig einfügbare SDK-, CLI- und PartiQL-Ausgaben ohne Installation. DynoTable ist eine Closed-Source-Kommerz-App; diese Seite beschreibt, was sie tut, nicht wie sie gebaut ist.
FAQ
Kann Redis DynamoDB ersetzen?
Meist nicht als System of Record. Redis ist zuerst In-Memory, sodass es — solange du seine Persistenz nicht aktivierst und abstimmst — als Cache oder kurzlebiger Speicher konzipiert ist, nicht als dauerhafte Datenbank. DynamoDB persistiert und repliziert jeden Schreibvorgang über Availability Zones. Viele Teams nutzen beides: DynamoDB für dauerhafte Daten, Redis (oder DAX) als schnelle In-Memory-Schicht davor.
Ist DynamoDB oder Redis schneller?
Redis ist pro Operation schneller, weil es Daten in Mikrosekunden aus dem RAM liefert, während DynamoDB auf Lese- und Schreibvorgänge im einstelligen Millisekundenbereich aus dauerhaftem Speicher abzielt. Wenn du DynamoDB mit cache-artiger Latenz brauchst, bringt DAX letztendlich konsistente Lesevorgänge in den Mikrosekundenbereich, ohne die DynamoDB-API zu verlassen.
Was ist das DynamoDB-Äquivalent zum Redis-Caching?
DynamoDB Accelerator (DAX) ist AWS' integrierter, vollständig verwalteter In-Memory-Cache für DynamoDB. Er ist API-kompatibel, sodass bestehende DynamoDB-Aufrufe unverändert funktionieren, und cached Items nach Primärschlüssel als Read-through/Write-through-Schicht. Er ist DynamoDB-spezifisch, während Redis ein universeller Datenstrukturspeicher ist.
Verwandt
- Lerne, wann man DynamoDB verwendet und wie DynamoDB TTL kurzlebige, cache-artige Items verfallen lässt.
- Modelliere dauerhafte Zugriffsmuster mit Single-Table-Design.
- Baue Expressions mit dem kostenlosen DynamoDB Expression Builder.
- DynoTable herunterladen, um deine DynamoDB-Tabellen zu durchsuchen, abzufragen und zu bearbeiten.
Zuletzt verifiziert am 2026-07-12 anhand des offiziellen AWS DynamoDB Developer Guide und der Redis-Dokumentation. Redis ist eine Marke des jeweiligen Inhabers; hier nur zur Identifikation genannt.