Une meilleure alternative à la console DynamoDB AWS

La console DynamoDB AWS te donne une liste de tables et un navigateur d'items basique. Dès l'instant où tu dois filtrer une grande table, parcourir les résultats, exporter plus d'une page, ou exécuter quoi que ce soit ressemblant à un agrégat, elle se met en travers. DynoTable est un client DynamoDB de bureau construit autour d'un SQL Workbench qui exécute des JOIN, GROUP BY et agrégats dans le cadre des règles d'access-pattern de DynamoDB — les requêtes que l'éditeur PartiQL de la console ne peut pas exprimer. Cette page est un regard factuel et daté sur ce que la console ne peut pas faire et ce qu'un client dédié ajoute. DynoTable lit ta chaîne d'identifiants AWS standard et pointe sur les mêmes tables de ton compte, donc il n'y a rien à migrer.

FonctionnalitéDynoTableAWS DynamoDB Console
SQL JOINs, GROUP BY & aggregatesOuiNon
Aggregate functions (COUNT / SUM / AVG)OuiSIZE only
Filter without billing the full scanSame Query/Scan opsPost-scan filter
Export full result to CSVOuiOne page at a time
Auto-paginating result gridOuiManual, 1 MB at a time
Multiple tabs & saved queriesOuiNon
InstallDesktop appNone
PricingPaidFree

Ce qui manque à la console AWS

Le navigateur d'items de la console est une fine enveloppe sur l'API DynamoDB, il hérite donc des aspérités de l'API sans en lisser aucune :

  • Le filtrage est post-scan, pas une vraie requête. Une expression de filtre « est appliquée après la fin d'un Scan mais avant que les résultats ne soient renvoyés », donc un Scan « consomme la même quantité de capacité de lecture, qu'une expression de filtre soit présente ou non » (docs AWS). Tu paies pour lire toute la page, puis la majeure partie est jetée. Le guide query vs scan explique pourquoi ça compte pour le coût.
  • La pagination est manuelle, 1 Mo à la fois. « Une seule requête Scan peut récupérer un maximum de 1 Mo de données », et « l'absence de LastEvaluatedKey est le seul moyen de savoir que tu as atteint la fin du jeu de résultats » (docs AWS). Dans la console, cela signifie cliquer page après page pour parcourir une table — voir le guide de pagination pour comprendre comment fonctionne le curseur sous le capot.
  • L'export CSV se fait une page à la fois. La propre documentation d'export CSV d'AWS le dit clairement : « tu peux exporter les résultats une page à la fois vers un fichier CSV. S'il y a plusieurs pages de résultats, tu dois exporter chaque page individuellement » (docs AWS). Cette page documente l'Operation Builder de NoSQL Workbench ; la vue « Explore items » de la console web exporte la page affichée de la même façon — un export complet signifie paginer et télécharger à la main.
  • Pas d'agrégation. PartiQL pour DynamoDB liste exactement une fonction d'agrégation — SIZE — et note que « toute fonction SQL non incluse dans cette liste n'est actuellement pas supportée » (docs AWS). Il n'y a pas de COUNT, SUM ou AVG dans l'éditeur de la console.

Limites de la console que les devs rencontrent au quotidien

TâcheConsole DynamoDB AWSDynoTable
Filtrer une grande tableFiltre appliqué après le scan ; la lecture complète reste facturée (docs)Constructeur visuel de filtres/conditions de clé sur les mêmes ops Query/Scan
Parcourir les résultatsManuel, 1 Mo / LastEvaluatedKey à la fois (docs)Grille de résultats à scroll continu qui récupère les pages pour toi
Exporter en CSVPage par page : NoSQL Workbench exporte « chaque page individuellement » (docs AWS) ; l'export Explore-items de la console ne couvre que la page à l'écranExporte les résultats query/scan sans cliquer page par page
COUNT / SUM / AVGNon supporté — seulement SIZE (docs)GROUP BY + agrégats dans le SQL Workbench
Joindre deux tablesNon supporté — le SELECT de PartiQL est mono-table (docs)INNER/LEFT JOIN planifiés vers de vraies ops Query/Scan

Peut-on interroger DynamoDB en SQL dans la console ?

Seulement le sous-ensemble au goût SQL que PartiQL expose. La console a un éditeur PartiQL intégré (dans le volet de navigation gauche) qui exécute des instructions PartiQL (docs AWS), et la grammaire SELECT de PartiQL est délibérément étroite :

SELECT expression [, ...]
FROM table[.index]
[ WHERE condition ]
[ ORDER BY key [DESC|ASC], ... ]

(docs AWS.) Une table, un WHERE optionnel, un ordre optionnel — pas de JOIN, pas de GROUP BY, pas d'agrégat au-delà de SIZE. Cela expose fidèlement le modèle d'accès mono-table de DynamoDB, mais ça signifie que les questions analytiques sont hors-jeu dans la console. Le guide PartiQL vs SQL parcourt exactement où la grammaire s'arrête, et le guide d'exemples PartiQL a des instructions à copier-coller pour ce qu'elle peut faire.

Le SQL Workbench de DynoTable compile un SQL plus riche — INNER/LEFT JOIN, GROUP BY, COUNT, SUM et compagnie — vers les opérations réelles Query/Scan de DynamoDB sur le client. Tu écris du SQL de forme relationnelle ; DynoTable le planifie contre tes clés et GSI, donc il reste dans le cadre des règles d'access-pattern de DynamoDB plutôt que de prétendre que la table est une base de données relationnelle. Si tu as atteint le mur où l'éditeur PartiQL de la console s'arrête, le guide SQL pour DynamoDB explique ce qui marche et ce qui ne marche pas, le guide DynamoDB JOIN montre comment le Workbench joint deux tables, et le guide GROUP BY couvre l'agrégation sans clause GROUP BY.

Comment exporter une table DynamoDB en CSV sans cliquer page par page

L'export CSV natif d'AWS se fait page par page. Pour l'Operation Builder de NoSQL Workbench, les docs sont explicites : tu « peux exporter les résultats une page à la fois vers un fichier CSV » et « dois exporter chaque page individuellement » (docs AWS). La vue Explore items de la console web est orientée page de la même façon — elle scanne une page de résultats à la fois et tu exportes les lignes devant toi — donc un export complet d'une grande table signifie toujours filtrer, paginer et télécharger à la main. Un client dédié exporte le jeu de résultats entier d'une requête ou d'un scan d'un seul coup, vues filtrées comprises. Les options plus longues — AWS CLI, export S3, scripts — sont couvertes dans le guide d'export DynamoDB vers CSV. Un piège qu'il vaut mieux connaître d'emblée : l'API bas niveau de DynamoDB utilise des descripteurs de type (S, N, B, BOOL, …) comme tokens indiquant à DynamoDB comment interpréter chaque attribut (docs AWS), donc un dump CSV naïf de JSON DynamoDB laisse fuiter les enveloppes {"S": "..."} à moins que l'outil ne les aplatisse (le guide des types de données explique les tags de type).

Ce qu'un client dédié ajoute

Au-delà de corriger les aspérités ci-dessus, un client de bureau conçu pour DynamoDB ajoute les conforts de workflow que la console n'a jamais eus : plusieurs onglets pour garder plusieurs tables et requêtes ouvertes à la fois, la modification en ligne d'items dans la grille de résultats au lieu de faire des allers-retours via un éditeur JSON, et les requêtes enregistrées pour que les conditions de filtre et de clé que tu reconstruis chaque jour restent. Rien de tout cela ne nécessite de déplacer tes données — DynoTable lit ta chaîne d'identifiants AWS standard et parle aux mêmes tables de ton compte, y compris DynamoDB Local pour le travail hors ligne (voir le guide DynamoDB Local).

Quand la console suffit (et quand non)

La console est vraiment très bien pour les petits travaux occasionnels : examiner une poignée d'items, un GetItem ponctuel, créer une table, ou vérifier un réglage. Si tu ouvres DynamoDB une fois par semaine et ne dépasses jamais le premier écran, tu n'as besoin de rien d'autre.

Ça commence à faire mal dès que ton travail est répétitif ou analytique — parcourir des milliers d'items, filtrer une grande table sans brûler de capacité de lecture, exporter un jeu de résultats complet, ou répondre à une question « combien / quel est le total ». C'est là qu'un client dédié, et spécifiquement le SQL Workbench, se rentabilise.

Télécharge DynoTable pour macOS, Windows ou Linux, pointe-le sur le même profil et la même région que tu utilises dans la console, et lance un JOIN ou un GROUP BY que tu ne pouvais pas exprimer avant. Voir tarification pour les plans actuels.

FAQ

Existe-t-il une meilleure alternative à la console DynamoDB AWS ?

Oui. DynoTable est un client DynamoDB de bureau qui corrige les points faibles de la console — pagination manuelle, filtrage post-scan et export CSV une page à la fois — et ajoute un SQL Workbench qui exécute des JOIN, GROUP BY et agrégats que l'éditeur PartiQL de la console ne peut pas exprimer.

Pourquoi la console DynamoDB ne peut-elle pas exécuter JOIN ou GROUP BY ?

La console interroge avec PartiQL, dont la grammaire SELECT est mono-table avec un WHERE et un ORDER BY optionnels, et la seule fonction d'agrégation qu'elle supporte est SIZE (docs AWS). Le SQL Workbench de DynoTable planifie ces requêtes sur le client, en les compilant vers les opérations réelles Query/Scan de DynamoDB.

Dois-je migrer mes données pour utiliser une alternative à la console ?

Non. DynoTable lit ta chaîne d'identifiants AWS standard et pointe sur les mêmes régions et tables — tes données restent dans DynamoDB, donc il n'y a rien à migrer.

En lien

Dernière vérification 2026-06-10. AWS, DynamoDB et la console AWS sont des marques d'Amazon Web Services ; référencées ici à des fins d'identification uniquement.

Travaille avec DynamoDB sans la Console

DynoTable est un client de bureau rapide pour DynamoDB — parcours les tables, exécute des requêtes de style SQL et édite les items en local.