Two index types. Two completely different storage models. One of them you can never add after the table exists.
That’s the DynamoDB index decision nobody warns you about until migration day.
Here’s the real cost of each. Forget the textbook version.
LOCAL SECONDARY INDEX (LSI)
↳ Same partition key as your base table, different sort key
↳ Supports strongly consistent reads
↳ Shares throughput with the base table. No separate capacity to manage.
↳ Must be created at table creation time. Miss this window? You’re recreating the entire table.
↳ Hard 10 GB limit per partition key value (table items + all LSI items combined)
↳ Max 5 per table
↳ Cannot be deleted once created
That 10 GB limit is the silent killer. Your table grows, your partition key accumulates data, and one day writes start failing with ItemCollectionSizeLimitExceededException. No warning. No gradual degradation. Just rejected writes.
GLOBAL SECONDARY INDEX (GSI)
↳ Completely different partition key AND sort key. Query across the entire table.
↳ Has its own provisioned throughput (separate RCUs and WCUs)
↳ Can be added or removed anytime, even on a live production table
↳ Eventually consistent reads ONLY. No strong consistency option.
↳ Max 20 per table
↳ No item collection size limit
↳ If GSI write capacity is throttled, the base table throttles too (back pressure)
That last point catches teams off guard. You provision 1,000 WCUs on your table but only 100 on the GSI. Under heavy write load, the GSI becomes the bottleneck and your entire table starts throwing throttle errors.
THE DECISION FRAMEWORK
Use LSI when:
→ You need strongly consistent reads on an alternative sort key
→ Your partition key values will stay well under 10 GB forever
→ You know ALL your access patterns before table creation
Use GSI when:
→ You need to query across different partition keys entirely
→ Access patterns might evolve after launch
→ You want independent throughput control
→ Eventual consistency is acceptable
The uncomfortable truth? AWS themselves recommend GSIs over LSIs in almost every case. The official best practice guide says “Global secondary indexes are often more useful than local secondary indexes.”
LSI gives you strong consistency but locks you into decisions you made on day one. GSI gives you flexibility but forces you to design around eventual consistency.
Pick the wrong one and you’re either recreating tables or redesigning your read model.
#SystemDesign #AWS #DynamoDB #BackendEngineering #DistributedSystems

You can share you thought with this squad 

Backend Developer 

A practical breakdown of DynamoDB's two index types — Local Secondary Index (LSI) and Global Secondary Index (GSI) — covering their key differences, hidden pitfalls, and when to use each. LSIs must be created at table creation time, support strongly consistent reads, but have a hard 10 GB per-partition limit that can silently cause write failures. GSIs can be added anytime and have no size limit, but only support eventual consistency and can throttle the base table if their write capacity is under-provisioned. AWS itself recommends GSIs in most cases. A decision framework is provided to guide the choice based on access patterns, consistency requirements, and data growth expectations.

DynamoDB Indexes GSI VS LSI