SQL para DynamoDB: qué funciona, qué no, y el Workbench

DynamoDB es un almacén clave-valor NoSQL, pero responde preguntas con forma de SQL más de lo que la gente espera — y mucho menos de lo que esperan. Este es el mapa honesto: qué SQL-sobre-DynamoDB obtienes de fábrica realmente, dónde se detiene, y las pocas maneras de ejecutar las consultas de JOIN / GROUP BY / agregado que la superficie nativa no puede expresar.

¿Puedes consultar DynamoDB con SQL? La respuesta corta

En parte. DynamoDB incluye PartiQL, que las Docs de AWS describen como «un lenguaje de consulta compatible con SQL, para seleccionar, insertar, actualizar y eliminar datos en Amazon DynamoDB.» Así que puedes escribir SELECT * FROM "Orders" WHERE OrderID = 100 y funciona.

Pero PartiQL es una superficie compatible con SQL sobre la API de DynamoDB, no un motor SQL. Habla la sintaxis; no añade potencia de consulta relacional. AWS es explícito en que «Amazon DynamoDB soporta un subconjunto del lenguaje de consulta PartiQL» (referencia). En el momento en que buscas un JOIN, un GROUP BY o COUNT(*), estás fuera de lo que PartiQL puede hacer — mira PartiQL vs SQL para la comparación completa característica por característica.

PartiQL: una superficie compatible con SQL, no un motor SQL

PartiQL asigna sentencias con aspecto de SQL a las mismas operaciones del plano de datos que el SDK expone. Un SELECT con una igualdad de clave de partición se compila a un Query; un SELECT sin ella se compila a un Scan. Según la referencia de SELECT de AWS:

Usar la sentencia SELECT puede resultar en un escaneo de tabla completa si no se proporciona una condición de igualdad o IN con una clave de partición en la cláusula WHERE.

Así que las mismas reglas de patrón de acceso que gobiernan Query y Scan siguen aplicando — PartiQL solo las esconde tras una sintaxis familiar. No añade planificador de consultas, ni joins, ni agregación basada en conjuntos. Cada sentencia colapsa a una operación nativa:

Tú escribes	DynamoDB ejecuta
`SELECT … WHERE PK = …`	`GetItem` o `Query`
`SELECT …` (sin PK)	`Scan` (lee la tabla entera)
`INSERT INTO …`	`PutItem`
`UPDATE … WHERE PK=… AND SK=…`	`UpdateItem` (un Item)
`DELETE … WHERE PK=… AND SK=…`	`DeleteItem` (un Item)

Si una operación no se reduce a un solo Get/Query/Scan/Put/Update/Delete, PartiQL simplemente no puede expresarla. Todo lo de abajo es una consecuencia de ese único hecho.

Qué cubre PartiQL

PartiQL de DynamoDB soporta cuatro sentencias DML/de consulta:

SELECT — leer Items (se compila a Query o Scan)
INSERT — añadir un Item (PutItem)
UPDATE — modificar un Item (UpdateItem)
DELETE — eliminar un Item (DeleteItem)

También soporta transacciones y operaciones por lotes. Una lectura bien formada apunta a la clave de partición con una igualdad o un IN:

SELECT OrderID, Total
FROM "Orders"
WHERE OrderID IN [1, 2, 3] ORDER BY OrderID DESC

ORDER BY está permitido, pero la referencia de AWS restringe la clave de ordenación a «una hash key o una sort key» — la clave de partición o de orden, no columnas arbitrarias. Ese es el techo de lo que el SELECT de PartiQL acepta. Para sentencias listas para copiar y pegar, mira los ejemplos de PartiQL.

Qué no puede hacer PartiQL

Estas son las cosas que los desarrolladores más a menudo esperan de «SQL», y PartiQL soporta ninguna de ellas:

Sin JOIN. La sintaxis de SELECT de PartiQL es un único FROM {{table}}[.{{index}}] — una tabla o un índice, nunca dos tablas relacionadas por una clave. Este es el compromiso del diseño de tabla única: modelas para tus patrones de acceso de antemano porque la capa de consulta no puede reformar los datos después.
Sin GROUP BY. No está en la gramática; no hay cláusula para agrupar filas.
Sin funciones de agregado. La referencia de funciones de PartiQL lista exactamente una función bajo «Funciones de agregado»: SIZE, que devuelve el tamaño en bytes de un atributo para un solo Item. No hay COUNT, SUM, AVG, MIN ni MAX a través de filas. AWS lo afirma sin rodeos: «Cualquier función SQL que no esté incluida en esta lista no está actualmente soportada en DynamoDB.»
Sin LIKE, sin subconsultas, sin UNION, sin funciones de ventana. La coincidencia de patrones usa contains / begins_with; el resto no tiene equivalente en absoluto.

Así que «ingresos totales por cliente el mes pasado» — un GROUP BY de una línea en cualquier base de datos relacional — no puede expresarse en PartiQL. Tendrías que sacar los datos con un scan y agregarlos en código de aplicación.

La única manera de obtener comportamiento real de JOIN / GROUP BY / agregado sobre datos de DynamoDB es una herramienta que ejecute un motor SQL real encima. Hay dos: el conector federado de Amazon Athena, y el SQL Workbench de DynoTable.

Cómo consultar DynamoDB con SQL real vía Amazon Athena

La propia respuesta de AWS a «SQL real sobre DynamoDB» es el conector de DynamoDB de Amazon Athena, que «permite a Amazon Athena comunicarse con DynamoDB para que puedas consultar tus tablas con SQL.» Como Athena es un motor SQL completo, esto sí te da JOIN y agregados — el tutorial de AWS se titula «Acceder, consultar y unir tablas de Amazon DynamoDB usando Athena.»

El inconveniente es la configuración y el coste:

Es un conector federado basado en Lambda que despliegas en tu cuenta (vía la consola de Athena o el Serverless Application Repository), conectado a través de AWS Glue para el schema y volcando resultados a un bucket de S3 (docs del conector).
Por debajo aún usa las operaciones de API Query y Scan de DynamoDB. AWS advierte que «las consultas que usan scans pueden consumir un gran número de unidades de capacidad de lectura (RCU)», así que una consulta analítica sobre una tabla grande lee — y mide — muchos Items (costes del conector). Usa la calculadora de tamaño de Item para estimar lo que costará una consulta intensiva en scan.
Operaciones de escritura como INSERT INTO no están soportadas a través del conector.

Athena es la herramienta correcta para analítica programada y dashboards de BI. Es pesada para el caso cotidiano de «solo necesito unir dos tablas y echar un vistazo al resultado» — ese es el hueco que llena la siguiente sección.

SQL Workbench de DynoTable: SQL dentro de las reglas de patrón de acceso de DynamoDB

El SQL Workbench de DynoTable ejecuta SQL real — JOIN, GROUP BY, COUNT/SUM/AVG — contra tus tablas DynamoDB en vivo desde un cliente de escritorio, sin Lambda, Glue ni S3 que montar. Materializa las filas a través del runtime real Query/Scan de DynamoDB, y luego ejecuta tu SQL completo en un motor en memoria encima:

-- Se ejecuta en el Workbench de DynoTable (NO en PartiQL):
SELECT c.country, COUNT(*) AS orders, SUM(o.total) AS revenue
FROM orders o
INNER JOIN customers c ON o.customerId = c.PK
GROUP BY c.country
ORDER BY revenue DESC

La parte de «dentro de las reglas de patrón de acceso de DynamoDB» importa. El Workbench no pretende que DynamoDB sea Postgres — aún lee a través de Query/Scan por debajo, así que sigues consciente de lo que cuesta cada consulta, e impone el modelo de acceso de DynamoDB en lugar de ocultarlo:

Solo INNER JOIN y LEFT JOIN — el atributo-destino del ON debe ser una clave de partición o clave de partición de GSI. Sin RIGHT / FULL / CROSS / comma-join.
Aún sin self-joins, sin subconsultas, sin tablas derivadas, sin funciones de ventana.
Los joins y las proyecciones operan sobre atributos escalares.

Si solo necesitas componer las condiciones y expresiones de clave para la API en bruto — no una sentencia SQL completa — el Generador de expresiones de DynamoDB genera la FilterExpression / KeyConditionExpression correcta sin la superficie de PartiQL en absoluto.

Si tu objetivo es un cliente SQL de DynamoDB para explorar, depurar y analizar tablas, el Workbench llena ese hueco — y el resto de DynoTable es una GUI de DynamoDB completa a su alrededor.

Prueba DynoTable para ejecutar SQL real contra tus propias tablas.

Preguntas frecuentes

¿Puedes ejecutar SQL en DynamoDB? Puedes ejecutar PartiQL, un subconjunto compatible con SQL (SELECT/INSERT/UPDATE/DELETE por clave). Para SQL completo — JOIN, GROUP BY, agregados — necesitas un motor SQL encima: el conector de DynamoDB de Amazon Athena, o el SQL Workbench de DynoTable.

¿Soporta PartiQL de DynamoDB JOIN? No. La sintaxis de SELECT de PartiQL tiene una sola tabla o índice en el FROM y ninguna gramática de join. Los joins requieren un motor sobrepuesto a DynamoDB.

¿Soporta PartiQL GROUP BY o agregados como COUNT y SUM? No. No hay cláusula GROUP BY, y la única función «de agregado» es SIZE (el tamaño en bytes de un atributo para un Item). COUNT, SUM, AVG, MIN y MAX a través de filas no están soportados.

¿Es DynamoDB SQL o NoSQL? NoSQL — un almacén clave-valor y documental. PartiQL añade un lenguaje de consulta compatible con SQL encima, pero DynamoDB no tiene motor relacional, joins ni agregados.

¿Es PartiQL bueno para consultas ad-hoc? Para búsquedas basadas en clave, sí. Para consultas analíticas ad-hoc (conteos, rollups, joins), no — PartiQL no puede expresarlas, y los SELECT sin restringir se vuelven silenciosamente escaneos de tabla completa.

¿Hay un cliente SQL de DynamoDB que maneje JOIN y GROUP BY? Sí — el SQL Workbench de DynoTable ejecuta JOIN/GROUP BY/agregados contra tablas en vivo desde el escritorio, y Amazon Athena lo hace vía un conector federado que despliegas en tu cuenta de AWS.