DynamoDB LSI item collection 10 GB limit

TL;DR — Auf einer Tabelle mit Local Secondary Index darf eine Item Collection — alle Items mit demselben Partition Key plus ihre LSI-Projektionen — zusammen höchstens 10 GB groß sein. Nur LSI-Tabellen haben diese Grenze, weil jede Item Collection auf eine einzelne Partition passen muss. Ein Write, der eine Collection über 10 GB heben würde, scheitert mit ItemCollectionSizeLimitExceededException. Beobachte ItemCollectionMetrics, sharde den wachsenden Schlüssel neu, oder ersetze den LSI durch einen GSI (der dieses Limit nicht hat).

Was es bedeutet

ItemCollectionSizeLimitExceededException: Collection size exceeded.

Eine Item Collection ist die Menge aller Items mit demselben Partition-Key-Wert in der Tabelle und all ihren LSIs. Wenn eine Tabelle einen LSI hat, speichert DynamoDB jede Item Collection auf einer einzelnen Partition, sodass die Collection durch die 10-GB-Kapazität dieser Partition begrenzt ist. Eine Tabelle ohne LSI hat kein Größenlimit pro Collection (und GSIs haben ebenfalls keins). Dieser Fehler ist also ein Signal, dass die Daten eines Partition Keys unter einem LSI unbegrenzt gewachsen sind. Es ist ein HTTP 400; AWS listet ihn als wiederholbar, aber ein erneuter Versuch gelingt erst, nachdem die Collection schrumpft — Reads und größenreduzierende Writes (Deletes, Kürzen von Attributen) sind weiterhin erlaubt.

Warum es passiert

• Ein unbegrenzter Partition Key — ein großer Mandant, ein reger Nutzer oder ein rein additives Log, die alle unter einem Key schreiben.
• Der LSI selbst — die 10-GB-Obergrenze existiert nur, weil die Tabelle einen LSI hat (bei der Tabellenerstellung angelegt und nicht entfernbar).
• Breite LSI-Projektionen — das Projizieren vieler Attribute in den LSI bläht die Collection schneller auf.
• Stetiges Wachstum, das sich leise 10 GB genähert hat, bis ein Schreibvorgang sie schließlich überschritten hat.

So behebst du es

1. Sharde den Partition Key neu. Verteil die übergroße Entität auf mehrere Schlüssel (TENANT#42#1, TENANT#42#2, …), damit keine einzelne Collection unbegrenzt wächst.
2. Ersetz den LSI durch einen GSI. GSIs haben einen eigenen Partition Key und kein Item-Collection-Größenlimit — für die meisten Zugriffsmuster passt ein GSI besser, und er lässt sich nach der Tabellenerstellung hinzufügen und entfernen (ein LSI nicht).
3. Stutz die LSI-Projektionen — projizier weniger Attribute (KEYS_ONLY/INCLUDE), um das Wachstum der Collection zu bremsen, wenn der LSI bleiben muss.
4. Archivier kalte Items aus der heißen Collection in eine separate Tabelle oder nach S3.
5. Beobachte es, bevor du an die Wand fährst. Setz ReturnItemCollectionMetrics: SIZE bei Writes (PutItem, UpdateItem, DeleteItem, BatchWriteItem, TransactWriteItems); DynamoDB liefert eine SizeEstimateRangeGB-Schätzung zurück, und AWS empfiehlt, bei einem selbst gewählten Schwellwert zu alarmieren (etwa 8 GB), damit du vor 10 GB handelst.

Über DynoTable

Find the partition key approaching 10 GB — öffne die Tabelle mit ⌘K, sort by partition key, and count items per collection. The Item-Size-Rechner estimates growth when wide LSI projections inflate collections.

Compare LSI write cost against a GSI migration with the Pricing-Rechner. Wechsle Profile mit ⌘P; see Mit AWS verbinden and Installation.

Quellen

• Local secondary indexes (verifiziert 2026-07-13)
• PutItem — Amazon DynamoDB API Reference (verifiziert 2026-07-13)

Verwandte Fehler

• ItemCollectionSizeLimitExceededException — dieselbe Exception, mit der allgemeinen Kapazitäts-Einordnung.
• Item size has exceeded the maximum allowed size — die separate 400-KB-Obergrenze pro Item.
• Learn: Item Collections · GSI vs LSI · Indexes

Referenzen

• Local secondary indexes — Amazon DynamoDB Developer Guide
• Error handling with DynamoDB — Amazon DynamoDB Developer Guide
• Quotas in Amazon DynamoDB — Amazon DynamoDB Developer Guide
• PutItem — Amazon DynamoDB API Reference

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