GSI vs LSI en DynamoDB
Tanto un Global Secondary Index (GSI) como un Local Secondary Index (LSI) te
permiten hacer un Query por un atributo que no es la clave de tu tabla. No son
intercambiables —las diferencias deciden cuál necesita un patrón.
Las diferencias que importan
| GSI | LSI | |
|---|---|---|
| Clave de partición | Cualquier atributo | La misma que la tabla |
| Clave de ordenación | Cualquier atributo | Cualquier atributo |
| Cuándo se crea | En cualquier momento | Solo al crear la tabla |
| Consistencia | Solo eventual | Fuerte disponible |
| Capacidad | La suya propia | Comparte la de la tabla |
| Propagación de escritura | Asíncrona (eventual) | Síncrona (atómica) |
| Máximo por tabla | 20 (por defecto, ampliable) | 5 (estricto) |
| Límite de partición de 10 GB | No | Sí (por PK) |
Una regla práctica
- ¿Necesitas una clave de partición diferente (p. ej. buscar pedidos por
statusen lugar de porcustomer)? Necesitas un GSI —un LSI no puede reparticionar. - ¿Necesitas un segundo orden de ordenación dentro de la misma partición —un LSI conserva exactamente la clave de partición de la tabla y solo cambia la clave de ordenación— decidido de antemano, con lecturas de consistencia fuerte? Un LSI encaja.
La elección se reduce a una pregunta: ¿qué clave estás cambiando?
Una clave de partición diferente obliga a un GSI; una clave de ordenación diferente en la misma partición es el único caso en el que encaja un LSI.
En la práctica, la mayoría de los equipos recurren casi exclusivamente a los GSI: se pueden añadir más tarde, se escalan de forma independiente y no están sujetos al límite de 10 GB por partición. Sobrecarga las claves de un único GSI para servir varios patrones —consulta diseño de tabla única.
Si estás añadiendo un GSI para eliminar un Scan, recuerda que tiene su propia capacidad de lectura/escritura. Dimensiona ese coste extra con la calculadora de precios, y prueba DynoTable para inspeccionar los atributos proyectados de un índice antes de comprometerte con él.