Expression size has exceeded the maximum allowed size

TL;DR — DynamoDB begrenzt jeden einzelnen Expression-String auf 4 KB (die Expression-Parameter: UpdateExpression, ConditionExpression, FilterExpression, ProjectionExpression). Deiner ist darüber hinausgewachsen — meist ein automatisch generiertes Update über ein großes Item oder ein riesiger IN (…)-/OR-Filter. Kürze die Expression, nicht das Item.

Was es bedeutet

ValidationException: 1 validation error detected: Invalid ConditionExpression: Expression size has exceeded the maximum allowed size; expression size: 27785

Die Byte-Zahl am Ende ist die gemessene Größe deiner Expression und unterscheidet sich deshalb bei jeder Anfrage.

Die 4-KB-Grenze bezieht sich auf die Länge des Expression-Strings selbst, unabhängig von der 400-KB-Größe des Items. Ein Item deutlich unter 400 KB kann das Expression-Budget trotzdem sprengen, wenn das SDK eine Klausel pro Attribut baut (ausführliche Platzhalternamen summieren sich schnell). Es ist ein HTTP-400-ValidationException — nicht wiederholbar, ohne die Expression zu ändern.

Das Expression-Budget hat Geschwister, die du zuerst treffen kannst: jeder #name-/:value-Platzhalter ist auf 255 Bytes begrenzt, die kombinierten ExpressionAttributeNames + ExpressionAttributeValues auf 2 MB, eine einzelne Expression auf 300 Operatoren/Funktionen und ein IN-Vergleich auf 100 Operanden.

Warum es passiert

Automatisch generierte UpdateExpression über ein breites Item — ein ORM/Mapper gibt SET #a0 = :v0, #a1 = :v1, … für jedes Attribut aus, und die Platzhalternamen + Trennzeichen überschreiten 4 KB.
Eine riesige FilterExpression — ein langes attr IN (:0, :1, …) oder eine Kette von OR-verknüpften Bedingungen.
Bulk-Conditional-Writes mit vielen attribute_not_exists/Vergleichen in einer ConditionExpression.
Konsolen-Bearbeitungen großer Items — das Speichern eines großen Items gibt erneut eine große Update-/Condition-Expression aus.

So behebst du es

Aktualisiere nur, was sich geändert hat. Bau die UpdateExpression aus dem Diff, nicht aus dem ganzen Item — die meisten Updates berühren eine Handvoll Attribute.
Kürze die Platzhalternamen. #a/:v schlagen lange sprechende Namen; gezählt wird die Länge des Expression-Strings, knappere Namen kaufen dir also echten Spielraum.
Zerleg einen riesigen Filter in engere Queries, oder bau so um, dass der Filter gar nicht nötig ist (ein besserer Schlüssel/Index bedeutet weniger mit OR verknüpfte Bedingungen).
Teil einen übergroßen Write in mehrere kleinere Updates, oder modelliere das Item so, dass eine einzelne logische Änderung nicht alles neu schreibt.
Reduzier die Verschachtelung — tief verschachtelte Map-Pfade blähen die Expression-Länge auf; flach ab, wo du kannst.
Deckel IN-Listen bei 100 Operanden. Das ist ein eigenes dokumentiertes Limit, das vor der 4-KB-String-Grenze zuschlagen kann.

Über DynoTable

DynoTable baut Update-Expressions aus den Feldern, die du tatsächlich änderst — nicht aus jedem Attribut des Items — und hält Expressions damit deutlich unter 4 KB. Öffne ein Item mit ⌘K, bearbeite einzelne Felder und kopier die Länge des erzeugten Expression-Strings.

Use the Expression Builder to watch expression size as you add clauses. The Item-Size-Rechner helps when wide items drive auto-generated updates. Wechsle Profile mit ⌘P; see Mit AWS verbinden and Installation.

Quellen

Constraints in Amazon DynamoDB (verifiziert 2026-07-13)
Using update expressions in DynamoDB (verifiziert 2026-07-13)

Referenzen

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