PartiQL vs SQL en DynamoDB: qué se rompe

La mayor fuente de confusión con el 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 que pueda unir, agrupar o agregar. Las palabras clave familiares ocultan una máquina muy distinta por debajo.

¿En qué se diferencia el PartiQL de DynamoDB del SQL?

PartiQL toma prestada la sintaxis de SQL pero no su motor. En DynamoDB cada sentencia se corresponde con una sola operación nativa —GetItem, Query, Scan, PutItem, UpdateItem o DeleteItem— así que no hay JOIN, GROUP BY, subconsulta ni agregado. Se lee como SQL pero solo puede hacer lo que esas operaciones clave-valor ya hacen.

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

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

La misma correspondencia, como flujo: la cláusula WHERE decide si un SELECT es una Query barata o un Scan de tabla completa:

Cada sentencia se resuelve a exactamente una operación nativa: esa correspondencia uno a uno es la razón por la que PartiQL no puede unir, agrupar ni agregar.

Qué es distinto — característica por característica

Allí donde la columna del Workbench dice Sí frente a un No de PartiQL, esa es una brecha que cierra el Workbench SQL de DynoTable. El Workbench materializa tus tablas a través del motor de consultas real de DynamoDB y ejecuta SQL de verdad encima: SQL dentro de las reglas de patrón de acceso de DynamoDB.

Qué se rompe, y por qué

Estos son los fallos que el validador de PartiQL de DynoTable marca antes de que la consulta llegue siquiera al cable: cada uno se remonta a una restricción real de DynamoDB.

• SELECT * sin una clave de partición es un Scan oculto. PartiQL no da error; simplemente lee cada elemento y filtra después, que es el clásico tiro por la culata de coste de Query vs Scan detrás de una sintaxis amable.
• UPDATE / DELETE necesitan la clave principal completa. Se corresponden con un UpdateItem/DeleteItem de un solo elemento, así que el WHERE debe fijar la clave de partición (y la clave de ordenación, en una tabla de clave compuesta). No puedes "actualizar todas las filas donde status = 'open'" en una sola sentencia.
• Las comillas dobles son identificadores, no cadenas. El PartiQL de DynamoDB sigue aquí el estándar SQL: "name" es un nombre de columna/tabla, 'name' es un valor de cadena. Entrecomillar un valor con comillas dobles es el error más común de principiante: el mensaje del validador es literalmente "Las comillas dobles delimitan identificadores en el PartiQL de DynamoDB, no cadenas. Usa comillas simples para valores de cadena."
• IN usa corchetes, no paréntesis: WHERE pk IN ['a','b'], con un tope de 50 valores de PK / 100 valores que no sean de clave.
• Nada de JOIN, nada de agregados. No hay ningún motor que combine tablas o pliegue filas. 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 reconfigurar 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 en línea y literales de cadena entre comillas dobles contra DynamoDB, cosas que DynamoDB rechaza todas. El autocorrector de consultas de modelos de DynoTable existe precisamente porque los modelos baratos producen de forma fiable estos patrones: quita las comillas doblemente escapadas, reescribe LIKE '%x%' → contains, IS NULL → attribute_not_exists y eleva el LIMIT en línea 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 Workbench SQL de DynoTable: las consultas que PartiQL no puede ejecutar

Cuando realmente necesitas un JOIN o un GROUP BY, el Workbench SQL de DynoTable es la respuesta. Valida el lado destino de cada JOIN contra una clave de partición, materializa las filas unidas a través del motor real de Query/Scan de DynamoDB y luego ejecuta un único SELECT (agregados, GROUP BY, DISTINCT, CASE, CAST) encima: SQL dentro de las reglas de patrón 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 hace cumplir el modelo de acceso de DynamoDB, no pretende ser Postgres):

• Solo INNER JOIN y LEFT JOIN: el atributo destino del ON debe ser una clave de partición o una clave de partición de GSI. Nada de RIGHT / FULL / CROSS / join por comas.
• Todavía sin auto-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 crudo, el Constructor de expresiones de DynamoDB genera la FilterExpression / KeyConditionExpression correcta sin la superficie de PartiQL en absoluto. Para hacer PartiQL bien, consulta los ejemplos de PartiQL desarrollados; para dimensionar lo que costará cualquier consulta, usa la calculadora de tamaño de elemento. Ten en cuenta que PartiQL nunca cambia el formato del cable: los valores siguen viajando como DynamoDB-JSON. ¿Eligiendo un cliente? Mira dónde se sitúa el Workbench frente a una GUI de DynamoDB corriente o Dynobase.

Preguntas frecuentes

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

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

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

¿Por qué mi SELECT * cuesta tanto? Sin una clave de partición en el WHERE, PartiQL ejecuta un Scan de tabla completa y mide cada elemento leído antes de que se aplique el filtro. Añade un predicado de clave de partición para convertirlo en una 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 atributo ("AppData"). Entrecomillar un valor con comillas dobles es el error más común de PartiQL.

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