GSI vs LSI in DynamoDB
Both a Global Secondary Index (GSI) and a Local Secondary Index (LSI) let you
Query by an attribute that isn't your table's key. They are not
interchangeable — the differences decide which one a pattern needs.
The differences that matter
| GSI | LSI | |
|---|---|---|
| Partition key | Any attribute | Same as the table |
| Sort key | Any attribute | Any attribute |
| When created | Anytime | Table-creation only |
| Consistency | Eventual only | Strong available |
| Capacity | Its own | Shares the table's |
| Write propagation | Async (eventual) | Synchronous (atomic) |
| Max per table | 20 (default, raisable) | 5 (hard) |
| 10 GB partition cap | No | Yes (per PK) |
A rule of thumb
- Need a different (e.g. look up orders by
statusinstead ofcustomer)? You need a GSI — an LSI can't repartition. - Need a second sort order within the same partition — an LSI keeps the table's exact partition key and only swaps in a different sort key — decided up front, with reads? An LSI fits.
The choice collapses to one question — which key are you changing:
Different partition key forces a GSI; a different sort key on the same partition is the only case an LSI fits.
In practice most teams reach for GSIs almost exclusively: they're addable later, independently scaled, and not subject to the 10 GB per-partition limit. Overload a single GSI's keys to serve several patterns — see single-table design.
If you're adding a GSI to kill a Scan, remember it has its own read/write capacity. Size that extra cost with the pricing calculator, and try DynoTable to inspect an index's projected attributes before you commit to it.