Quick Decision Matrix
| Requirement | Use LSI | Use GSI |
|---|---|---|
| Need strong consistency | Yes | No (eventual only) |
| Different partition key than base table | No | Yes |
| Add index after table creation | No | Yes |
| Items > 10 GB per partition key | No | Yes |
| Independent capacity provisioning | No | Yes |
| Cost optimization through separate scaling | No | Yes |
When to Use LSI
Use LSI only when:
- You absolutely need strong consistency for alternate sort key queries
- You’re creating the table from scratch (can’t add LSI later)
- Your partition key values stay under 10 GB
LSI Advantages:
- Strong consistency support
- Automatic fetching of non-projected attributes (with extra RCU cost)
LSI Limitations:
- Must use same partition key as base table
- Must be created at table creation time
- 10 GB limit per partition key value
- Shares capacity pool with base table (less flexibility)
When to Use GSI
Use GSI for almost everything else:
- Need different partition key (most common use case)
- Want to add/remove indexes on existing tables
- Need independent capacity provisioning and scaling
- Want cost optimization through sparse indexes
- Have high-volume write patterns requiring separate index scaling
GSI Advantages:
- Complete flexibility: any partition key, any sort key
- Add/delete anytime without downtime
- Independent capacity provisioning per index
- No size limits per partition
- Better cost control through selective projections and right-sizing capacity
GSI Limitations:
- Eventual consistency only
- Separate provisioned capacity = more complexity to manage
Recommendation
Default to GSI unless you specifically need strong consistency.
LSIs are a legacy feature that made more sense before GSIs supported flexible capacity modes. The flexibility, independent scaling, and ability to add indexes post-creation make GSIs the better choice for 95% of use cases.
The only compelling reason to use LSI today: Strong consistency for alternate sort key queries.