DynamoDB prend-il en charge les index secondaires ?

Oui. DynamoDB prend en charge deux sortes d'index secondaires. Un index secondaire global (GSI) a ses propres clés de partition/tri et sa propre capacité (20 par table par défaut, en cohérence à terme). Un index secondaire local (LSI) partage la clé de partition de la table avec une clé de tri différente, accepte la cohérence forte, et doit être défini à la création de la table.

Index secondaire global (GSI)

Ses propres clés de partition et de tri, indépendantes de celles de la table.
Son propre débit provisionné (ou sa capacité à la demande).
Lectures en cohérence à terme uniquement.
Ajout ou suppression à tout moment ; quota par défaut de 20 par table.

Un GSI, c'est la façon de retrouver des éléments par un attribut extérieur à la clé primaire de la table.

Index secondaire local (LSI)

Partage la clé de partition de la table, avec une clé de tri différente.
Partage le débit de la table.
Accepte les lectures fortement cohérentes.
Doit être créé à la création de la table et ne peut pas être ajouté ensuite.

Les deux différences que tu peux mesurer

Une lecture sur GSI ne se dégrade pas discrètement quand tu demandes la cohérence forte. Elle échoue :

ValidationException: Consistent reads are not supported on global secondary indexes
HTTP 400

La même requête avec ConsistentRead: true sur un LSI réussit, et rapporte ConsumedCapacity 1.0 là où la lecture en cohérence à terme du même élément rapporte 0.5. La cohérence forte est disponible sur un LSI, au prix du double d'unités de lecture.

La seconde différence porte sur les écritures, et c'est celle qui se voit sur la facture. Le même élément de 920 octets écrit dans trois tables qui ne diffèrent que par le nombre de GSI qu'elles portent :

0 GSIs   ConsumedCapacity 1   table 1
1 GSI    ConsumedCapacity 2   table 1, gsi1 1
2 GSIs   ConsumedCapacity 3   table 1, gsi1 1, gsi2 1

Chaque GSI qui projette un attribut modifié est une écriture de plus que tu paies. AWS énonce la règle que les chiffres montrent : le coût d'écriture est "the sum of write capacity units consumed by writing to the base table and those consumed by updating the global secondary indexes". Une projection KEYS_ONLY est la façon de garder cette seconde écriture petite.

Choisir entre les deux

Prends un GSI pour de nouveaux modèles d'accès et pour la souplesse ; prends un LSI quand tu as besoin de cohérence forte sur un tri alternatif à l'intérieur de la même partition.

Aller plus loin

Compare-les dans GSI vs LSI et vois les projections d'index. Télécharge DynoTable pour interroger à travers tes index.

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus ; quotas revérifiés le 2026-07-28.

La chaîne d'erreur et les valeurs de ConsumedCapacity ont été capturées le 2026-07-28 sur DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 et sont la sortie du moteur lui-même.