SQL pour DynamoDB : ce qui marche, ce qui ne marche pas, et le Workbench

DynamoDB est un magasin clé-valeur NoSQL, mais il répond à des questions de forme SQL plus que les gens ne le pensent — et bien moins qu'ils ne l'espèrent. Voici la carte honnête : le SQL-sur-DynamoDB que tu obtiens réellement d'origine, où il s'arrête, et les rares moyens d'exécuter les requêtes JOIN / GROUP BY / agrégat que la surface native ne peut pas exprimer.

Peut-on interroger DynamoDB en SQL ? La réponse courte

En partie. DynamoDB embarque PartiQL, que les docs AWS décrivent comme « un langage de requête compatible SQL, pour sélectionner, insérer, mettre à jour et supprimer des données dans Amazon DynamoDB. » Tu peux donc écrire SELECT * FROM "Orders" WHERE OrderID = 100 et ça marche.

Mais PartiQL est une surface compatible SQL au-dessus de l'API DynamoDB, pas un moteur SQL. Il parle la syntaxe ; il n'ajoute pas de puissance de requête relationnelle. AWS est explicite : « Amazon DynamoDB supporte un sous-ensemble du langage de requête PartiQL » (référence). Dès que tu tends la main vers un JOIN, un GROUP BY, ou COUNT(*), tu es hors de ce que PartiQL peut faire — voir PartiQL vs SQL pour la comparaison complète fonctionnalité par fonctionnalité.

PartiQL : une surface compatible SQL, pas un moteur SQL

PartiQL mappe des instructions au look SQL sur les mêmes opérations du plan de données que le SDK expose. Un SELECT avec une égalité de clé de partition se compile en un Query ; un SELECT sans clé de partition se compile en un Scan. Selon la référence SELECT d'AWS :

L'utilisation de l'instruction SELECT peut entraîner un scan complet de la table si une condition d'égalité ou IN avec une clé de partition n'est pas fournie dans la clause WHERE.

Donc les mêmes règles d'access-pattern qui gouvernent Query et Scan s'appliquent toujours — PartiQL les cache juste derrière une syntaxe familière. Il n'ajoute aucun planificateur de requête, aucune jointure, et aucune agrégation ensembliste. Chaque instruction se réduit à une opération native :

Tu écris	DynamoDB exécute
`SELECT … WHERE PK = …`	`GetItem` ou `Query`
`SELECT …` (sans PK)	`Scan` (lit la table entière)
`INSERT INTO …`	`PutItem`
`UPDATE … WHERE PK=… AND SK=…`	`UpdateItem` (un item)
`DELETE … WHERE PK=… AND SK=…`	`DeleteItem` (un item)

Si une opération ne se réduit pas à un unique Get/Query/Scan/Put/Update/Delete, PartiQL ne peut tout simplement pas l'exprimer. Tout ce qui suit est une conséquence de ce seul fait.

Ce que PartiQL couvre

PartiQL de DynamoDB supporte quatre instructions DML/requête :

SELECT — lire des items (se compile en Query ou Scan)
INSERT — ajouter un item (PutItem)
UPDATE — modifier un item (UpdateItem)
DELETE — supprimer un item (DeleteItem)

Il supporte aussi les transactions et opérations par lot. Une lecture bien formée cible la clé de partition avec une égalité ou un IN :

SELECT OrderID, Total
FROM "Orders"
WHERE OrderID IN [1, 2, 3] ORDER BY OrderID DESC

ORDER BY est autorisé, mais la référence AWS restreint la clé d'ordre à « une clé de hachage ou une clé de tri » — la clé de partition ou de tri, pas des colonnes arbitraires. C'est le plafond de ce que le SELECT de PartiQL accepte. Pour des instructions prêtes au copier-coller, voir les exemples PartiQL.

Ce que PartiQL ne peut pas faire

Voici les choses que les développeurs attendent le plus souvent du « SQL », et que PartiQL ne supporte aucunement :

Pas de JOIN. La syntaxe SELECT de PartiQL est un unique FROM {{table}}[.{{index}}] — une table ou un index, jamais deux tables reliées sur une clé. C'est le compromis du single-table-design : tu modélises pour tes access patterns d'emblée parce que la couche de requête ne peut pas remettre les données en forme après coup.
Pas de GROUP BY. Ce n'est pas dans la grammaire ; il n'y a pas de clause pour grouper des lignes.
Pas de fonctions d'agrégation. La référence des fonctions PartiQL liste exactement une fonction sous « Fonctions d'agrégation » : SIZE, qui renvoie la taille d'un attribut en octets pour un seul item. Il n'y a pas de COUNT, SUM, AVG, MIN, ou MAX à travers les lignes. AWS le dit clairement : « Toute fonction SQL non incluse dans cette liste n'est pas actuellement supportée dans DynamoDB. »
Pas de LIKE, pas de sous-requêtes, pas d'UNION, pas de fonctions de fenêtrage. La recherche de motifs utilise contains / begins_with ; le reste n'a aucun équivalent.

Donc « le chiffre d'affaires total par client le mois dernier » — un GROUP BY d'une ligne dans n'importe quelle base relationnelle — ne peut pas être exprimé en PartiQL. Tu scannerais les données et les agrégerais dans le code applicatif.

Le seul moyen d'obtenir un vrai comportement JOIN / GROUP BY / agrégat sur des données DynamoDB est un outil qui exécute un vrai moteur SQL par-dessus. Il y en a deux : le connecteur fédéré d'Amazon Athena, et le SQL Workbench de DynoTable.

Comment interroger DynamoDB en vrai SQL via Amazon Athena

La propre réponse d'AWS à « du vrai SQL sur DynamoDB » est le connecteur DynamoDB d'Amazon Athena, qui « permet à Amazon Athena de communiquer avec DynamoDB afin que tu puisses interroger tes tables en SQL. » Parce qu'Athena est un moteur SQL complet, cela te donne bien le JOIN et les agrégats — le tutoriel d'AWS s'intitule « Accéder, interroger et joindre des tables Amazon DynamoDB avec Athena. »

Le hic, c'est la mise en place et le coût :

C'est un connecteur fédéré basé sur Lambda que tu déploies dans ton compte (via la console Athena ou le Serverless Application Repository), câblé à travers AWS Glue pour le schéma et déversant les résultats dans un bucket S3 (docs du connecteur).
Sous le capot, il utilise toujours les opérations API Query et Scan de DynamoDB. AWS prévient que « les requêtes qui utilisent des scans peuvent consommer un grand nombre d'unités de capacité de lecture (RCU) », donc une requête analytique sur une grande table lit — et facture — beaucoup d'items (coûts du connecteur). Utilise le calculateur de taille d'item pour estimer ce que coûtera une requête lourde en scan.
Les opérations d'écriture comme INSERT INTO ne sont pas supportées via le connecteur.

Athena est le bon outil pour les analytiques planifiées et les tableaux de bord BI. Il est lourd pour le cas quotidien « j'ai juste besoin de joindre deux tables et de jeter un œil au résultat » — c'est l'écart que comble la section suivante.

SQL Workbench de DynoTable : du SQL dans le cadre des règles d'access-pattern de DynamoDB

Le SQL Workbench de DynoTable exécute du vrai SQL — JOIN, GROUP BY, COUNT/SUM/AVG — contre tes tables DynamoDB en direct depuis un client de bureau, sans Lambda, Glue ou S3 à mettre en place. Il matérialise les lignes à travers le runtime réel Query/Scan de DynamoDB, puis exécute ton SQL complet dans un moteur en mémoire par-dessus :

-- S'exécute dans le Workbench DynoTable (PAS en 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

La partie « dans le cadre des règles d'access-pattern de DynamoDB » compte. Le Workbench ne prétend pas que DynamoDB est Postgres — il lit toujours à travers Query/Scan sous le capot, donc tu restes conscient de ce que coûte chaque requête, et il applique le modèle d'accès de DynamoDB plutôt que de le cacher :

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 de self-joins, 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 les conditions et expressions de clé pour l'API brute — pas une instruction SQL complète — le Expression Builder DynamoDB génère les FilterExpression / KeyConditionExpression corrects sans la surface PartiQL du tout.

Si ton but est un client SQL DynamoDB pour explorer, déboguer et analyser des tables, le Workbench comble cet écart — et le reste de DynoTable est un GUI DynamoDB complet tout autour.

Essaie DynoTable pour exécuter du vrai SQL contre tes propres tables.

FAQ

Peut-on exécuter du SQL sur DynamoDB ? Tu peux exécuter PartiQL, un sous-ensemble compatible SQL (SELECT/INSERT/UPDATE/DELETE par clé). Pour du SQL complet — JOIN, GROUP BY, agrégats — tu as besoin d'un moteur SQL par-dessus : le connecteur DynamoDB d'Amazon Athena, ou le SQL Workbench de DynoTable.

PartiQL de DynamoDB supporte-t-il JOIN ? Non. La syntaxe SELECT de PartiQL a une unique table ou un index dans FROM et aucune grammaire de jointure. Les jointures requièrent un moteur en couche au-dessus de DynamoDB.

PartiQL supporte-t-il GROUP BY ou les agrégats comme COUNT et SUM ? Non. Il n'y a pas de clause GROUP BY, et la seule fonction « d'agrégation » est SIZE (la taille en octets d'un attribut pour un item). COUNT, SUM, AVG, MIN et MAX à travers les lignes ne sont pas supportés.

DynamoDB est-il SQL ou NoSQL ? NoSQL — un magasin clé-valeur et document. PartiQL ajoute un langage de requête compatible SQL par-dessus, mais DynamoDB n'a pas de moteur relationnel, de jointures ni d'agrégats.

PartiQL est-il bon pour les requêtes ad-hoc ? Pour les recherches par clé, oui. Pour les requêtes ad-hoc analytiques (comptages, agrégations, jointures), non — PartiQL ne peut pas les exprimer, et les SELECT sans contrainte deviennent silencieusement des scans complets de table.

Existe-t-il un client SQL DynamoDB qui gère JOIN et GROUP BY ? Oui — le SQL Workbench de DynoTable exécute JOIN/GROUP BY/agrégats contre des tables en direct depuis le bureau, et Amazon Athena le fait via un connecteur fédéré que tu déploies dans ton compte AWS.