GSI vs LSI in DynamoDB

When you start learning DynamoDB, one thing becomes clear very quickly: how you design your keys decides how well your table works. But when people compare GSI and LSI, they often focus only on feature-level differences like consistency, throughput, or creation time. The real difference becomes much easier to understand when you look at **how DynamoDB maintains them **behind the scenes.

How querying works in DynamoDB

When creating tables in DynamoDB, the Primary Key needs to be defined. A primary key can have:

• Partition key (PK) — decides which group an item belongs to
• Sort key (SK) (optional) — sort items inside that group

Partitions are logical groups where DynamoDB stores data. If a table or index has a sort key, the data inside that partition is stored in sorted order.

Note: A DynamoDB table must have a partition key, but the sort key is optional. If you don’t define a sort key, your table uses a simple primary key (PK only). If you do, it becomes a composite primary key (PK + SK).

DynamoDB is fast when you query using this key structure because it does not need to scan the whole table. It can go directly to the relevant partition and fetch the matching items.

What happens if you want to ***query or sort data, not using ***that primary key? This is where the SECONDARY INDEXES come in.

DynamoDB has two types of indexes:

• GSI — Global Secondary Index.
• LSI — Local Secondary Index.

These indexes help support additional query patterns while maintaining efficiency. At a high level, both GSI and LSI solve the same problem: they let DynamoDB support more query patterns without scanning the whole table. But they do not do it in the same way.

GSI

A GSI creates a separate indexed view of the same data using a different partition key and optionally a different sort key, but keeps two in sync. It queries span all primary(basic) partitions across the entire table.

Characteristics:

• **Eventually consistent — **updates propagate asynchronously. It may take a brief moment for changes to appear in the GSI after the base table is updated.
• Can be created at any time
• separate throughput (settings) —can have Independent Read Capacity Unit(RCU) and Write Capacity Unit(WCU) than base table
• Flexible Keys — Any attribute as partition key/sort key

When to use:

• Query on attributes different from the base table’s primary key
• You can accept eventual consistency for reads
• Need to query to access all partitions of base table
• Add indexes to an existing table
• Flexibility with separate throughput control

Limitations:

• Extra write cost, because DynamoDB must also maintain the index
• More write overhead than using only the base table
• Max of GSI for a table is 20
• If the GSI does not have enough write capacity, it can affect writes to the base table (Throttling can happen)
• Reads are eventually consistent, not strongly consistent

LSI

An LSI is an index that uses the same partition key as the base table, but a different sort key. It does not create a completely new access path across the whole table. Instead, it gives another way to organize and query items within the same partition key. Queries are scoped to a single partition.

Characteristics:

• Strongly consistent — immediate consistency with base table. always use the most updated data. [reads from LSI immediately reflect all writes that were successful before the read operation.]
• Can be created at table creation time only
• Shared throughput — use base table’s RCU and WCU
• Same Partition Key —only sort key can differ

When to use:

• Query with the same partition key as base table, but a different sort key
• Need strong consistency for queries
• Defined during the table design phase

Limitations:

• Less flexible than GSI in the context of throughput, creation time, and choosing partition key.
• Not suitable for queries that need to span the whole table
• Max of LSI for a table is 5

Simple Example:

Base table: Orders

Primary key:

PK: userIdSK: orderId

Sample items:

userId=U1, orderId=O1001, createdAt=2026-03-01, status=SHIPPEDuserId=U1, orderId=O1002, createdAt=2026-03-03, status=PENDINGuserId=U2, orderId=O2001, createdAt=2026-03-02, status=SHIPPED

Scenario 01: Using the base table key

1. Get all orders for U1 (query by userId)
2. Get one order if you know userId + orderId

Scenario 02: Using an LSI (same PK, different sorting)

1. Get orders for a given user, sorted by createdAt

• LSI PK: userId (same as base table)
• LSI SK: createdAt

Now DynamoDB can still look inside the same user’s partition, but sort the results by creation date instead of orderId.

Scenario 03: Use GSI (new access pattern across the table)

1. Get all SHIPPED orders across all users

• GSI PK: status
• (Optional) GSI SK: createdAt (If you want shipped orders sorted by date)

This is a completely new access pattern across the whole table.

In all three scenarios, querying is based on the partitions(logical separations), so only that partition will be accessed to get relevant data. And the sort key is needed to get the other range for that queried data.
Therefore queriying using indexes will be more efficient than using only one partition key and sort key, which is defined for the primary table.

Why do GSI and LSI behave differently?

The real reason is that DynamoDB maintains them differently.

LSI Behaviour

An LSI is closely linked to the base table. It uses the same partition key as the main table. Only the sort key is different. Because of this, LSI queries stay within the same partition key group. DynamoDB does not need to look across the whole table.

Since LSI is closely tied to the base table, it can support strongly consistent reads. But because of that close connection, you must create an LSI when you create the table.

GSI Behaviour

A GSI maintains a separate indexed view of projected data from the base table. using a different partition and sort key. Because of that, a GSI creates a new way to query data. It is not limited to the base table’s main key.

But DynamoDB updates the base table first and then updates the GSI. That is why GSI reads are usually eventually consistent. GSI behaves differently because it works like a separate access path for the same data.

Final Takeaway

Secondary indexes exist because one primary key design cannot support every query pattern.

An LSI helps when you want another way to query data within the same partition key. A GSI helps when you need a new access pattern across the table.

So the core difference is not just consistency or throughput.
The core difference is this:

• LSI changes how you query inside an existing partition key
• GSI creates a new query path using a different key

To really understand LSI and GSI, it helps to look at what is happening underneath and why they behave differently in practice.

Once you see why they work differently, the choice between LSI and GSI becomes much clearer.