Le modèle de coût de DynamoDB : pourquoi le SQL peut cacher la facture

Exécuter du vrai SQL sur DynamoDB est puissant — tu obtiens des JOINs, GROUP BY et des clauses WHERE arbitraires sur une base de données qui n'en propose nativement aucun. Mais le SQL a été conçu pour un moteur doté d'un planificateur de requêtes et d'index secondaires sur chaque colonne, et DynamoDB n'a ni l'un ni l'autre. Un SELECT parfaitement légal peut se compiler en Scan de table complet qui lit — et te facture — chaque item de la table.

C'est le double tranchant de l'abstraction SQL : elle fait paraître gratuits des modes d'accès coûteux. Ce guide explique le modèle de coût sous-jacent, pour que la commodité ne se transforme jamais en facture surprise, et montre comment DynoTable fait remonter le coût avant que tu n'exécutes la requête.

Pourquoi le SQL sur DynamoDB coûte-t-il plus qu'il n'y paraît ?

Une base de données relationnelle peut répondre à WHERE status = 'active' efficacement parce qu'elle construit un index pour n'importe quelle colonne que tu interroges. Pas DynamoDB. Elle répond efficacement sur exactement une chose : la clé de partition (éventuellement affinée par une clé de tri ou un index secondaire global). Tout le reste est un Scan.

• Une égalité sur la clé de partition est une Query. DynamoDB saute directement aux items sous cette clé et ne lit que ceux-là. Borné et bon marché.
• Tout le reste est un Scan + Filter. DynamoDB lit chaque item de la table, puis applique ton WHERE comme FilterExpression — après la lecture. Tu es facturé pour tout ce qu'elle a scanné, pas pour la poignée de lignes renvoyées.

Ce dernier point est le piège. Une clause WHERE semble réduire le travail. Sur un attribut hors clé, elle ne réduit que la sortie — le coût de lecture est déjà dépensé.

Query vs Scan : le calcul des RCU

DynamoDB facture les lectures en unités de capacité de lecture (RCU) :

• 1 RCU = une lecture fortement cohérente d'un item jusqu'à 4 KB. Les lectures à cohérence à terme coûtent la moitié d'une unité. Les lectures sont arrondies au supérieur par tranche de 4 KB.
• Une Query ne lit que les items sous une seule clé de partition — le coût dépend des items correspondants, pas de la table.
• Un Scan lit toute la table, 4 KB à la fois. Une table de 1 GB représente environ 262,000 RCU à cohérence à terme pour un seul passage complet — à chaque passage, à chaque fois.

Une FilterExpression ne réduit pas ce nombre. Le filtrage a lieu après la lecture, donc un Scan filtré coûte exactement autant qu'un Scan non filtré. Calcule les vrais chiffres pour tes données avec le calculateur de taille d'item et le calculateur de tarifs.

Quelles constructions SQL se transforment discrètement en Scans ?

• WHERE sans égalité sur la clé de partition → un Scan complet avec un filtre après lecture.
• JOIN → il n'y a pas de jointure côté serveur dans DynamoDB. Chaque table jointe est récupérée séparément et assemblée côté client — un mode d'accès N+1, une requête par ligne jointe.
• COUNT, SUM, GROUP BY, agrégations → aucune agrégation côté serveur n'existe, donc chaque item correspondant est lu. Sur un Scan, cela signifie lire la table entière.
• ORDER BY ou DISTINCT sur un attribut hors clé → le tri et la déduplication ont lieu côté client sur tout ce qui a été scanné.

Aucune de ces opérations n'est mauvaise à exécuter — parfois un Scan est exactement ce que tu veux. Le but est de savoir quand tu en exécutes un.

Comment garder le SQL honnête sur le coût ?

• Conçois tes clés autour de tes modes d'accès. La requête la moins coûteuse est celle à laquelle ton schéma de clés répond déjà. Planifie-la avec l'outil de single-table design et le guide Query vs Scan.
• Mets une égalité sur la clé de partition dans le WHERE pour obtenir une Query au lieu d'un Scan.
• Ajoute un GSI pour un second mode d'accès plutôt que de scanner-et-filtrer.
• Lis le coût avant d'exécuter. Le Workbench de DynoTable compile ton SQL vers l'opération DynamoDB réelle et affiche le plan — Scan vs Query, quel index il utilise, la condition de clé vs le filtre après Scan, et un coût RCU estimé — puis signale les Scans complets et les jointures N+1 en ligne. C'est le EXPLAIN que DynamoDB n'a jamais livré. Vois aussi pourquoi les Scans sont lents et coûteux et capacité On-Demand vs Provisionnée.

Le SQL de DynoTable aggrave-t-il le problème de coût ?

Non — parce qu'il rend le coût visible. La critique du SQL-sur-DynamoDB est juste : une abstraction qui cache les Scans te laisse te tirer une balle dans le pied. La réponse de DynoTable n'est pas de retirer le SQL, mais de placer une radiographie du coût derrière lui. Chaque requête dans le Workbench prévisualise sa vraie forme DynamoDB avant de s'exécuter, si bien que tu conserves l'ergonomie du SQL et l'honnêteté sur les RCU et la conception des clés que le modèle natif t'offre.

Ai-je besoin de l'agent IA pour tout cela ?

Non — le visualiseur de tables, le SQL Workbench et l'aperçu du coût fonctionnent tous pleinement sans lui. L'agent IA est l'une des fonctionnalités phares de DynoTable — un agent de code natif DynamoDB qui écrit des requêtes adaptées au schema, transforme les données, et plus encore — et il est là dès que tu le veux. Il s'exécute sur ton propre AWS Bedrock, donc tu paies AWS directement au prix coûtant (sans marge), et tes données ne quittent jamais ton compte. Active-le quand ça aide ; le client de base est complet dans tous les cas.

Mon travail est-il portable ?

Oui. DynoTable parle des standards, pas un jardin clos : du SQL standard, des identifiants AWS et du SSO standard, l'export CSV/JSON, l'export de schema déduit vers TypeScript, JSON-Schema ou Zod, et un serveur MCP pour que tes propres outils et agents puissent se connecter. Tes requêtes, configs et schemas s'exportent proprement — rien n'est verrouillé.

Essaie-le

Télécharge DynoTable et ouvre le SQL Workbench sur ta propre table — l'aperçu du coût te montre ce que chaque requête coûte vraiment avant que tu ne l'exécutes.