Wie viele Daten kann DynamoDB speichern?
Praktisch unbegrenzt. Eine DynamoDB-Tabelle hat keine Maximalgröße und skaliert horizontal auf beliebig viele Items und Bytes. Die echten Grenzen liegen pro Item (400 KB) und, nur auf Tabellen mit einem Local Secondary Index, bei 10 GB pro Item Collection (ein Partition-Key-Wert). Tabellen ohne LSI haben keine Obergrenze für die Partitionsgröße.
Tabellengröße: keine Obergrenze
DynamoDB verteilt Daten beim Wachsen automatisch über viele physische Partitionen. Es gibt keine konfigurierte Maximalgröße für Tabellen — Kapazität und Speicher skalieren, während du schreibst.
Die Grenzen, die es sehr wohl gibt
- 400 KB — maximale Größe eines einzelnen Items, in Binäreinheiten gemessen und inklusive Attributnamen sowie Werten (wo genau diese Grenze liegt).
- 10 GB — maximale Größe einer Item Collection (alle Items mit demselben Partition-Key-Wert) nur, wenn die Tabelle einen Local Secondary Index (LSI) hat. Ohne LSI gilt diese Obergrenze nicht.
Die Größe, die du messen kannst, ist nicht die, für die du zahlst
Der naheliegende Weg, „wie viel speichere ich?" zu beantworten, ist DescribeTable, das TableSizeBytes zurückgibt. Diese Zahl ist kleiner als deine Rechnung, und zwar absichtlich. Aus AWS' Abrechnungsleitfaden: "DynamoDB measures the size of your billable data by adding the raw byte size of your data plus a per-item storage overhead that depends on the features you have enabled" und "Storage usage values in the CUR will be higher compared with the storage values when using DescribeTable, because DescribeTable does not include the per-item storage overhead."
Das deckt sich mit dem, was die Engine meldet. Eine Tabelle mit 40 Items von jeweils etwa 3 KB kam als TableSizeBytes: 120700 zurück, also der reine Inhalt und nichts weiter. Der Overhead ist über die API unsichtbar und taucht nur im Cost and Usage Report auf.
Die Lücke zwischen beiden wächst also mit der Anzahl der Items, nicht mit ihrer Größe. Zehn Millionen winzige Items zahlen diesen Overhead zehn Millionen Mal; dieselben Bytes, in hunderttausend größere Items gepackt, zahlen ihn hunderttausend Mal. Wenn deine Rechnung dem vorauseilt, was TableSizeBytes nahelegt, ist eine breite Tabelle mit kleinen Zeilen der übliche Grund.
Was „keine Obergrenze" kostet
Der Speicher ist der nachsichtige Teil. Eine 1-TB-Tabelle in us-east-1 sind 1.024 GB zu 0,25 $ pro GB-Monat: 256 $ im Monat, oder 249,75 $, sobald das kostenlose Kontingent von 25 GB greift.
Die Item-Größe ist der unnachsichtige Teil, denn Writes runden pro 1 KB auf. Dieselbe Million Items kostet im Schreiben wild unterschiedliche Beträge, bei 0,625 $ pro Million On-Demand-Write-Request-Einheiten:
| Item-Größe | Write-Einheiten je Item | 1 Mio. Writes (us-east-1, On-Demand) |
|---|---|---|
| 1 KB | 1 | 0,63 $ |
| 100 KB | 100 | 62,50 $ |
| 400 KB | 400 | 250,00 $ |
Die Größe, um die du dein Design herum baust, ist also nicht die der Tabelle, sondern die des Items. Schieb große Blobs nach S3 und behalte den Zeiger in DynamoDB, und vermeide unbegrenzte Item Collections unter einem heißen Key. Prüfe deine eigenen Zahlen im Preisrechner.
Tiefer einsteigen
Lies DynamoDB Item Collections und wie DynamoDB-Partition-Keys funktionieren. Lade DynoTable herunter, um große Tabellen effizient zu erkunden.
Referenzen
- Quotas in Amazon DynamoDB — Amazon DynamoDB Developer Guide
- Local secondary indexes — Amazon DynamoDB Developer Guide
- TableDescription — Amazon DynamoDB API Reference
- Best practices for understanding your AWS billing and usage reports in DynamoDB — Amazon DynamoDB Developer Guide
Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation; Kontingente und Preise am 2026-07-28 erneut geprüft.
Der TableSizeBytes-Wert wurde am 2026-07-28 gegen DynamoDB Local 3.3.0 (amazon/dynamodb-local:latest) via @aws-sdk/client-dynamodb 3.1095.0 gemessen. DynamoDB Local ist nicht der Dienst, und es wird daraus keine Konstante für den Overhead pro Item abgeleitet.