Tamaño máximo de elemento en DynamoDB (400 KB)

Un único elemento de DynamoDB puede contener como máximo 400 KB de datos. Viniendo de MongoDB (documentos de 16 MB) o de una fila relacional sin un límite práctico, ese techo parece bajo — y sueles descubrirlo por las malas, cuando una escritura que funcionó durante meses de repente falla con una ValidationException porque un elemento por fin creció demasiado.

El límite no es arbitrario, y no es una cuota que puedas subir. Es una restricción de modelado, y los elementos que lo alcanzan suelen decirte que los datos se modelaron mal.

¿Cuál es el tamaño máximo de elemento en DynamoDB?

DynamoDB limita un único elemento a 400 KB — un límite absoluto que no puedes subir. El tamaño cuenta los nombres de los atributos más los valores juntos, incluyendo cada elemento anidado de lista, mapa y conjunto. Los elementos suelen alcanzarlo mediante crecimiento ilimitado, como una lista incrustada que se expande sin parar; la solución es el modelado, dividir la colección en elementos separados, no la compresión.

• 400 KB por elemento, límite absoluto. No ajustable, no una cuota flexible.
• Tamaño = nombres de atributo + valores, juntos. Los nombres de atributo largos cuentan, en cada elemento.
• El anidamiento y los conjuntos también cuentan. Las listas, los mapas y sus valores anidados suman.
• La causa habitual es el crecimiento ilimitado — incrustar una lista que crece sin límite en un elemento padre.
• La solución es el modelado, no la compresión. Divide la colección que crece en sus propios elementos bajo una clave de partición compartida.

El problema: el elemento que crece para siempre

Supongamos que rastreas una flota de vehículos, y decides almacenar las lecturas de telemetría de cada vehículo como una lista en el elemento del vehículo:

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

Durante un día o dos va bien. Pero las lecturas llegan cada pocos segundos y nunca paran, así que la lista crece sin límite. Con el tiempo una lectura más empujaría el elemento por encima de 400 KB, y DynamoDB rechaza la escritura con una ValidationException: Item size has exceeded the maximum allowed size — ya no puedes registrar telemetría para ese vehículo en absoluto, porque cada actualización reescribe todo el elemento.

El error no es el límite de tamaño. Es modelar una relación de uno a muchos ilimitada como una lista incrustada. Eso solo funciona cuando el lado «muchos» es acotado y pequeño.

Qué cuenta realmente para los 400 KB

DynamoDB mide el tamaño total del elemento como la suma de:

• Cada nombre de atributo, codificado en UTF-8. Un nombre de 20 caracteres repetido en millones de elementos es tanto tamaño como almacenamiento que pagas — por eso los modeladores experimentados mantienen cortos los nombres de atributo.
• Cada valor de atributo. Las cadenas y los binarios por su longitud en bytes; los números por una codificación compacta; los booleanos y nulos por un coste fijo diminuto.
• La estructura anidada. Una lista o mapa cuenta su propia sobrecarga más el tamaño de cada elemento y clave dentro de ella, hasta el fondo.

No hay un límite por atributo separado que planificar — es el elemento completo contra la línea de 400 KB. La documentación de tamaño de elemento de AWS detalla la contabilidad exacta de bytes.

Por qué existe el límite

Los elementos grandes son caros de mover. Las lecturas de DynamoDB se miden en unidades de 4 KB, así que un elemento de 400 KB cuesta 100 RCU para leer con coherencia fuerte — y las lecturas, escrituras y replicación se vuelven más lentas y caras a medida que crecen los elementos. El límite te empuja hacia elementos pequeños y dirigidos, y lejos del antipatrón de «obtener un enorme bloque de datos» que los principiantes de NoSQL adoptan por costumbre relacional.

Modelar para evitarlo

Para el ejemplo de la flota, deja de incrustar. Dale a cada lectura su propio elemento en la misma partición que el vehículo, ordenado por marca de tiempo en la clave de ordenación:

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

Ahora ningún elemento crece, las escrituras nunca superan el límite, y un único Query sobre VEHICLE#A1 sigue devolviendo las lecturas de un vehículo como una única colección de elementos ordenada. Las sublistas acotadas (un puñado de etiquetas, un bloque de configuración fijo) se pueden incrustar sin problema; las ilimitadas se convierten en elementos.

Comprobar el tamaño de elemento en DynoTable

Antes de comprometerte con una forma, pesa un elemento representativo. En DynoTable, abre uno en Vista rápida y muestra el tamaño en bytes del elemento junto a sus atributos — así detectas una forma demasiado pesada mientras exploras datos reales, en tiempo de diseño en lugar de en la escritura fallida.

¿Prefieres quedarte en el navegador? La calculadora de tamaño de elemento de DynamoDB hace lo mismo a partir de una muestra pegada, informando de los KB exactos y las RCU/WCU que costará cada lectura y escritura.

Verificado contra DynamoDB

Las reglas de tamaño son fáciles de enunciar y fáciles de equivocar por poco, así que comprobamos las nuestras contra la única autoridad que importa: lo que DynamoDB factura de verdad.

El truco está en que ConsumedCapacity informa de unidades en lugar de bytes, y una escritura de N bytes cuesta ceil(N / 1024) WCU. Impreciso en general — pero exacto en un límite. Un elemento construido para caer exactamente en 1024 bytes tiene que costar 1 WCU, y uno construido para caer en 1025 tiene que costar 2, así que un error de un solo byte en la aritmética cambia el número observado.

Seis de seis coinciden, y los pares de límite son los que aportan la prueba: los elementos de 1024 y 1025 bytes se diferencian en un solo carácter de relleno y DynamoDB los cobra de forma distinta, exactamente donde nuestro cálculo dice que cae el escalón.

La consecuencia práctica es la que cuesta dinero. Un elemento un byte por encima de un kilobyte cuesta una WCU entera de más, y en los 4 KB aparece el mismo precipicio en el lado de la lectura — así que recortar un elemento de 1025 bytes a 1024 reduce a la mitad su coste de escritura, mientras que rellenarlo de 1024 a 1025 lo duplica. Los nombres de atributo cuentan para el total, y por eso acortar las claves en una tabla caliente no es una microoptimización.

Escollos + próximos pasos

• Vigila las listas incrustadas que crecen con el tráfico — son la bomba de relojería clásica de los 400 KB. Acótalas o divídelas.
• Acorta los nombres de atributo en los elementos de alta cardinalidad — es tamaño y almacenamiento gratis recuperado.
• Los valores grandes van en S3. Almacena los grandes bloques de datos (imágenes, documentos) en S3 y guarda solo la clave en el elemento.
• Relacionado: desnormalización y relaciones de uno a muchos cubren cuándo incrustar frente a dividir.

¿Quieres ver los tamaños reales de los elementos de una tabla de un vistazo? Descarga DynoTable e inspecciona tus datos directamente.

Cifras de capacidad verificadas el 2026-07-26 contra el servicio DynamoDB en vivo en us-east-1 (pnpm content:verify-item-size).