DynamoDB PartiQL vs SQL: qué cambia (y qué se rompe)

La mayor fuente de confusión con PartiQL de DynamoDB — tanto para humanos como para asistentes de IA — es tratarlo como SQL relacional. No lo es. PartiQL es una superficie compatible con SQL sobre las operaciones existentes de DynamoDB, no un motor de consultas capaz de unir, agrupar o agregar. Las palabras clave familiares esconden una máquina muy distinta por debajo.

El modelo mental

Cada sentencia PartiQL se compila a una de las operaciones nativas de DynamoDB:

No hay ningún planificador capaz de leer de dos tablas, construir un hash join o plegar filas en un COUNT. Si una operación no se asigna a un único Get/Query/Scan/ Put/Update/Delete, PartiQL sencillamente no puede expresarla. Esa es toda la historia — todo lo de abajo es una consecuencia de este único hecho.

El mismo mapeo, como un flujo — la cláusula WHERE decide si un SELECT es un Query barato o un Scan de tabla completa:

Cada sentencia se resuelve en exactamente una operación nativa — ese mapeo uno a uno es la razón por la que PartiQL no puede unir, agrupar ni agregar.

Qué cambia — característica por característica

Cada que el SQL Workbench de DynoTable sí puede ejecutar está marcado. El Workbench materializa tus tablas a través del motor de consultas real de DynamoDB y ejecuta SQL real encima — SQL dentro de las reglas de patrones de acceso de DynamoDB.

Qué se rompe, y por qué

Estos son los fallos que el validador de PartiQL de DynoTable señala antes de que la consulta llegue a la red — cada uno se remonta a una restricción real de DynamoDB.

• SELECT * sin una partition key es un Scan oculto. PartiQL no dará error; simplemente lee cada ítem y filtra después, que es el clásico cepo de costo Query-vs-Scan detrás de una sintaxis amigable.
• UPDATE / DELETE necesitan la clave primaria completa. Se asignan a un UpdateItem/DeleteItem de un solo ítem, así que el WHERE debe fijar la partition key (y la sort key, en una tabla con clave compuesta). No puedes "actualizar todas las filas donde status = 'open'" en una sola sentencia.
• Las comillas dobles son identificadores, no cadenas. PartiQL de DynamoDB sigue el estándar SQL aquí: "name" es un nombre de columna/tabla, 'name' es un valor de cadena. Entrecomillar un valor con comillas dobles es el error de principiante más común — el mensaje del validador es literalmente "Double quotes delimit identifiers in DynamoDB PartiQL, not strings. Use single quotes for string values."
• IN usa corchetes, no paréntesis: WHERE pk IN ['a','b'], con un tope de 50 valores de PK / 100 valores que no son clave.
• Sin JOIN, sin agregados. No hay ningún motor que combine tablas o pliegue filas. Este es el compromiso del single-table-design: modelas para tus patrones de acceso por adelantado porque la capa de consultas no puede reformar los datos después.

Por qué los asistentes de IA se equivocan en esto

Los LLM están entrenados sobre océanos de SQL relacional, así que emiten con confianza JOIN, GROUP BY, LIKE, LIMIT inline y literales de cadena con comillas dobles contra DynamoDB — todo lo cual DynamoDB rechaza. El autofix de consultas de modelo de DynoTable existe precisamente porque los modelos baratos producen estos patrones de forma fiable: elimina las comillas con doble escape, reescribe LIKE '%x%' → contains, IS NULL → attribute_not_exists, y eleva el LIMIT inline al parámetro de la petición. Si tu IA está generando "PartiQL" que se lee como Postgres, esa es la señal.

SELECT o.id, c.name
FROM orders o
JOIN customers c ON o.customerId = c.PK

SELECT country, COUNT(*) AS orders, SUM(total) AS revenue
FROM orders
GROUP BY country

SELECT * FROM orders
WHERE customerId IN (SELECT PK FROM customers WHERE country = 'ES')

SELECT PK FROM orders
UNION
SELECT PK FROM archived_orders

SELECT * FROM orders

UPDATE orders SET status = 'shipped'
WHERE status = 'open'

SELECT * FROM users WHERE "name" = "Alice"

El SQL Workbench de DynoTable: las consultas que PartiQL no puede ejecutar

Cuando realmente necesitas un JOIN o un GROUP BY, el SQL Workbench de DynoTable es la respuesta. Valida el lado destino de cada JOIN contra una partition key, materializa las filas unidas a través del motor real Query/Scan de DynamoDB, y luego ejecuta tu SQL completo (agregados, GROUP BY, DISTINCT, CASE, CAST) encima — SQL dentro de las reglas de patrones de acceso de DynamoDB.

-- Runs in the DynoTable Workbench (NOT in 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

Restricciones honestas (el Workbench impone el modelo de acceso de DynamoDB, no pretende ser Postgres):

• Solo INNER JOIN y LEFT JOIN — el atributo destino del ON debe ser una partition key o una GSI partition key. 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 condiciones y expresiones de clave para la API en bruto, el DynamoDB Expression Builder genera el FilterExpression / KeyConditionExpression correcto sin la superficie de PartiQL en absoluto. Para PartiQL bien hecho, mira los ejemplos de PartiQL resueltos; para dimensionar cuánto costará cualquier consulta, usa la calculadora de tamaño de ítem. Ten en cuenta que PartiQL nunca cambia el formato de red — los valores siguen viajando como DynamoDB-JSON. ¿Eligiendo un cliente? Mira cómo se posiciona el Workbench frente a una GUI sencilla de DynamoDB o Dynobase.

Preguntas frecuentes

¿PartiQL es lo mismo que SQL? No. PartiQL es un lenguaje de consultas compatible con SQL, pero en DynamoDB solo expone operaciones que se asignan a un único Get/Query/Scan/Put/Update/Delete. No tiene joins, agregados, subconsultas ni GROUP BY.

¿Puede PartiQL de DynamoDB hacer un JOIN? No. PartiQL de DynamoDB no puede unir tablas. El SQL Workbench de DynoTable sí puede ejecutar INNER/LEFT JOIN (a una partition key o GSI partition key) materializando los datos a través del motor de consultas real de DynamoDB.

¿PartiQL de DynamoDB admite GROUP BY o COUNT? No — no hay agregados ni GROUP BY en PartiQL de DynamoDB. Usa el SQL Workbench de DynoTable para consultas COUNT/SUM/AVG/GROUP BY/HAVING.

¿Por qué mi SELECT * cuesta tanto? Sin una partition key en el WHERE, PartiQL ejecuta un Scan de tabla completa y mide cada ítem leído antes de aplicar el filtro. Añade un predicado de partition key para convertirlo en un Query.

¿Debería usar comillas simples o dobles en PartiQL? Comillas simples para valores de cadena ('CUSTOMER#42'), comillas dobles para identificadores como nombres de tabla y de atributo ("AppData"). Entrecomillar un valor con comillas dobles es el error más común de PartiQL.

¿Listo para ejecutar SQL real contra DynamoDB? Descarga DynoTable y abre una pestaña de Workbench.