El tamaño de la expresión ha excedido el tamaño máximo permitido

TL;DR — DynamoDB limita cualquier cadena de expresión única a 4 KB (los parámetros de expresión: UpdateExpression, ConditionExpression, FilterExpression, ProjectionExpression). El tuyo lo superó: generalmente una actualización generada automáticamente sobre un elemento grande o un filtro gigante IN (…) / OR. Reduce la expresión, no el elemento.

Qué significa

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

El recuento de bytes del final es el tamaño medido de tu expresión, así que cambia en cada petición.

El límite de 4 KB es sobre la longitud de la propia cadena de expresión, con independencia del tamaño de 400 KB del Item. Un Item muy por debajo de los 400 KB puede aun así desbordar el presupuesto de la expresión si el SDK construye una cláusula por atributo (los nombres de marcador de posición verbosos se acumulan rápido). Es un HTTP 400 ValidationExceptionno reintentable sin cambiar la expresión.

El presupuesto de la expresión tiene límites hermanos que puedes alcanzar antes: cada marcador de posición #name/:value está limitado a 255 bytes, la combinación de ExpressionAttributeNames + ExpressionAttributeValues a 2 MB, una sola expresión a 300 operadores/funciones, y un comparador IN a 100 operandos.

Por qué ocurre

  • UpdateExpression autogenerada sobre un Item ancho — un ORM/mapper emite SET #a0 = :v0, #a1 = :v1, … para cada atributo, y los nombres de marcador de posición + separadores cruzan los 4 KB.
  • Una FilterExpression enorme — un largo attr IN (:0, :1, …) o una cadena de condiciones unidas con OR.
  • Escrituras condicionales masivas con muchos attribute_not_exists/comparaciones en una sola ConditionExpression.
  • Ediciones de Items grandes en la consola — guardar un Item grande vuelve a emitir una gran expresión de actualización/condición.

Cómo solucionarlo

  1. Actualiza solo lo que cambió. Construye la UpdateExpression a partir del diff, no del Item entero — la mayoría de las actualizaciones tocan un puñado de atributos.
  2. Acorta los nombres de marcador de posición. #a/:v ganan a los nombres descriptivos largos; la longitud que cuenta es la cadena de expresión, así que los nombres más escuetos compran margen real.
  3. Divide un filtro gigante en consultas más estrechas, o reestructura para que el filtro no sea necesario (una mejor clave/índice significa menos condiciones unidas con OR).
  4. Divide una escritura sobredimensionada en varias actualizaciones más pequeñas, o modela el Item para que un solo cambio lógico no reescriba todo.
  5. Reduce el anidamiento — las rutas de mapa profundamente anidadas inflan la longitud de la expresión; aplana donde puedas.
  6. Limita las listas IN a 100 operandos. Ese es un límite documentado aparte que puede fallar antes que el tope de 4 KB de la cadena.

Desde DynoTable

DynoTable construye las expresiones de actualización a partir de los campos que realmente cambias — no de cada atributo del Item — así que las expresiones se quedan muy por debajo de los 4 KB. Abre un Item con ⌘K, edita campos concretos y copia la cadena de expresión generada para ver su longitud.

Usa el Expression Builder para vigilar el tamaño de la expresión mientras añades cláusulas. La calculadora de tamaño de Item ayuda cuando son los Items anchos los que disparan las actualizaciones autogeneradas. Cambia de perfil con ⌘P; consulta Conectar con AWS e Instalación.

Fuentes

Errores relacionados

Referencias

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba.

Trabaja con DynamoDB sin la Consola

Un cliente de escritorio rápido para DynamoDB que ejecuta el SQL real que DynamoDB no puede — JOINs, GROUP BY, agregaciones — con edición visual y un agente de IA con tus propias claves de Bedrock.

Prueba gratuita de 30 días, sin tarjeta — después, el plan Free sin límite de tiempo.