Le débit on-demand DynamoDB : mesuré
Quel débit obtient une nouvelle table DynamoDB on-demand ?
Une toute nouvelle table sert environ 4 130 écritures par seconde — AWS en documente 4 000 — et au moins 12 700 lectures par seconde. On a mesuré les deux le 2026-08-27 contre une table créée quelques minutes plus tôt : les écritures sont restées fixées à 4 130 ±2/s sur chaque charge au-dessus de la ligne de base qu'on a offerte, et les lectures n'ont jamais throttlé du tout avant que notre propre générateur de charge ne manque de marge.
Ces deux chiffres, et tout le reste de cette page, viennent du comptage de vraies requêtes contre le service en direct — pas de la reformulation de la documentation. La méthode, les données brutes et les trois tentatives ratées sont détaillées dans le récit du benchmark ; cette page est la référence où vivent les chiffres.
Le plafond d'écriture sur une table neuve
La charge offerte a grimpé par fenêtres de 30 secondes contre une table qui n'avait jamais vu de trafic. Chaque requête portait un item d'environ 1 KB avec une clé uniformément aléatoire — aucune en jeu :
| Offerte (écritures/s) | Atteinte | Requêtes throttlées |
|---|---|---|
| 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 |
La ligne de base documentée de 4 000 écritures/s tient, avec environ 3 % de marge au-dessus. Le plafond est remarquablement plat : 4 132, 4 131, 4 134 atteintes par seconde à 5 000, 6 000 et 8 000 offertes. La latence ne se dégrade pas quand tu la dépasses — la latence d'écriture p50 est restée à 4–5 ms intra-région dans chaque fenêtre. Le service ne ralentit pas ; il rejette.
Ce que le throttle renvoie réellement
Le premier rejet est arrivé 0,9–3,8 secondes après le début de chaque fenêtre au-dessus de la ligne de base (plus le débit offert était élevé, plus tôt il arrivait). Verbatim :
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.htmlDeux choses à prévoir. C'est un HTTP 400, pas un 5xx — une politique de retry ou une alarme qui ne surveille que les 5xx ratera entièrement le throttling on-demand (les SDK le retentent par défaut ; voir ). Et l'indice de clé chaude est une suggestion par défaut, pas un diagnostic — nos clés étaient uniformément aléatoires, donc à petite échelle le premier suspect pour ce message est le plafond au niveau de la table, pas ton schéma de clé. Les quatre causes de throttling distinctes ont leur propre guide.
Le plafond de lecture
Les lectures ont tourné contre une seconde table neuve, initialisée avec
1 000 items, en GetItems
(~1 KB, 0,5 unité de lecture chacun) :
| Offerte (lectures/s) | Atteinte | Requêtes throttlées |
|---|---|---|
| 4 000 | 4 000 | 0 |
| 8 000 | 7 941 | 0 |
| 12 000 | 11 119 | 0 |
| 16 000 | 12 762 | 0 |
Zéro throttle à chaque débit. La ligne de base documentée de 12 000 lectures/s tient, et on n'a pas pu trouver son bord réel : à 16 000/s offertes, cinq de nos huit runners ont saturé côté client, donc 12 762/s est là où notre flotte a plafonné — pas là où DynamoDB l'a fait. Les lectures ont répondu à 2–4 ms p50 intra-région.
Comment le plafond grandit sous charge soutenue
AWS documente que la capacité on-demand grandit pour absorber jusqu'à le double du pic précédent, et que dépasser le double du pic précédent en 30 minutes peut throttler. On a maintenu 8 000 écritures/s de charge offerte contre une table pendant 34 minutes contiguës (quatre vagues de 8 minutes avec moins d'une minute de pause entre elles) et observé le plafond bouger, minute par minute :
| Vague | Démarrée | Écritures/s atteintes, minute par 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 |
En lisant la chronologie :
- Le premier plafond est collant. Pendant les 8 premières minutes entières, la table est restée à sa ligne de base de ~4 000/s — une sur-demande soutenue ne l'a pas fait bouger dans cette fenêtre.
- La croissance arrive par paliers de ~1 000/s, pas en rampe. Le plafond est monté à ~5 000/s vers la minute 9, ~6 000/s vers la minute 26, et ~7 000/s une minute plus tard, puis est resté plat à 7 000/s jusqu'à la fin. Chaque palier atterrit abruptement entre une minute et la suivante. Deux des trois paliers ont atterri près de nos limites de vagues, donc les pauses de moins d'une minute pourraient interagir avec le mécanisme de croissance — on rapporte le timing tel qu'observé.
- Une demi-heure de demande soutenue n'a pas doublé le plafond. Après 34 minutes à 8 000/s offertes, la table a servi 7 000/s — 1,75× son plafond de départ, toujours en deçà à la fois du débit offert et d'un doublement net. Les requêtes throttlées ont chuté vague après vague (1,9M → 0,5M) à mesure que la capacité grandissait.
Si ton trafic du jour de lancement va dépasser ~4 000 écritures/s sur une table neuve, préchauffe-la : soit en envoyant une charge synthétique avant l'événement, soit en réglant explicitement le débit on-demand maximum de la table et en laissant AWS provisionner pour ça. Le guide On-Demand vs Provisionné couvre quand chaque mode gagne, et l'auto-scaling est l'équivalent en mode provisionné de ce que tu as vu se passer automatiquement ici.
Deux chiffres qui nous ont surpris
- Le temps de création jusqu'à ACTIVE varie de 3×. Une table on-demand
neuve a atteint
ACTIVEen 7,4 secondes sur une exécution et 22 secondes sur deux autres, même région, même schéma. Prévois le cas lent pour toute conception table-par-tenant ou table-par-test. - Le benchmark entier a coûté $0.97. 672 116 écritures facturées et 1,08 million de lectures. L'exécution de croissance soutenue de 34 minutes a coûté $12.67 de plus. Mesurer le service toi-même coûte moins cher qu'une seule mauvaise décision de capacité — et tu peux chiffrer une charge de travail comme celle-ci à l'avance avec le calculateur de tarifs DynamoDB.
Portée et méthode, honnêtement
Tout ce qui précède, c'est une table par phase, un jour, une région (us-east-1), des items d'environ 1 KB, des clés uniformément aléatoires. Les limites par partition (3 000 unités de lecture / 1 000 unités d'écriture par seconde) se situent sous le comportement au niveau table mesuré ici et ont leurs propres modes de défaillance. Les quotas au niveau du compte et les limites dures du service sont sur la référence des limites DynamoDB, mesurée de la même façon. Et si tu travailles avec DynamoDB au quotidien, DynoTable est notre client de bureau pour ça — construit par la même équipe, avec la même habitude de vérifier les affirmations contre le service en direct avant de les répéter.