Consistent reads are not supported on global secondary indexes

TL;DR — Pusiste ConsistentRead: true en una Query o Scan que apunta a un índice secundario global. Los GSI se replican desde la tabla base de forma asíncrona y solo sirven lecturas con consistencia eventual — la bandera es un error duro, no una preferencia. Quita la bandera o, si de verdad necesitas consistencia de lectura tras escritura, lee la tabla base (o diseña la clave en un LSI).

Qué significa

ValidationException: Consistent reads are not supported on global secondary indexes

Un GSI es físicamente su propia estructura de índice, con sus propias particiones y capacidad; DynamoDB propaga las escrituras de la tabla base hacia él de forma asíncrona. Como un Item que acabas de escribir puede no haber llegado todavía al índice, DynamoDB no puede atender una lectura con consistencia fuerte contra él — así que ConsistentRead: true combinado con un IndexName de un GSI se rechaza de plano. La documentación de AWS es explícita: consulta un GSI con ConsistentRead en true y recibes una ValidationException.

Los índices secundarios locales son distintos: un LSI comparte su partición con la tabla base, así que ahí sí se admite ConsistentRead: true.

Por qué ocurre

• La bandera se puso de forma global — un ayudante de consulta compartido o un envoltorio del cliente pone por defecto ConsistentRead: true en cada lectura, y una de las rutas de llamada añade un IndexName que apunta a un GSI.
• Un LSI pasó a ser un GSI — código escrito para un índice local (donde la bandera es legal) se apuntó a uno global.
• Consulta de tabla base copiada y pegada — una consulta que usaba legítimamente consistencia fuerte sobre la tabla se reutilizó añadiendo IndexName.

Cómo solucionarlo

1. Quita ConsistentRead de las lecturas de GSI (o ponlo en false — el valor por defecto):

   await client.send(
     new QueryCommand({
       TableName: 'Orders',
       IndexName: 'status-index',
       KeyConditionExpression: '#s = :open',
       // ConsistentRead: true  ← delete this line for a GSI
       ExpressionAttributeNames: {'#s': 'status'},
       ExpressionAttributeValues: {':open': {S: 'OPEN'}}
     })
   );

2. ¿Necesitas lectura tras escritura? Consulta la tabla base con ConsistentRead: true — posible siempre que la clave que buscas sea la propia clave de partición de la tabla.

3. ¿Misma clave de partición, distinta ordenación? Modélalo como un LSI (se crea al crear la tabla), que sí admite lecturas con consistencia fuerte.

4. O absorbe el retraso en la aplicación — la propagación del GSI suele ser rápida; para los flujos de UI, devolver los datos recién escritos que ya tienes es mejor que releer el índice.

La aplicación de escritorio DynoTable muestra los índices de cada tabla y te deja consultarlos directamente — y como sabe qué índice es global y cuál local, esta clase de error simplemente no aparece.

Errores relacionados

• Un GSI limita la tabla base — el acoplamiento en la escritura de los GSI.
• The table does not have the specified index
• Cannot update GSI while it is being created
• Ejemplo de código: Consultar un GSI en Node.js — una consulta a un GSI con consistencia eventual hecha bien.
• Aprende: Por qué los GSI son de consistencia eventual · GSI vs LSI · Consistencia

Referencias

• Query — Amazon DynamoDB API Reference
• Using Global Secondary Indexes in DynamoDB — Amazon DynamoDB Developer Guide
• Constraints in Amazon DynamoDB — Amazon DynamoDB Developer Guide

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba.