DynamoDB PartiQL vs SQL : ce qui diffère (et ce qui casse)

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

Le modèle mental

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

Il n'existe aucun 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 découle de cet unique fait.

Le même mapping, sous forme de flux — la clause WHERE décide si un SELECT est un Query économique ou un Scan de toute la table :

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

Ce qui diffère — fonctionnalité par fonctionnalité

Chaque que le Workbench SQL de DynoTable peut exécuter est marqué. Le Workbench matérialise tes tables à travers le véritable moteur de requêtes de DynamoDB et exécute du vrai SQL par-dessus — du SQL dans les règles 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 renvoie à une vraie contrainte de DynamoDB.

• SELECT * sans clé de partition est un Scan caché. PartiQL ne produit pas d'erreur ; il lit simplement chaque item et filtre ensuite, ce qui est le piège de coût classique Query vs Scan derrière une syntaxe conviviale.
• UPDATE / DELETE nécessitent la clé primaire complète. Ils correspondent à un UpdateItem/DeleteItem sur un seul item, donc le WHERE doit fixer 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 désignent des identifiants, pas des chaînes. PartiQL pour DynamoDB suit ici le standard SQL : "name" est un nom de colonne ou de table, 'name' est une valeur de type chaîne. Mettre une valeur entre guillemets doubles est l'erreur de débutant la plus courante — le message du validateur est littéralement « Double quotes delimit identifiers in DynamoDB PartiQL, not strings. Use single quotes for string values. »
• 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'existe aucun moteur pour combiner des tables ou replier des lignes. C'est le compromis du single-table design : tu modélises pour tes schémas 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 là-dessus

Les LLM sont entraînés sur des océans de SQL relationnel, donc ils émettent avec assurance JOIN, GROUP BY, LIKE, LIMIT en ligne et des littéraux de chaîne entre guillemets doubles contre DynamoDB — autant de choses que DynamoDB rejette. L'autofix de requêtes par modèle de DynoTable existe précisément parce que les modèles bon marché produisent ces motifs de façon fiable : il supprime les guillemets doublement échappés, réécrit LIKE '%x%' → contains, IS NULL → attribute_not_exists, et remonte le LIMIT en ligne 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 révélateur.

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 Workbench SQL de DynoTable : les requêtes que PartiQL ne peut pas exécuter

Quand tu as vraiment besoin d'un JOIN ou d'un GROUP BY, le Workbench SQL de DynoTable est la réponse. Il valide le côté cible de chaque JOIN contre une clé de partition, matérialise les lignes jointes à travers le véritable moteur Query/Scan de DynamoDB, puis exécute ton SQL complet (agrégats, GROUP BY, DISTINCT, CASE, CAST) par-dessus — du SQL dans les règles 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 par 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 les 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 le bon FilterExpression / KeyConditionExpression sans la surface PartiQL du tout. Pour du PartiQL bien fait, consulte les exemples PartiQL détaillés ; pour estimer ce que va coûter 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 comment le Workbench se positionne face à une GUI DynamoDB classique ou à Dynobase.

FAQ

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

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

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

Pourquoi mon SELECT * coûte-t-il autant ? Sans clé de partition dans le WHERE, PartiQL exécute un Scan de toute la table et facture la lecture de chaque item 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 dans PartiQL ? Des guillemets simples pour les valeurs de type chaîne ('CUSTOMER#42'), des guillemets doubles pour les identifiants comme les noms de tables et d'attributs ("AppData"). Mettre une valeur entre 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.