DynamoDB PartiQL vs SQL : ce qui casse

La plus grande source de confusion avec le PartiQL de DynamoDB — pour les humains comme pour les assistants IA — est de le traiter comme du SQL relationnel. Il ne l'est pas. PartiQL est une surface compatible SQL au-dessus des opérations existantes de DynamoDB, pas un moteur de requête capable de joindre, grouper ou agréger. Les mots-clés familiers cachent une machine très différente en dessous.

En quoi le PartiQL de DynamoDB diffère-t-il de SQL ?

PartiQL emprunte la syntaxe de SQL mais pas son moteur. Sur DynamoDB, chaque instruction correspond à une seule opération native — GetItem, Query, Scan, PutItem, UpdateItem ou DeleteItem — donc il n'y a pas de JOIN, GROUP BY, sous-requête ni agrégat. Ça se lit comme du SQL mais ne peut faire que ce que ces opérations clé-valeur font déjà.

Chaque instruction PartiQL se compile vers l'une des opérations natives de DynamoDB :

Il n'y a pas de planificateur capable de lire depuis deux tables, de construire une jointure par hachage, ou de replier des lignes en un COUNT. Si une opération ne correspond pas à un seul Get/Query/Scan/Put/Update/ Delete, PartiQL ne peut tout simplement pas l'exprimer. C'est toute l'histoire — tout ce qui suit est une conséquence de ce seul fait.

Le même mapping, sous forme de flux — la clause WHERE décide si un SELECT est un Query bon marché ou un Scan de table entière :

Chaque instruction se résout à exactement une opération native — ce mapping un-à-un est la raison pour laquelle PartiQL ne peut pas joindre, grouper ou agréger.

Ce qui diffère — fonctionnalité par fonctionnalité

Partout où la colonne Workbench affiche Oui face à un Non de PartiQL, c'est une lacune que le Workbench SQL de DynoTable comble. Le Workbench matérialise tes tables à travers le vrai runtime de requête de DynamoDB et exécute du vrai SQL par-dessus — du SQL dans le respect des règles de modèle d'accès de DynamoDB.

Ce qui casse, et pourquoi

Voici les échecs que le validateur PartiQL de DynoTable signale avant même que la requête n'atteigne le réseau — chacun remonte à une vraie contrainte de DynamoDB.

• SELECT * sans clé de partition est un Scan caché. PartiQL ne renverra pas d'erreur ; il lit simplement chaque item puis filtre ensuite, ce qui est le classique piège de coût Query-vs-Scan derrière une syntaxe accueillante.
• UPDATE / DELETE ont besoin de la clé primaire complète. Ils correspondent à un UpdateItem/DeleteItem mono-item, donc le WHERE doit épingler la clé de partition (et la clé de tri, sur une table à clé composite). Tu ne peux pas « mettre à jour toutes les lignes où status = 'open' » en une seule instruction.
• Les guillemets doubles sont des identifiants, pas des chaînes. Le PartiQL de DynamoDB suit le standard SQL ici : "name" est un nom de colonne/table, 'name' est une valeur chaîne. Entourer une valeur de guillemets doubles est l'erreur de débutant la plus courante — le message du validateur est littéralement « Les guillemets doubles délimitent les identifiants dans le PartiQL de DynamoDB, pas les chaînes. Utilisez des guillemets simples pour les valeurs chaînes. »
• IN utilise des crochets, pas des parenthèses : WHERE pk IN ['a','b'], plafonné à 50 valeurs de PK / 100 valeurs hors clé.
• Pas de JOIN, pas d'agrégats. Il n'y a pas de moteur pour combiner des tables ou replier des lignes. C'est le compromis de la conception à table unique : tu modélises pour tes modèles d'accès en amont parce que la couche de requête ne peut pas remodeler les données après coup.

Pourquoi les assistants IA se trompent

Les LLM sont entraînés sur des océans de SQL relationnel, donc ils émettent avec assurance JOIN, GROUP BY, LIKE, LIMIT en inline et des littéraux chaînes à guillemets doubles contre DynamoDB — qui rejette tout ça. L'autofix de requête de modèle propre à DynoTable existe précisément parce que les modèles bon marché produisent de façon fiable ces motifs : il retire les guillemets doublement échappés, réécrit LIKE '%x%' → contains, IS NULL → attribute_not_exists, et hisse le LIMIT en inline vers le paramètre de requête. Si ton IA génère du « PartiQL » qui se lit comme du Postgres, c'est le signe.

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"

Le SQL Workbench de DynoTable : les requêtes que PartiQL ne peut pas exécuter

Quand tu as réellement besoin d'un JOIN ou d'un GROUP BY, le SQL Workbench de DynoTable est la réponse. Il valide le côté-vers de chaque JOIN contre une clé de partition, matérialise les lignes jointes à travers le vrai runtime Query/Scan de DynamoDB, puis exécute un seul SELECT (agrégats, GROUP BY, DISTINCT, CASE, CAST) par-dessus — du SQL dans le respect des règles de modèle d'accès 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

Contraintes honnêtes (le Workbench applique le modèle d'accès de DynamoDB, il ne prétend pas être Postgres) :

• INNER JOIN et LEFT JOIN uniquement — l'attribut-cible du ON doit être une clé de partition ou une clé de partition de GSI. Pas de RIGHT / FULL / CROSS / jointure virgule.
• Pas encore d'auto-jointures, pas de sous-requêtes, pas de tables dérivées, pas de fonctions de fenêtrage.
• Les jointures et projections opèrent sur des attributs scalaires.

Si tu as seulement besoin de composer des conditions et des expressions de clé pour l'API brute, le DynamoDB Expression Builder génère la FilterExpression / KeyConditionExpression correcte sans passer par la surface PartiQL du tout. Pour du PartiQL fait correctement, vois les exemples PartiQL illustrés ; pour estimer ce que coûtera une requête, utilise le calculateur de taille d'item. Note que PartiQL ne change jamais le format réseau — les valeurs voyagent toujours en DynamoDB-JSON. Tu choisis un client ? Vois où se situe le Workbench face à une GUI DynamoDB classique ou à Dynobase.

FAQ

PartiQL est-il la même chose que SQL ? Non. PartiQL est un langage de requête compatible SQL, mais sur DynamoDB il n'expose que des opérations correspondant à un seul Get/Query/Scan/Put/Update/Delete. Il n'a pas de jointures, d'agrégats, de sous-requêtes ni de GROUP BY.

Le PartiQL de DynamoDB peut-il faire un JOIN ? Non. Le PartiQL de DynamoDB ne peut pas joindre de tables. Le SQL Workbench de DynoTable peut exécuter un INNER/LEFT JOIN (vers une clé de partition ou une clé de partition de GSI) en matérialisant les données à travers le vrai runtime de requête de DynamoDB.

Le PartiQL de DynamoDB prend-il en charge GROUP BY ou COUNT ? Non — il n'y a pas d'agrégats ni de GROUP BY dans le PartiQL de DynamoDB. Utilise le SQL Workbench de DynoTable pour les requêtes COUNT/SUM/AVG/GROUP BY/HAVING.

Pourquoi mon SELECT * coûte-t-il si cher ? Sans clé de partition dans le WHERE, PartiQL exécute un Scan de table entière et facture chaque item lu avant que le filtre ne s'applique. Ajoute un prédicat sur la clé de partition pour le transformer en Query.

Dois-je utiliser des guillemets simples ou doubles en PartiQL ? Guillemets simples pour les valeurs chaînes ('CUSTOMER#42'), guillemets doubles pour les identifiants comme les noms de table et d'attribut ("AppData"). Entourer une valeur de guillemets doubles est l'erreur PartiQL la plus courante.

Prêt à exécuter du vrai SQL contre DynamoDB ? Télécharge DynoTable et ouvre un onglet Workbench.