¿DynamoDB es una base de datos relacional?

No. DynamoDB no es una base de datos relacional — es un almacén NoSQL de clave-valor y documentos. No hay tablas con esquemas fijos, ni claves foráneas, ni joins. Modelas los datos en torno a los patrones de acceso de tu aplicación y desnormalizas, en vez de normalizar entre tablas relacionadas como harías en una base de datos relacional (SQL). Si echas de menos el flujo de trabajo relacional, DynoTable recupera parte de él en el cliente: un SQL Workbench que ejecuta JOIN y GROUP BY de verdad, y Smart Tables que unen tablas de forma visual.

Por qué no es relacional

Las bases de datos relacionales imponen un esquema, normalizan los datos en muchas tablas y las unen en el momento de la lectura. DynamoDB hace lo contrario: almacena Items sin esquema y espera que preunas los datos duplicando o incrustando la información relacionada.

Qué sustituye a las funciones relacionales

Joins → desnormalización y diseño de tabla única.
Tablas normalizadas → colecciones de Items agrupadas bajo una clave de partición.
SQL ad hoc → Query y Scan basados en claves, o PartiQL (un subconjunto compatible con SQL, todavía sin joins).

PartiQL no cierra la brecha, por cierto. Su parser rechaza un SELECT sobre dos tablas y rechaza GROUP BY, ambos antes de leer nada; las negativas exactas están citadas en ¿DynamoDB admite joins? y ¿DynamoDB admite SQL?.

Lo que te cuesta de verdad desnormalizar

El intercambio se suele describir como "duplica datos en vez de unirlos", lo que suena a una decisión de almacenamiento. En realidad es una decisión de escritura y de atomicidad, y esa es la parte que los motores relacionales te ocultan.

Toma un cliente con 5.000 pedidos, y el cliente cambia su nombre visible. En un esquema relacional eso es un solo UPDATE sobre una fila, y todos los joins recogen el nuevo valor de inmediato. Desnormalizado en DynamoDB, el nombre vive en los 5.000 Items de pedido, así que el cambio de nombre son 5.000 escrituras de Item: 5.000 unidades de escritura, unos $0.003 en us-east-1 bajo demanda a 1 KB por Item.

El dinero no es nada. El problema es que no puede ser una sola operación. TransactWriteItems está limitado a 100 acciones, así que 5.000 Items son al menos 50 transacciones separadas, y no hay aislamiento entre ellas. Mientras dure ese despliegue, tus propios datos se contradicen entre sí, y cualquier lectura que caiga a mitad de camino ve una mezcla de nombres viejos y nuevos.

Las bases de datos relacionales te compran exactamente eso: un solo cambio atómico sobre una única copia autoritativa. Renunciar a ello es el precio real de la entrada, y por eso "qué atributos se duplican" merece más atención de diseño que cuáles se indexan.

Profundiza

Lee cómo modelar datos en DynamoDB y diseño de tabla única. Descarga DynoTable para explorar tu modelo de datos de forma visual — y ejecutar consultas de estilo relacional con JOIN/GROUP BY sobre él con el SQL Workbench.

Referencias

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba; el tope de 100 acciones por transacción se volvió a consultar en la referencia de la API el 2026-07-28.