What is the Difference Between DynamoDB GSI and LSI?
DynamoDB provides two types of secondary indexes—Global Secondary Indexes (GSIs) and Local Secondary Indexes (LSIs)—to allow flexible querying on non-key attributes. The fundamental difference lies in their partition key structure and scope: an LSI shares the same partition key as the parent table and is scoped to a single partition, whereas a GSI uses a different partition key and spans across all partitions in the table. Choosing the right index depends on your application's query requirements, performance needs, and data scale.
Core Conceptual Differences
Understanding how DynamoDB distributes and indexes data is essential for choosing between GSIs and LSIs.
- Key Schema Flexibility: An LSI must keep the exact same partition key as the underlying table, allowing you to choose a alternate sort key. A GSI allows you to define an entirely new partition key as well as an optional new sort key.
- Creation Timeline: An LSI must be defined at table creation time; you cannot add, modify, or delete an LSI after the table exists. In contrast, a GSI can be created or deleted at any time during the lifecycle of the table.
- Storage and Size Constraints: An LSI enforces an item collection size limit of 10 GB per partition key value. GSIs have no limit on the amount of data stored per partition key value or overall index size.
Read Consistency and Capacity
The performance and operational behavior of GSIs and LSIs differ significantly when handling database reads and writes.
Consistency Models
LSIs support both eventually consistent and strongly consistent reads because they reside on the same partition as the parent table. GSIs only support eventually consistent reads because data is asynchronously replicated from the base table to the GSI.
Provisioned Throughput
In DynamoDB provisioned mode, LSIs consume capacity units (RCUs and WCUs) directly from the parent table's provisioned throughput. GSIs have their own dedicated throughput settings, meaning write operations on a GSI require sufficient throughput allocated specifically to that index; otherwise, base table writes may experience throttling.
Key Comparison
| Feature | Local Secondary Index (LSI) | Global Secondary Index (GSI) |
|---|---|---|
| Partition Key | Must be the same as the base table | Can be different from the base table |
| Sort Key | Must be different from the base table | Can be optional or different |
| Creation Time | Table creation only | Any time (creation or post-creation) |
| Read Consistency | Eventually or Strongly Consistent | Eventually Consistent only |
| Capacity / Throughput | Consumes base table throughput | Has separate provisioned capacity |
| Partition Size Limit | 10 GB limit per partition key value | No size limit |
| Index Limits Per Table | Up to 5 per table | Up to 20 per table |
When to Use Each Index
Select an LSI when you need strong read consistency, want your indexes to share the table's throughput capacity, and know that your item collections will never exceed the 10 GB limit per partition key.
Select a GSI when you need to query across the entire dataset using a different partition key, require flexibility to create or remove indexes as application requirements evolve, or expect high-volume data growth that exceeds 10 GB per partition key.