DynamoDB prend-il en charge SQL ?

En partie. DynamoDB prend en charge PartiQL, un langage de requête compatible SQL pour les instructions SELECT, INSERT, UPDATE et DELETE. Ce n'est pas du SQL complet : il n'y a pas de JOIN, pas de GROUP BY, pas d'agrégations arbitraires, et les requêtes efficaces exigent toujours de cibler la clé primaire ou un index. Si tu veux ces pièces manquantes, le SQL Workbench de DynoTable exécute de vraies requêtes JOIN, GROUP BY et d'agrégation sur tes tables DynamoDB, depuis le bureau.

Ce que PartiQL t'apporte

Une syntaxe SQL familière pour les quatre opérations de données. Tu peux écrire SELECT * FROM "Orders" WHERE ... au lieu de construire des appels d'API bas niveau, ce qui est pratique et lisible.

Ce qu'il ne t'apporte pas

Pas de JOIN — DynamoDB est non relationnel ; tu dénormalises à la place.
Pas de GROUP BY / agrégats — le regroupement et les sommes se font dans ton application.
Pas de scans libres à bas prix — un SELECT sans condition de clé exécute quand même un Scan et coûte en conséquence.

Là où l'analyseur s'arrête

Ce ne sont pas des fonctionnalités que tu peux atteindre avec une autre syntaxe. Lance-les et l'instruction ne va même pas jusqu'à lire un élément :

SELECT "region", SUM("total") FROM "Orders" GROUP BY "region"
  ValidationException: Unsupported clause: GROUP BY

SELECT COUNT(*) FROM "Orders"
  ValidationException: Unexpected path component at 1:8:5

SELECT SUM("total") FROM "Orders"
  ValidationException: Unexpected path component at 1:8:3

SELECT DISTINCT "region" FROM "Orders"
  ValidationException: Unsupported token in expression: DISTINCT

Regarde ce que disent les erreurs sur les agrégats. Il n'y a aucune fonction d'agrégation que l'analyseur puisse refuser, donc COUNT(*) est lu comme un chemin d'attribut et se casse la figure sur le *, à la colonne 8. Voilà à quel point la surface SQL est mince.

ORDER BY est celui à connaître, parce qu'il donne l'impression de fonctionner :

SELECT * FROM "Orders" WHERE "pk" = 'U#1' ORDER BY "total"
  ValidationException: Variable reference total in ORDER BY clause must be part of the primary key

Tu peux trier par la clé de tri, en ordre croissant ou décroissant, et par rien d'autre. Trier sur n'importe quel autre attribut est le travail de ton application, après la lecture.

Le modèle mental

Vois PartiQL comme une couche de syntaxe au-dessus des opérations Query, Scan et d'écriture existantes de DynamoDB ; les mêmes règles d'access-pattern s'appliquent en dessous.

Du vrai SQL (JOIN, GROUP BY, agrégats) avec DynoTable

PartiQL s'arrête au SELECT mono-table. Le SQL Workbench de DynoTable va plus loin : il exécute de véritables JOIN, GROUP BY et fonctions d'agrégation (COUNT, SUM, AVG, MIN, MAX) sur tes tables DynamoDB. Il lit les éléments par l'API DynamoDB normale, puis exécute la partie relationnelle de la requête sur le client : du SQL dans le cadre des règles d'access-pattern de DynamoDB, puisque chaque jointure lit toujours par une vraie clé ou un vrai index. Les trois choses que PartiQL ne sait pas faire, tu les écris donc en une seule instruction :

SELECT   c.region, COUNT(*) AS orders, SUM(o.total) AS revenue
FROM     Orders o
JOIN     Customers c ON o.customerId = c.id
GROUP BY c.region

Il reste honnête sur les contraintes sous-jacentes (une jointure non bornée est une lecture non bornée) : les requêtes les plus rapides sont donc celles dont la jointure ou le WHERE tombe sur une clé de partition ou un index. Tout le détail dans SQL pour DynamoDB et dans le manuel produit, à /docs/dynamodb-sql-workbench.

Prototype le versant PartiQL du même modèle de données avec le query builder DynamoDB — il émet des programmes Query délimités à une partition, qui restent sur le chemin efficace qu'emprunte un SELECT PartiQL quand une condition de clé est présente.

Aller plus loin

Compare les deux dans PartiQL vs SQL, vois les exemples PartiQL, et lis SQL pour DynamoDB. Télécharge DynoTable pour écrire du PartiQL, et de vrais JOIN, GROUP BY et agrégats, sur tes tables.

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.

Chaque ValidationException ci-dessus a été reproduite le 2026-07-28 contre DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 et est citée telle quelle, décalages de colonne compris.