¿Admite DynamoDB SQL?

Parcialmente. DynamoDB admite PartiQL, un lenguaje de consulta compatible con SQL para sentencias SELECT, INSERT, UPDATE y DELETE. No es SQL completo: no hay JOINs, ni GROUP BY, ni agregaciones arbitrarias, y las consultas eficientes siguen requiriendo apuntar a la clave primaria o a un índice. Si quieres esas piezas que faltan, el SQL Workbench de DynoTable ejecuta consultas reales de JOIN, GROUP BY y agregaciones sobre tus tablas DynamoDB desde el escritorio.

Qué te da PartiQL

Una sintaxis SQL familiar para las cuatro operaciones de datos. Puedes escribir SELECT * FROM "Orders" WHERE ... en lugar de construir llamadas de API de bajo nivel, lo cual es cómodo y legible.

Qué no te da

Sin JOINs — DynamoDB es no relacional; desnormalizas en su lugar.
Sin GROUP BY / agregaciones — agrupar y sumar ocurre en tu aplicación.
Sin Scans gratuitos de forma libre — un SELECT sin condición de clave sigue ejecutando un Scan y cuesta en consecuencia.

Dónde se detiene el analizador

No son funciones que puedas alcanzar con sintaxis distinta. Ejecútalas y la sentencia nunca llega a leer un Item:

SELECT "region", SUM("total") FROM "Orders" GROUP BY "region"
  ValidationException: Unsupported clause: GROUP BY

SELECT COUNT(*) FROM "Orders"
  ValidationException: Unexpected path component at 1:8:5

SELECT SUM("total") FROM "Orders"
  ValidationException: Unexpected path component at 1:8:3

SELECT DISTINCT "region" FROM "Orders"
  ValidationException: Unsupported token in expression: DISTINCT

Mira lo que dicen los errores de agregación. No hay función de agregación que el analizador pueda rechazar, así que COUNT(*) se lee como una ruta de atributo y cae en el *, en la columna 8. Así de fina es la superficie SQL.

ORDER BY es el que conviene conocer, porque parece que funciona:

SELECT * FROM "Orders" WHERE "pk" = 'U#1' ORDER BY "total"
  ValidationException: Variable reference total in ORDER BY clause must be part of the primary key

Puedes ordenar por la clave de ordenación, ascendente o descendente, y por nada más. Ordenar por cualquier otro atributo es trabajo de tu aplicación, después de la lectura.

El modelo mental

Piensa en PartiQL como una capa de sintaxis sobre las operaciones Query, Scan y de escritura existentes de DynamoDB; las mismas reglas de patrones de acceso aplican debajo.

SQL real (JOIN, GROUP BY, agregaciones) con DynoTable

PartiQL se detiene en SELECT de una sola tabla. El SQL Workbench de DynoTable va más allá: ejecuta JOIN, GROUP BY y funciones de agregación reales (COUNT, SUM, AVG, MIN, MAX) sobre tus tablas DynamoDB. Lee los Items a través de la API normal de DynamoDB y luego ejecuta la parte relacional de la consulta en el cliente: SQL dentro de las reglas de patrones de acceso de DynamoDB, ya que cada join sigue leyendo a través de una clave o índice real. Así que las tres cosas que PartiQL no puede hacer, las escribes como una sentencia:

SELECT   c.region, COUNT(*) AS orders, SUM(o.total) AS revenue
FROM     Orders o
JOIN     Customers c ON o.customerId = c.id
GROUP BY c.region

Es honesto sobre las restricciones subyacentes (un join sin límite es una lectura sin límite), así que las consultas más rápidas son las cuyo join o WHERE alcanza una clave de partición o índice. Detalle completo en SQL para DynamoDB y el manual del producto en /docs/dynamodb-sql-workbench.

Prototipa el lado PartiQL del mismo modelo de datos con el DynamoDB query builder — emite programas Query acotados por partición que se mantienen en la ruta eficiente que PartiQL SELECT usa cuando hay condición de clave.

Profundiza

Compara los dos en PartiQL vs SQL, consulta ejemplos de PartiQL y lee SQL para DynamoDB. Descarga DynoTable para escribir PartiQL, y JOIN, GROUP BY y agregaciones reales, contra tus tablas.

Referencias

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

Cada ValidationException anterior se reprodujo el 2026-07-28 contra DynamoDB Local 3.3.0 vía @aws-sdk/client-dynamodb 3.1095.0 y se cita literalmente, desplazamientos de columna incluidos.