Le GUI DynamoDB avec du vrai SQL et de l’IA
Un client de bureau rapide et local-first pour AWS DynamoDB. Un agent IA sur tes propres clés Bedrock, des jointures visuelles et du vrai SQL avec agrégations — le tout sur ta machine, en parlant directement à AWS, jamais via nos serveurs.
Le SQL dans le cadre des règles d’access-pattern de DynamoDB.
Tout s’exécute sur tes propres identifiants AWS
Pose n’importe quelle question à tes tables.
Un agent qui lit ton schema, exécute des Query et rédige des écritures — propulsé par Amazon Bedrock via tes identifiants AWS. Aucun service tiers ne voit jamais tes données.
Ton Bedrock, tes clés
Le modèle s’exécute dans ton compte. Les prompts, le schema et les lignes ne quittent jamais ton périmètre AWS.
Lit le vrai schema
Il inspecte d’abord les clés, les GSI et la forme des items — puis choisit Query plutôt que Scan quand il le peut.
Des brouillons que tu approuves
Les écritures sont présentées sous forme de diff vérifiable. Rien n’est commité sans ton accord.
Des jointures pour une base de données qui n’en a pas.
Trace des relations entre les tables sur un canevas et travaille la vue jointe en direct pendant que tu édites — aucune migration de schema, aucun ETL.
Recalcul en direct
Ajoute ou supprime une arête et la grille jointe se recalcule instantanément pendant que tu édites.
Par PK ou GSI
Joins sur la clé primaire ou sur n’importe quel index secondaire global — DynoTable choisit la lecture la moins coûteuse.
Lecture seule par défaut
Les tables de base ne sont jamais modifiées. La vue est une projection que tu peux exporter ou interroger.
Du vrai SQL. GROUP BY, COUNT, jointures.
Écris un SELECT complet avec agrégations et jointures multi-tables sur tes données DynamoDB en direct — les lignes reviennent en quelques millisecondes.
Des agrégations que DynamoDB ne peut pas faire
SUM, AVG, COUNT DISTINCT, HAVING — le SQL que tu utilises, sur un stockage NoSQL.
Seulement ce que tu interroges
Seules les lignes touchées par ta requête sont lues — jamais toute la table.
S’intègre dans la grille
Les résultats utilisent la même grille de données que partout ailleurs — trie, filtre et ouvre n’importe quelle ligne.
Ton agent préféré, tes données.
Connecte Claude Code, Cursor ou Codex à DynoTable via MCP. L’agent lit ton schema et travaille tes tables au travers d’une connexion dont tu définis la portée et que tu approuves — les écritures atterrissent toujours en staging pour ta revue.
N’importe quel client MCP
Claude Code, Cursor, Codex — connecte-toi via le MCP standard avec OAuth, une connexion par profil.
Tu approuves la connexion
Chaque agent obtient la portée que tu choisis — lecture seule, lecture + staging, ou complète — et uniquement les profils que tu exposes.
Les agents proposent, tu commites
Les agents externes n’écrivent jamais directement. Les changements atterrissent en staging sous forme de diff vérifiable — c’est toi qui commites.
Fait ce que la Console AWS ne sait pas faire. Plus léger que les clients cloud.
| DynoTable | AWS Console | Clients cloud | |
|---|---|---|---|
| Agent IA sur tes propres identifiants | Oui | — | tiers |
| Jointures visuelles et vrai SQL | Oui | — | partiel |
| Tout au clavier, ⌘K partout | Oui | — | variable |
| Les données restent sur ton appareil | Oui | dans le navigateur | synchronisé sur le cloud |
| Exports à mémoire constante (1M+ lignes) | Oui | — | variable |
Des réponses claires.
En quoi est-ce différent de Dynobase ou des clients cloud ?
Trois choses : un SQL Workbench qui exécute de vraies jointures, des GROUP BY et des agrégations sur tes tables, un agent IA qui s’exécute sur ton propre AWS Bedrock, et une conception local-first — tes données et tes identifiants ne quittent jamais ta machine, là où les clients cloud les font transiter par leurs serveurs.
L’IA envoie-t-elle mes données à un tiers ?
Non. L’agent s’exécute sur Amazon Bedrock via tes propres identifiants AWS — les prompts, le schema et les lignes des tables ne quittent jamais ton compte AWS. Aucun serveur DynoTable n’intervient.
Est-ce sûr de l’utiliser sur mes tables de production ?
Oui. DynoTable utilise tes propres identifiants AWS, il ne peut donc faire que ce que ta policy IAM autorise — donne-lui un rôle en lecture seule et il ne peut rien modifier. Et les modifications n’atteignent jamais tes tables directement : chaque changement s’accumule dans une fenêtre de staging que tu examines avant de valider.
Puis-je utiliser Claude Code ou Cursor avec mes tables ?
Oui. DynoTable exécute un serveur MCP local auquel les agents externes se connectent — désactivé par défaut et approuvé par connexion. L’agent n’écrit jamais directement dans DynamoDB : chaque changement atterrit dans ta fenêtre de validation en staging pour être examiné et validé, et tes identifiants AWS ne quittent jamais ta machine.
Comment les jointures et le SQL fonctionnent-ils sans surcharger DynamoDB ?
DynoTable ne lit que les lignes touchées par une requête et exécute les jointures et agrégations sur ta machine — jamais contre DynamoDB. Tes tables sont lues avec le mode d’accès le moins coûteux disponible — Query plutôt que Scan dès qu’une clé ou un index le permet.
Fonctionne-t-il hors ligne ou avec DynamoDB Local ?
Oui. Pointe un Profil vers un endpoint local (par ex. DynamoDB Local sur le port 8000/9000) et travaille entièrement hors ligne. Les Profils peuvent être en ligne ou hors ligne, chacun avec sa propre région et sa propre couleur.
DynoTable est-il gratuit ?
Les outils web — les calculateurs et le builder d’expressions — sont gratuits, sans inscription. L’application de bureau propose un essai gratuit de 30 jours, puis un tarif par siège, facturé mensuellement ou annuellement.
Quelles plateformes sont prises en charge ?
macOS, Windows et Linux — tous disponibles dès aujourd’hui. macOS est livré en build Apple Silicon, Windows en installateur x64, et Linux en paquets .deb et .rpm.
Arrête de te battre avec la Console.
Télécharge DynoTable, pointe-le vers un profil et exécute ta première requête en moins d’une minute.
Essai gratuit de 30 jours · Garantie satisfait ou remboursé · macOS, Windows & Linux