DynoTable

Une alternative à dynamodb-admin pour DynamoDB local et en direct

dynamodb-admin est le GUI web gratuit, sous licence MIT, que la plupart des développeurs attrapent quand ils lancent DynamoDB Local ou LocalStack. Tu l'exécutes comme un petit serveur Node (npm install -g dynamodb-admin), tu le pointes sur un endpoint, et tu parcours tes tables locales. Il excelle dans cette unique tâche. Cette page est pour quand tu l'as dépassé — et que tu veux un client qui gère les tables locales et AWS en direct, avec filtrage, modification en ligne et un SQL Workbench. DynoTable est un client DynamoDB de bureau multiplateforme construit autour de ce Workbench.

Ce que dynamodb-admin fait bien

Le README de dynamodb-admin le décrit simplement : un « GUI pour DynamoDB Local, dynalite, localstack etc. » (README). C'est le bon outil quand tu travailles contre un endpoint local :

  • Gratuit et open source (MIT), donc il n'y a rien à acheter ni à licencier (licence).
  • Zéro friction d'installation — npm install -g dynamodb-admin et tu as une UI web sur localhost:8001 (le --port par défaut), pointée par défaut sur http://localhost:8000 (README).
  • Une image Docker — l'image officielle aaronshaf/dynamodb-admin sur Docker Hub se glisse directement dans un docker-compose à côté d'amazon/dynamodb-local. Elle lit les variables d'env HOST, PORT, BASE_PATH et DYNAMO_ENDPOINT (README), donc elle se câble proprement dans une stack de dev conteneurisée.
  • Créer, parcourir et modifier des tables via une interface web simple pendant que tu développes, sans toucher à la console AWS.

Par défaut, elle fixe accessKeyId / secretAccessKey aux valeurs factices key et secret et la région à us-east-1 (README) — ce qui te dit exactement pour quoi elle est faite : la boucle interne de développement local.

dynamodb-admin peut-il se connecter à DynamoDB AWS en direct ?

Techniquement oui — et c'est la chose la plus courante que les gens essaient une fois qu'une UI admin local-only ne suffit plus. Tu surcharges l'endpoint et fournis de vrais identifiants :

# Pointer dynamodb-admin sur une vraie région au lieu de localhost
AWS_REGION=eu-west-1 \
AWS_ACCESS_KEY_ID=AKIA... \
AWS_SECRET_ACCESS_KEY=... \
dynamodb-admin --dynamo-endpoint=https://dynamodb.eu-west-1.amazonaws.com

Ou passe --skip-default-credentials pour qu'il cesse d'injecter les key/secret factices et retombe sur la résolution standard des identifiants du SDK AWS à la place (README).

Ça marche, mais c'est hors du chemin balisé. Les options documentées de dynamodb-admin sont l'endpoint, l'hôte, le port, le base path et un toggle d'identifiants (README) — il n'y a aucun gestionnaire de connexion, aucun sélecteur de profil, aucun SSO. Changer de compte ou de région signifie arrêter le processus Node et le relancer avec des variables d'env différentes. Bien pour un coup d'œil occasionnel à une table de prod ; une friction comme outil quotidien sur plusieurs comptes.

Là où dynamodb-admin s'arrête

La frontière apparaît à mesure que ton travail dépasse une seule table locale :

  • Les tables AWS en direct sont hors du chemin balisé. Comme ci-dessus — tu peux le pointer sur une vraie région, mais il est documenté et configuré par défaut autour de DynamoDB Local, sans connexions enregistrées ni changement de profil.
  • Pas de requêtes relationnelles. Comme tout navigateur visuel, il liste et modifie des items dans une table. Il ne peut pas joindre deux tables, faire un GROUP BY, ou calculer un COUNT / SUM, parce que DynamoDB n'a pas de moteur de requête relationnel en dessous. dynamodb-admin n'en ajoute pas — et PartiQL non plus : sa grammaire SELECT prend un unique FROM table sans JOIN, GROUP BY, ni fonctions d'agrégation (référence SELECT PartiQL d'AWS) (voir PartiQL vs SQL).
  • C'est un onglet de navigateur sur un serveur que tu exécutes. Pas d'app de bureau native, pas de connexions enregistrées entre projets, pas de chaîne d'identifiants intégrée — tu gardes un processus Node (ou un conteneur) en marche et tu ajoutes localhost à tes favoris.

Aucun de ces points n'est un bug. Ce sont les bords d'un outil de dev local délibérément petit. La question est de savoir si ton workflow les a franchis.

Ce que tu gagnes en passant à un client DynamoDB complet

Un client DynamoDB de bureau comble l'écart de deux façons. D'abord, une app pour local et en direct : la même UI se connecte à DynamoDB Local, LocalStack et tes vrais comptes AWS, en lisant ta chaîne d'identifiants AWS standard (profils, SSO, variables d'env) au lieu de relancer un serveur par environnement. Ensuite, une vraie surface de requête par-dessus le parcours — conditions de clé et de filtre, modification en ligne, PartiQL et SQL.

DynoTable se connecte à DynamoDB local et en direct depuis une seule app de bureau, en utilisant les profils AWS et clés d'accès que tu as déjà. Tes données restent dans DynamoDB, donc il n'y a rien à migrer. Par-dessus le parcours et la modification en ligne, sa fonctionnalité phare est le SQL Workbench.

Du SQL dans le cadre des règles d'access-pattern de DynamoDB

Un simple client visuel — dynamodb-admin compris — scanne et filtre une seule table. Il ne peut pas joindre deux tables, grouper des lignes ou agréger, parce que DynamoDB n'expose aucun moteur relationnel — même le SELECT de PartiQL est mono-FROM sans JOIN, GROUP BY, ni agrégats (référence SELECT PartiQL d'AWS). Le SQL Workbench de DynoTable compile le SQL — 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 relationnelle. Si tu as atteint le mur où même PartiQL s'arrête, SQL pour DynamoDB et le guide PartiQL vs SQL expliquent ce qui manque et comment le Workbench le comble.

-- Le genre de requête qu'un navigateur mono-table ne peut pas exprimer :
SELECT u.email, COUNT(o.id) AS orders, SUM(o.total) AS revenue
FROM Users u
JOIN Orders o ON o.userId = u.id
GROUP BY u.email;

Construire ces conditions de clé et de filtre à la main est fastidieux ; le Expression Builder DynamoDB gratuit génère pour toi la KeyConditionExpression / FilterExpression et les maps de noms/valeurs d'attribut — aucune installation requise.

DynoTable fonctionne-t-il avec DynamoDB Local comme dynamodb-admin ?

Oui — DynoTable tourne contre tes endpoints locaux quand tu le veux, donc ce n'est pas un remplaçant « live-only ». Voir se connecter à DynamoDB Local et LocalStack pour la configuration de l'endpoint et des fausses-identifiants. Il couvre la même boucle interne locale que dynamodb-admin, plus les tables en direct et les requêtes qu'il ne peut pas.

Avis honnête : quand dynamodb-admin suffit

Si tu ne fais jamais que parcourir une instance DynamoDB locale pendant le développement, que tu veux quelque chose de gratuit et open source, et que tu n'as jamais besoin de toucher des tables en direct ou de lancer un JOIN, dynamodb-admin est le choix pragmatique — garde-le. DynoTable est une app de bureau payante ; elle mérite sa place quand tu travailles sur des comptes locaux et en direct, que tu veux des connexions enregistrées et ta vraie chaîne d'identifiants AWS, ou que tu as atteint une requête qu'un navigateur mono-table ne peut pas exprimer.

Télécharge DynoTable pour macOS, Windows ou Linux, pointe-le sur le même profil que tu utilises aujourd'hui, et lance une requête que tu ne pouvais pas exprimer avant. Voir tarification pour les plans actuels, et DynoTable en tant que GUI DynamoDB pour la vue d'ensemble.

FAQ

DynoTable est-il une alternative à dynamodb-admin ?

Pour le développement local-only, dynamodb-admin est gratuit et excellent. DynoTable est l'alternative quand tu as aussi besoin de tables AWS en direct, de connexions enregistrées via ta chaîne d'identifiants AWS, et d'un SQL Workbench qui exécute des JOIN, des GROUP BY et des agrégats — rien de tout cela qu'un navigateur local mono-table ne fournit.

dynamodb-admin peut-il se connecter à DynamoDB AWS en direct ?

Techniquement oui — tu surcharges --dynamo-endpoint vers une vraie région et fournis des identifiants (avec --skip-default-credentials et les variables d'env AWS standard (README)). Mais il est construit et configuré par défaut autour de DynamoDB Local, sans gestionnaire de connexion ni changement de profil, donc l'usage en direct est hors du chemin balisé.

Existe-t-il une image Docker dynamodb-admin ?

Oui — aaronshaf/dynamodb-admin est publiée sur Docker Hub et configurée via les variables d'env HOST, PORT, BASE_PATH et DYNAMO_ENDPOINT, donc elle se place à côté d'amazon/dynamodb-local dans un docker-compose (README). DynoTable est une app de bureau, pas un conteneur, donc il n'y a pas d'image à exécuter — il se connecte directement à ton endpoint local ou à ton compte en direct.

DynoTable fonctionne-t-il avec DynamoDB Local comme dynamodb-admin ?

Oui. DynoTable se connecte aux endpoints locaux — DynamoDB Local et LocalStack — ainsi qu'aux comptes AWS en direct, depuis la même app de bureau. Voir le guide de connexion locale.

dynamodb-admin peut-il exécuter du SQL ou joindre des tables ?

Non. dynamodb-admin parcourt et modifie une table à la fois ; il n'a aucune surface SQL, et DynamoDB lui-même n'a aucun moteur relationnel — même le SELECT de PartiQL est mono-FROM sans JOIN, GROUP BY, ni agrégats (référence SELECT PartiQL d'AWS) — donc JOIN, GROUP BY et les agrégats ne sont pas possibles sans un client qui les planifie. Le SQL Workbench de DynoTable les compile vers les opérations réelles Query / Scan de DynamoDB.

En lien

Dernière vérification 2026-06-10. dynamodb-admin est un logiciel open source sous licence MIT de ses auteurs respectifs ; référencé 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.

TéléchargerVoir les tarifs