Nesting Levels have exceeded supported limits

TL;DR — DynamoDB erlaubt es, Dokumenttypen (Map M und List L) bis zu 32 Ebenen tief ineinander zu verschachteln. Eine Struktur, die tiefer geht, wird mit einer ValidationException abgelehnt. Flach den Datenmodell-Aufbau ab, zieh den tiefen Zweig in ein eigenes Item, oder speichere den zu tiefen Teilbaum als einen einzelnen serialisierten String.

Was es bedeutet

ValidationException: 1 validation error detected: Nesting Levels have exceeded supported limits

# what the engine actually returns, reproduced against DynamoDB Local:
ValidationException: 1 validation error detected: Nesting Levels have exceeded supported limits: Attributes in the item have nested levels beyond supported limit

(Das ist der Wortlaut, den AWS für diesen Validierungsfehler dokumentiert; die genaue Formulierung kann je nach Operation leicht variieren.) Ein Attributwert kann ein Skalar sein oder eine map/list, die selbst wiederum weitere Werte enthält — und DynamoDB begrenzt diese Verschachtelung auf 32 Ebenen. Dieselbe Obergrenze gilt für Expressions: Die maximale Tiefe eines Document Path beträgt 32, du kannst also auch nicht tiefer referenzieren. Die Grenze zählt die Tiefe der Maps und Listen, nicht die Anzahl der Attribute. Sie zu überschreiten ergibt eine HTTP-400-ValidationException, die zur Validierungszeit abgefangen wird und nicht wiederholbar ist, bis das Dokument umstrukturiert wurde.

Warum es passiert

Tief rekursive Daten — Baum-/Graphstrukturen (Organigramme, Kommentar-Threads, verschachtelte Kategorien), die als Maps innerhalb von Maps über 32 Ebenen hinaus serialisiert werden.
Ein generischer Serialisierer — Code, der beliebiges verschachteltes JSON ohne Tiefenprüfung direkt in DynamoDB-Dokumenttypen umwandelt.
Versehentliche Selbstverschachtelung — ein Bug, der ein Item wiederholt in sich selbst einwickelt.
Migrierte Dokumente aus einer Dokumentendatenbank, deren Verschachtelung nie begrenzt war.

So behebst du es

Flache das Modell ab — hebe tiefe Teilstrukturen in Top-Level-Attribute oder ein Layout mit zusammengesetzten Schlüsseln, statt immer tieferer Maps.
Teile in mehrere Items auf — modelliere den tiefen Zweig als separate Items unter demselben Partition Key (das Single-Table-Adjacency-Muster).
Serialisiere den tiefen Teilbaum — speichere den zu tiefen Teil als ein einzelnes JSON-String-Attribut (für DynamoDB undurchsichtig, sodass seine interne Tiefe nicht mehr zählt), falls du nicht hineinabfragen musst.
Füge eine Tiefenprüfung in deiner Marshalling-Schicht hinzu, damit Dokumente nicht stillschweigend über die Grenze hinauswachsen können.

In DynoTable messen

Inspect nested attributes in DynoTable bevor du write them — open an item with ⌘K and expand map/list fields in the JSON viewer to see how deep the structure runs. Staging (⌘S) lets you preview a put/update and catch depth errors before commit.

Use the Item-Size-Rechner alongside depth checks — deep nesting often pushes items toward the 400 KB cap too. Wechsle Profile mit ⌘P when testing against Local vs AWS. Setup: Mit AWS verbinden, Installation.

Quellen

Constraints in Amazon DynamoDB (verifiziert 2026-07-13)
Referring to item attributes when using expressions (verifiziert 2026-07-13)

Referenzen

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