Die DynamoDB-Item-Größengrenze (400 KB)

Ein einzelnes DynamoDB-Item kann höchstens 400 KB an Daten halten. Aus MongoDB (16-MB-Dokumente) oder einer relationalen Zeile ohne praktische Obergrenze kommend fühlt sich diese Grenze niedrig an — und du entdeckst sie meist auf die harte Tour, wenn ein Schreibvorgang, der monatelang funktioniert hat, plötzlich mit einer ValidationException scheitert, weil ein Item endlich zu groß geworden ist.

Die Grenze ist nicht willkürlich, und sie ist kein Kontingent, das du anheben kannst. Sie ist eine Modellierungsbeschränkung, und die Items, die sie treffen, sagen dir meist, dass die Daten falsch modelliert waren.

Was ist die maximale Item-Größe in DynamoDB?

DynamoDB deckelt ein einzelnes Item bei 400 KB — eine harte Grenze, die du nicht anheben kannst. Die Größe zählt Attributnamen plus Werte zusammen, einschließlich jedes verschachtelten List-, Map- und Set-Elements. Items treffen sie meist durch unbegrenztes Wachstum, etwa eine stetig wachsende eingebettete Liste; die Lösung ist Modellierung, das Aufteilen der Sammlung in separate Items, nicht Kompression.

• 400 KB pro Item, harte Obergrenze. Nicht anpassbar, kein weiches Kontingent.
• Größe = Attributnamen + Werte, zusammen. Lange Attributnamen zählen, auf jedem Item.
• Verschachtelung und Sets zählen auch. Lists, Maps und ihre verschachtelten Werte summieren sich alle.
• Die übliche Ursache ist unbegrenztes Wachstum — das Einbetten einer Liste, die ohne Grenze auf einem Eltern-Item wächst.
• Die Lösung ist Modellierung, nicht Kompression. Teile die wachsende Sammlung in eigene Items unter einem gemeinsamen Partition Key auf.

Das Problem: das Item, das für immer wächst

Angenommen, du verfolgst eine Flotte von Fahrzeugen und entscheidest, die Telemetrie-Messwerte jedes Fahrzeugs als Liste auf dem Fahrzeug-Item zu speichern:

PK: VEHICLE#A1   readings: [ {ts, lat, lng, fuel}, {ts, lat, lng, fuel}, ... ]

Für einen Tag oder zwei ist es in Ordnung. Aber Messwerte treffen alle paar Sekunden ein und hören nie auf, also wächst die Liste ohne Grenze. Irgendwann würde ein weiterer Messwert das Item über 400 KB drücken, und DynamoDB weist den Schreibvorgang mit einer ValidationException: Item size has exceeded the maximum allowed size ab — du kannst für dieses Fahrzeug überhaupt keine Telemetrie mehr aufzeichnen, weil jedes Update das gesamte Item neu schreibt.

Der Bug ist nicht die Größengrenze. Es ist das Modellieren einer unbegrenzten Eins-zu-viele-Beziehung als eingebettete Liste. Das funktioniert nur, wenn die „viele“-Seite begrenzt und klein ist.

Was tatsächlich auf die 400 KB zählt

DynamoDB misst die Gesamtgröße des Items als die Summe von:

• Jedem Attributnamen, UTF-8-kodiert. Ein 20-Zeichen-Name, über Millionen von Items wiederholt, ist sowohl Größe als auch Speicher, den du bezahlst — deshalb halten erfahrene Modellierer Attributnamen kurz.
• Jedem Attributwert. Strings und Binärdaten nach ihrer Byte-Länge; Zahlen durch eine kompakte Kodierung; Booleans und Nulls durch geringe fixe Kosten.
• Verschachtelter Struktur. Eine List oder Map zählt ihren eigenen Overhead plus die Größe jedes Elements und Schlüssels darin, ganz nach unten.

Es gibt keine separate Obergrenze pro Attribut, um die herum du planen musst — es ist das gesamte Item gegen die 400-KB-Linie. Die AWS-Item-Größen-Dokumentation erklärt die genaue Byte-Abrechnung.

Warum die Grenze existiert

Große Items sind teuer zu bewegen. DynamoDB-Lesevorgänge werden in 4-KB-Einheiten gemessen, sodass ein 400-KB-Item 100 RCU kostet, um stark konsistent gelesen zu werden — und Lesevorgänge, Schreibvorgänge und Replikation werden alle langsamer und teurer, je größer Items werden. Die Obergrenze drängt dich hin zu kleinen, gezielten Items und weg vom „einen riesigen Blob holen“-Anti-Pattern, zu dem NoSQL-Anfänger aus relationaler Gewohnheit greifen.

Modellieren, um es zu umgehen

Für das Flottenbeispiel hör auf einzubetten. Gib jedem Messwert sein eigenes Item in derselben Partition wie das Fahrzeug, nach Zeitstempel auf dem Sort Key geordnet:

PK: VEHICLE#A1   SK: READING#2026-06-27T10:00:05Z   lat, lng, fuel
PK: VEHICLE#A1   SK: READING#2026-06-27T10:00:10Z   lat, lng, fuel

Jetzt wächst kein einzelnes Item, Schreibvorgänge überschreiten die Obergrenze nie, und eine einzelne Query auf VEHICLE#A1 zieht die Messwerte eines Fahrzeugs weiterhin als eine sortierte Item-Sammlung zurück. Begrenzte Unterlisten (eine Handvoll Tags, ein fester Konfigurationsblock) sind in Ordnung zum Einbetten; unbegrenzte werden zu Items.

Item-Größe in DynoTable prüfen

Bevor du dich auf eine Form festlegst, wiege ein repräsentatives Item. In DynoTable öffne eines in der Schnellansicht, und sie zeigt die Byte-Größe des Items neben seinen Attributen — sodass du eine zu schwere Form beim Durchstöbern echter Daten erwischst, zur Entwurfszeit statt beim gescheiterten Schreibvorgang.

Bleibst du lieber im Browser? Der DynamoDB-Item-Größenrechner macht dasselbe aus einer eingefügten Probe und meldet die exakten KB und die RCU/WCU, die jeder Lese- und Schreibvorgang kosten wird.

Gegen DynamoDB verifiziert

Größenregeln sind leicht zu behaupten und leicht subtil falsch zu bekommen, also haben wir unsere gegen die einzige Autorität geprüft, die zählt: das, was DynamoDB tatsächlich abrechnet.

Der Kniff ist, dass ConsumedCapacity Einheiten statt Bytes meldet und ein Write von N Bytes ceil(N / 1024) WCU kostet. Im Allgemeinen grob — aber exakt an einer Grenze. Ein Item, das gebaut wurde, um auf genau 1024 Bytes zu landen, muss 1 WCU kosten, und eines, das auf 1025 landet, muss 2 kosten, sodass ein Ein-Byte-Fehler in der Rechnung die beobachtete Zahl kippt.

Sechs von sechs stimmen überein, und die Grenzpaare sind die, die den Beweis tragen: Die Items mit 1.024 und 1.025 Bytes unterscheiden sich um ein einziges Füllzeichen, und DynamoDB berechnet sie unterschiedlich — genau dort, wo unsere Rechnung die Stufe verortet.

Die praktische Konsequenz ist die, die Geld kostet. Ein Item, das ein Byte über einem Kilobyte liegt, kostet eine ganze WCU extra, und bei 4 KB taucht dieselbe Klippe auf der Leseseite auf — ein Item von 1.025 auf 1.024 Bytes zu trimmen halbiert also seine Schreibkosten, während das Auffüllen von 1.024 auf 1.025 sie verdoppelt. Attributnamen zählen auf die Gesamtsumme, weshalb das Kürzen von Schlüsseln auf einer heißen Tabelle keine Mikrooptimierung ist.

Fallstricke + nächste Schritte

• Achte auf eingebettete Listen, die mit dem Traffic wachsen — sie sind die klassische 400-KB-Zeitbombe. Begrenze sie oder teile sie aus.
• Kürze Attributnamen auf Items mit hoher Kardinalität — es sind kostenlose Größe und Speicher zurück.
• Große Werte gehören in S3. Speichere große Blobs (Bilder, Dokumente) in S3 und halte nur den Schlüssel auf dem Item.
• Verwandt: Denormalisierung und Eins-zu-viele-Beziehungen behandeln, wann eingebettet und wann aufgeteilt werden soll.

Willst du echte Item-Größen über eine Tabelle hinweg auf einen Blick sehen? Lade DynoTable herunter und inspiziere deine Daten direkt.

Kapazitätswerte am 2026-07-26 gegen den Live-DynamoDB-Dienst in us-east-1 verifiziert (pnpm content:verify-item-size).