El límite de tamaño de elemento de DynamoDB (400 KB)

Un único elemento de DynamoDB puede contener como máximo 400 KB de datos. Si vienes de MongoDB (documentos de 16 MB) o de una fila relacional sin tope práctico, ese techo parece bajo — y tiendes a descubrirlo por las malas, cuando una escritura que funcionó durante meses de repente falla con un ValidationException porque un elemento finalmente 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 la alcanzan suelen estar diciéndote 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 tope duro que no puedes subir. El tamaño cuenta los nombres de atributo junto con los valores, incluyendo cada elemento anidado de listas, mapas y conjuntos. Los elementos suelen alcanzarlo por crecimiento ilimitado, como una lista incrustada que se expande sin fin; el arreglo es modelar, dividir la colección en elementos separados, no comprimir.

• 400 KB por elemento, tope duro. No ajustable, no es 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 todos.
• La causa habitual es el crecimiento ilimitado — incrustar una lista que crece sin límite en un elemento padre.
• El arreglo es modelar, no comprimir. 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

Digamos 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 un único elemento de vehículo cruza los 400 KB y toda escritura sobre él falla — ya no puedes registrar telemetría para ese vehículo en absoluto, porque cada actualización reescribe el elemento entero (ahora sobredimensionado).

El bug no es el límite de tamaño. Es modelar una relación uno-a-muchos ilimitada como una lista incrustada. Eso solo funciona cuando el lado de "muchos" está acotado y es 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 tamaño y almacenamiento que pagas — por eso los modeladores con experiencia mantienen los nombres de atributo cortos.
• 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 los nulos por un coste fijo diminuto.
• La estructura anidada. Una lista o un mapa cuenta su propia sobrecarga más el tamaño de cada elemento y clave dentro de ella, hasta el fondo.

No hay un tope por atributo separado que planificar — es el elemento entero contra la línea de 400 KB. Las cuotas de servicio de AWS detallan 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 leer de forma fuerte — y las lecturas, las escrituras y la replicación se vuelven todas más lentas y caras a medida que los elementos crecen. El tope te empuja hacia elementos pequeños y específicos, y lejos del antipatrón de "traer un blob gigante" 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 la 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 individual crece, las escrituras nunca rebasan el tope, y una única Query sobre VEHICLE#A1 todavía recupera las lecturas de un vehículo como una sola colección de elementos ordenada. Las sublistas acotadas (un puñado de etiquetas, un bloque de configuración fijo) están bien para incrustar; las ilimitadas se convierten en elementos.

Comprobar el tamaño de un elemento en DynoTable

Antes de comprometerte con una forma, pesa un elemento representativo. En DynoTable, abre uno en la Quick View y verás el tamaño en bytes del elemento junto a sus atributos — así detectas una forma demasiado pesada mientras navegas 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 de las RCU/WCU que costará cada lectura y escritura.

Trampas y próximos pasos

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

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