Wie schnell ist DynamoDB?

Schnell. DynamoDB liefert bei beliebiger Skalierung konstante Lese- und Schreiblatenzen im einstelligen Millisekundenbereich. Ergänzt du DynamoDB Accelerator (DAX), einen In-Memory-Cache, sinken letztendlich konsistente Reads auf Mikrosekunden. Die Performance bleibt flach, während Tabellen wachsen, weil Reads direkt auf einen Partition Key zielen statt zu scannen — die Latenz verschlechtert sich also nicht mit dem Datenvolumen.

Warum es bei Skalierung schnell bleibt

Ein GetItem oder Query hasht den Partition Key und geht direkt auf die richtige physische Partition. Es scannt nie die ganze Tabelle, die Antwortzeit ist also ungefähr konstant — ob die Tabelle Tausende oder Milliarden von Items hat.

Mikrosekunden-Reads mit DAX

DAX ist ein vollständig verwalteter, DynamoDB-kompatibler In-Memory-Cache, der sich vor deine Tabelle setzt. Er liefert letztendlich konsistente Reads in Mikrosekunden — bis zu 10-mal besser als Millisekunden — ohne Cache-Invalidierung, die du verwalten müsstest. Für Workloads, die stark konsistente Reads brauchen, passt er nicht.

Die Zahl, die deine Nutzer tatsächlich sehen

Einstellige Millisekunden werden am DynamoDB-Endpoint gemessen. Was deine Anwendung erlebt, ist das plus das Netzwerk — und das Netzwerk ist meist die deutlich größere Hälfte.

Am 2026-07-28 von einer Maschine in Spanien gemessen, neun Stichproben pro Region, Median des TCP-Handshakes zu jedem regionalen DynamoDB-Endpoint. Das ist ein Round-Trip, bevor auch nur ein Byte Anfrage gesendet wird:

Region	Median TCP-Handshake
eu-central-1 (Frankfurt)	46,6 ms
eu-south-2 (Spanien)	49,1 ms
eu-west-1 (Irland)	53,8 ms
us-east-1 (N. Virginia)	113,6 ms
ap-northeast-1 (Tokio)	259,5 ms

Eine Maschine, ein ISP, ein Nachmittag — lies das also als Größenordnungen und nicht als Benchmark. Zwei Dinge darin gelten allgemein. Ein transatlantischer Round-Trip ist mehr als das Zehnfache des Reads, den er transportiert — auf dieser Distanz ist DynamoDBs Latenz ein Rundungsfehler in deiner. Und die geografisch nächstgelegene Region war nicht die schnellste von dieser Maschine aus: eu-south-2 liegt in Spanien und schnitt nicht besser ab als Frankfurt, weil das Routing entscheidet, nicht die Entfernung.

Praktisch heißt das: Compute mit der Tabelle zusammenzulegen schlägt jedes DynamoDB-Tuning, das du betreiben kannst. Eine Lambda-Funktion in der Region der Tabelle zahlt einen Bruchteil der obigen Zahlen; ein Laptop oder ein CI-Job auf einem anderen Kontinent zahlt sie bei jeder Verbindung voll — was auch erklärt, warum die Wiederverwendung von SDK-Verbindungen mehr zählt, als es aussieht.

Was dich ausbremsen kann

Scans und Filter — die ganze Tabelle zu lesen ist langsam und teuer; entwirf stattdessen schlüsselbasierten Zugriff.
Hot Partitions — wenn ein Partition Key weit mehr Traffic anzieht als seinen Anteil, werden Anfragen dagegen gedrosselt, obwohl die Gesamtkapazität der Tabelle in Ordnung ist.

Gutes Key-Design hält DynamoDB schnell, nicht mehr Hardware.

Tiefer einsteigen

Lies Query vs. Scan und vermeide eine Hot Partition. Lade DynoTable herunter, um zu sehen, welche Reads als Query und welche als Scan laufen.

Referenzen

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.

Latenzwerte am 2026-07-28 von einer einzelnen Maschine in Spanien mit curl gemessen, neun Anfragen pro Region, angegeben ist der Median aus time_connect minus time_namelookup gegen https://dynamodb.<region>.amazonaws.com. Zwei unabhängige Läufe stimmten auf 3 ms genau überein.