¿DynamoDB no tiene esquema?

Así es. DynamoDB no tiene esquema. Aparte de la clave principal, no defines ningún atributo ni tipo de dato cuando creas una tabla. Cada Item puede llevar su propio conjunto de atributos, y pueden variar libremente de uno al siguiente — así que adaptas tu modelo de datos sin ejecutar migraciones de esquema.

Qué defines por adelantado

Solo la clave principal: una clave de partición (obligatoria) y una clave de ordenación opcional, más sus tipos. Todo lo demás es arbitrario. No declaras columnas.

Qué varía por Item

Dos Items cualesquiera de la misma tabla pueden tener atributos completamente distintos. Uno puede llevar email y status; otro puede llevar orderTotal y un mapa address anidado. DynamoDB guarda lo que escribas.

Dónde se detiene la ausencia de esquema

La ausencia de esquema tiene un límite preciso. La clave principal se valida en cada escritura; nada más. Dos Items sin ningún atributo en común entran en la misma tabla sin queja alguna:

await client.send(
  new PutItemCommand({
    TableName: 'people',
    Item: {pk: {S: 'USER#1'}, email: {S: 'a@b.c'}, status: {S: 'active'}}
  })
);
await client.send(
  new PutItemCommand({
    TableName: 'people',
    Item: {
      pk: {S: 'ORDER#1'},
      orderTotal: {N: '42.5'},
      address: {M: {city: {S: 'Madrid'}}},
      tags: {SS: ['a', 'b']}
    }
  })
);

Ambos funcionan. Ahora escribe la misma clave de partición como número en lugar de como cadena:

ValidationException: One or more parameter values were invalid: Type mismatch for key
HTTP 400

Y omite pk por completo:

ValidationException: One of the required keys was not given a value
HTTP 400

Esos dos rechazos son todo el esquema que hay. El atributo clave tiene que estar presente y tiene que coincidir con el tipo declarado en AttributeDefinitions. Todo lo que va más allá se acepta tal cual se escribió.

Una errata también pasa. Nada te avisa en tiempo de escritura de que staus debía ser status.

Por qué ayuda

Sin migraciones — añade o quita atributos cuando quieras.
Entidades mezcladas — muchos tipos de entidad pueden compartir una tabla (diseño de tabla única).
Evolucionable — el modelo cambia según cambian los requisitos.

Quien impone cualquier forma de la que dependas es tu aplicación, no la base de datos.

Lo que el sin esquema no relaja

Sin esquema aplica solo a los atributos que no son clave. El resto de límites de DynamoDB siguen vigentes:

400 KB por item — nombres y valores de atributo cuentan para el techo.
32 niveles de anidación para maps y listas dentro de un valor.
65.535 bytes de longitud máxima para un solo nombre de atributo.
25 items como máximo por llamada a BatchWriteItem.

Puedes poner un string status en un item y omitirlo en el siguiente, pero no puedes guardar un blob de 500 KB en ninguno. Usa la calculadora de tamaño de item para medir un payload antes de escribirlo, y lee diseño de tabla única cuando mezclas tipos de entidad en una tabla.

En DynoTable: abre Ajustes en cualquier tabla e indéxala. El esquema inferido se construye a partir de items muestreados y se etiqueta con honestidad — muestra lo que has escrito, no lo que declaraste. Mira Resumen e indexación de la tabla para cómo el índice local muestrea y se refresca.

Profundiza

Mira diseño de tabla única y el patrón del atributo de tipo para Items mezclados. Descarga DynoTable para inspeccionar formas de Items reales.

Referencias

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

Reproducido el 2026-07-28 contra DynamoDB Local 3.3.0 mediante @aws-sdk/client-dynamodb 3.1095.0 en Node v24.18.0. Ambos mensajes ValidationException son salida literal del motor.