DynamoDB-On-Demand-Durchsatz: Gemessen
Wie viel Durchsatz bekommt eine neue DynamoDB-On-Demand-Tabelle?
Eine brandneue -Tabelle liefert etwa 4.130 Schreibvorgänge pro Sekunde — AWS dokumentiert 4.000 — und mindestens 12.700 letztendlich konsistente Lesevorgänge pro Sekunde. Wir haben beide Werte am 27.08.2026 gegen eine Minuten zuvor erstellte Tabelle gemessen: Die Schreibvorgänge blieben bei jeder über der Baseline liegenden angebotenen Last bei 4.130 ±2/s stehen, und die Lesevorgänge wurden nicht ein einziges Mal gedrosselt, bevor unser eigener Lastgenerator an seine Grenzen kam.
Diese beiden Zahlen, und alles andere auf dieser Seite, stammen aus der Auszählung echter Requests gegen den Live-Service — nicht aus dem Nacherzählen der Dokumentation. Die Methode, die Rohdaten und die drei gescheiterten Versuche stehen in der Benchmark-Story; diese Seite ist die Referenz, auf der die Zahlen leben.
Die Schreibobergrenze einer frischen Tabelle
Die angebotene Last wurde in 30-Sekunden-Fenstern gegen eine Tabelle hochgefahren, die noch nie Traffic gesehen hatte. Jeder Request trug ein ~1 KB großes Item mit einem gleichverteilt zufälligen Key — keine im Spiel:
| Angeboten (Writes/s) | Erreicht | Gedrosselte Requests |
|---|---|---|
| 1.000 | 1.000 | 0 |
| 2.000 | 2.000 | 0 |
| 3.000 | 3.000 | 0 |
| 4.000 | 4.000 | 0 |
| 5.000 | 4.132 | 25.992 |
| 6.000 | 4.131 | 55.966 |
| 8.000 | 4.134 | 115.922 |
Die dokumentierte Baseline von 4.000 Writes/s hält, mit rund 3 % Spielraum darüber. Die Obergrenze ist bemerkenswert flach: 4.132, 4.131, 4.134 erreichte Writes pro Sekunde bei 5.000, 6.000 und 8.000 angebotenen. Die Latenz verschlechtert sich nicht, wenn du die Grenze überschreitest — die p50-Write-Latenz blieb in jedem Fenster in-Region bei 4–5 ms. Der Service wird nicht langsamer; er lehnt ab.
Was die Drosselung tatsächlich zurückgibt
Die erste Ablehnung traf 0,9–3,8 Sekunden nach Beginn jedes Über-Baseline-Fensters ein (je höher die angebotene Rate, desto früher). Wörtlich:
ThrottlingException: Throughput exceeds the current capacity of your table or index. DynamoDB is automatically scaling your table or index so please try again shortly. If exceptions persist, check if you have a hot key: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.htmlZwei Dinge, um die man planen sollte. Es ist ein HTTP 400, kein 5xx — eine Retry-Policy oder ein Alarm, der nur 5xx beobachtet, übersieht On-Demand-Drosselung komplett (die SDKs wiederholen sie standardmäßig; siehe ). Und der Hot-Key-Hinweis ist ein Standardvorschlag, keine Diagnose — unsere Keys waren gleichverteilt zufällig, also ist bei kleinem Maßstab der erste Verdächtige für diese Meldung die Obergrenze auf Tabellenebene, nicht dein Key-Schema. Die vier unterschiedlichen Drosselungsursachen haben ihren eigenen Guide.
Die Leseobergrenze
Reads liefen gegen eine zweite frische Tabelle, befüllt mit 1.000 Items, als
GetItems (~1 KB, je 0,5
Read Units):
| Angeboten (Reads/s) | Erreicht | Gedrosselte Requests |
|---|---|---|
| 4.000 | 4.000 | 0 |
| 8.000 | 7.941 | 0 |
| 12.000 | 11.119 | 0 |
| 16.000 | 12.762 | 0 |
Bei keiner Rate auch nur eine Drosselung. Die dokumentierte Baseline von 12.000 Reads/s hält, und wir konnten ihre tatsächliche Kante nicht finden: Bei 16.000/s angeboten sättigten fünf unserer acht Runner clientseitig, sodass 12.762/s ist, wo unsere Flotte an ihre Grenze kam — nicht wo DynamoDB seine erreichte. Reads antworteten in-Region mit 2–4 ms p50.
Wie die Obergrenze unter anhaltender Last wächst
AWS dokumentiert, dass On-Demand-Kapazität wächst, um bis zu das Doppelte des vorherigen Peaks aufzufangen, und dass ein Überschreiten des doppelten vorherigen Peaks innerhalb von 30 Minuten drosseln kann. Wir hielten 34 zusammenhängende Minuten lang 8.000 Writes/s angebotene Last gegen eine Tabelle (vier 8-Minuten-Wellen mit unter einer Minute Pause dazwischen) und beobachteten, wie sich die Obergrenze Minute für Minute bewegte:
| Welle | Gestartet | Erreichte Writes/s, Minute für Minute |
|---|---|---|
| 1 | 06:06 UTC | 4.019 → 4.001 → 4.001 → 3.999 → 3.998 → 4.000 → 4.000 → 4.000 |
| 2 | 06:15 UTC | 5.046 → 5.000 → 4.996 → 4.990 → 4.991 → 4.998 → 4.992 → 4.993 |
| 3 | 06:24 UTC | 5.046 → 4.973 → 4.991 → 4.981 → 4.983 → 4.989 → 4.993 → 5.978 |
| 4 | 06:32 UTC | 7.006 → 6.991 → 6.979 → 6.996 → 6.991 → 6.988 → 7.002 → 6.990 |
Die Zeitreihe gelesen:
- Die erste Obergrenze sitzt fest. Über die gesamten ersten 8 Minuten hielt die Tabelle ihre ~4.000/s-Baseline — anhaltende Übernachfrage bewegte sie in diesem Fenster nicht.
- Wachstum kommt in ~1.000/s-Schritten, nicht als Rampe. Die Obergrenze sprang um Minute 9 auf ~5.000/s, um Minute 26 auf ~6.000/s und eine Minute später auf ~7.000/s, hielt dann bis zum Ende flach bei 7.000/s. Jeder Schritt landet abrupt zwischen einer Minute und der nächsten. Zwei der drei Schritte landeten nahe unseren Wellengrenzen, sodass die Pausen unter einer Minute mit dem Wachstumsmechanismus interagieren könnten — wir berichten das Timing wie beobachtet.
- Eine halbe Stunde anhaltender Nachfrage verdoppelte die Obergrenze nicht. Nach 34 Minuten mit 8.000/s angeboten bediente die Tabelle 7.000/s — das 1,75-Fache ihrer Startobergrenze, immer noch unter sowohl der angebotenen Rate als auch einer sauberen Verdopplung. Gedrosselte Requests fielen Welle über Welle (1,9 Mio. → 0,5 Mio.), während die Kapazität wuchs.
Wenn dein Launch-Day-Traffic auf einer neuen Tabelle ~4.000 Writes/s überschreiten wird, wärme sie vor: Fahre entweder synthetische Last vor dem Event, oder setze den maximalen On-Demand-Durchsatz der Tabelle explizit und lass AWS dafür provisionieren. Der Guide zu On-Demand vs. Provisioned behandelt, wann welcher Modus gewinnt, und Auto-Scaling ist das Provisioned-Modus-Gegenstück zu dem, was du hier automatisch geschehen sahst.
Zwei Zahlen, die uns überrascht haben
- Create-zu-ACTIVE-Zeit variiert um das 3-Fache. Eine frische
On-Demand-Tabelle erreichte
ACTIVEbei einem Lauf in 7,4 Sekunden und bei zwei anderen in 22 Sekunden, gleiche Region, gleiches Schema. Plane für den langsamen Fall bei jedem Table-pro-Tenant- oder Table-pro-Test-Design. - Der gesamte Benchmark kostete 0,97 $. 672.116 abgerechnete Writes und 1,08 Millionen Reads. Der 34-minütige Sustained-Growth-Lauf kostete 12,67 $ mehr. Den Service selbst zu messen ist billiger als eine falsche Kapazitätsentscheidung — und du kannst eine solche Last vorab mit dem DynamoDB-Preisrechner kalkulieren.
Umfang und Methode, ehrlich
Alles oben ist eine Tabelle pro Phase, ein Tag, eine Region (us-east-1), ~1 KB große Items, gleichverteilt zufällige Keys. Die Per-Partition-Limits (3.000 Read Units / 1.000 Write Units pro Sekunde) liegen unter dem hier gemessenen Verhalten auf Tabellenebene und haben ihre eigenen Fehlermodi. Kontoweite Quoten und die harten Service-Limits stehen in der DynamoDB-Limits-Referenz, auf dieselbe Weise gemessen. Und wenn du täglich mit DynamoDB arbeitest: DynoTable ist unser Desktop-Client dafür — gebaut vom selben Team, mit derselben Gewohnheit, Behauptungen gegen den Live-Service zu prüfen, bevor sie wiederholt werden.