¿Es DynamoDB una base de datos NoSQL?

Sí. DynamoDB es una base de datos NoSQL — un almacén de clave-valor y documentos no relacional, totalmente gestionado. Guarda Items sin esquema fijo en lugar de filas en tablas de esquema rígido, y cambia joins SQL y consultas ad hoc por un rendimiento predecible de milisegundos de un solo dígito y escalado horizontal a prácticamente cualquier tamaño.

Qué tipo de NoSQL

DynamoDB admite tanto el modelo de datos clave-valor como el de documentos. Cada Item se aborda por una clave primaria, y los atributos pueden anidarse como mapas y listas hasta 32 niveles de profundidad — el lado documento del modelo.

En qué se diferencia de SQL

Sin esquema fijo — solo la clave primaria se define de antemano; otros atributos varían por Item.
Sin joins — desnormalizas y modelas en torno a patrones de acceso.
Rendimiento predecible — las lecturas apuntan a una clave de partición, así que la latencia se mantiene plana a medida que crecen los datos.

Qué hace el motor con un JOIN

PartiQL hace que DynamoDB parezca con forma SQL, así que el límite es fácil de pasar por alto. La sintaxis documentada de SELECT de AWS es toda la gramática, y no tiene cláusula JOIN:

SELECT {{expression}}  [, ...]
FROM {{table}}[.{{index}}]
[ WHERE {{condition}} ] [ [ORDER BY {{key}} [DESC|ASC] , ...]

Envía uno de todos modos y el analizador se detiene en la segunda tabla:

await client.send(
  new ExecuteStatementCommand({
    Statement: `SELECT o.pk FROM "orders" o JOIN "customers" c ON o.pk = c.pk`
  })
);

Salida real:

ValidationException: Only select from a single table or index is supported.
HTTP 400

El rechazo ocurre en tiempo de análisis, antes de leer datos, por eso ningún diseño de índice te da un join. Unir es trabajo de tu aplicación en un almacén NoSQL.

También acota lo que cualquier cliente puede ofrecer con honestidad. El SQL Workbench de DynoTable acepta INNER JOIN, LEFT JOIN, GROUP BY y COUNT/SUM/AVG/MIN/MAX.

Los compila a llamadas nativas Query y Scan, y luego une y agrega los resultados en tu máquina. DynamoDB sigue viendo únicamente lecturas de una sola tabla.

Cuándo encaja

DynamoDB está pensado para cargas OLTP: lecturas y escrituras puntuales y por rango de alto volumen y conocidas. El análisis pesado pertenece a un almacén columnar separado alimentado por exportación.

Límites NoSQL que sigues notando en producción

«NoSQL» describe el modelo de acceso, no la eliminación de restricciones. DynamoDB sigue limitándote a 400 KB por Item, 25 acciones por TransactWriteItems y 100 acciones de lectura o escritura por transacción. Un documento anidado puede tener 32 niveles de profundidad. Los GSI proyectan solo los atributos que nombras; no hay esquema oculto al que recurrir.

Esos límites importan porque no puedes salir de ellos con un join en tiempo de consulta. Modelas en torno a ellos de antemano — índices dispersos, atributos desnormalizados y claves de tabla única — y luego lees por partición. El Query Builder convierte un filtro en la solicitud Query o Scan que DynamoDB ejecutará de verdad.

En DynoTable: cuando una pregunta relacional es legítima, el SQL Workbench compila JOIN y GROUP BY hasta llamadas nativas Query y Scan en tu máquina — DynamoDB sigue viendo lecturas de una sola tabla. Consulta SQL Workbench para la gramática admitida y los límites honestos.

Profundiza

Consulta cuándo usar DynamoDB y cómo dar forma a los datos con cómo modelar datos en DynamoDB. Descarga DynoTable para explorar tus tablas NoSQL y ejecutar SQL sobre ellas dentro de las reglas de patrones de acceso de DynamoDB.

Referencias

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba; la gramática PartiQL SELECT se volvió a comprobar el 2026-07-28.

Reproducido el 2026-07-28 contra DynamoDB Local 3.3.0 vía @aws-sdk/client-dynamodb 3.1095.0 en Node v24.18.0. La ValidationException anterior es salida literal del motor.