DynamoDB Indexes Explained: LSI vs GSI and When to Use Them

When working with Amazon DynamoDB, understanding how to effectively use secondary indexes is crucial for building performant, cost-effective applications. Unlike relational databases where you can query any column, DynamoDB limits your primary access to partition and sort keys. Secondary indexes unlock the ability to query your data efficiently using different attributes.

This comprehensive guide explains everything you need to know about DynamoDB’s indexing options, helping you make informed decisions about when and how to use each type.

What Are Secondary Indexes in DynamoDB?

In DynamoDB, a secondary index lets you query data using an alternative key pattern, rather than just the primary key of your table. Think of an index as another way to access your data—like an index in a book that helps you look up information by topic instead of reading page by page.

Without secondary indexes, you would have two options for finding data by non-key attributes:

1. Perform a full table scan (expensive and slow)
2. Maintain a duplicate table with a different key structure (complex and costly)

Secondary indexes solve this problem by providing additional “views” of your data organized by different keys.

The Two Types of Secondary Indexes

DynamoDB offers two types of secondary indexes:

1. Local Secondary Indexes (LSIs)
2. Global Secondary Indexes (GSIs)

Each has distinct characteristics, limitations, and use cases. Let’s examine them in detail.

Local Secondary Indexes (LSIs)

What is a Local Secondary Index?

A Local Secondary Index uses the same partition key as the base table but a different sort key. It’s “local” because all items with the same partition key are stored together, both in the table and in the index.

Key Characteristics of LSIs

• Same partition key as the base table
• Different sort key than the base table
• Must be created when the table is created (cannot be added later)
• Limited to 5 LSIs per table
• Strong consistency option available (unlike GSIs)
• Share provisioned throughput with the base table
• 10GB limit per partition key value (across base table and all LSIs)

When to Use Local Secondary Indexes

LSIs are ideal when:

1. You need strongly consistent reads (GSIs only support eventual consistency)
2. You know your access patterns in advance (since LSIs can’t be added later)
3. Your data naturally groups by the same partition key, but you need different sort orders
4. You need to query within a single partition using different criteria

LSI Example

Imagine a music application with a Songs table using ArtistID as the partition key and SongTitle as the sort key:

Table: Songs
- Partition Key: ArtistID
- Sort Key: SongTitle

You might want to query an artist’s songs by release year instead of title. An LSI would allow this:

LSI: YearIndex
- Partition Key: ArtistID (same as base table)
- Sort Key: ReleaseYear

With this LSI, you can efficiently run queries like “Get all songs by Artist123 released in 2025” or “Get Artist123’s songs released between 2020 and 2025”.

Dynomate: Modern DynamoDB GUI Client

Built for real developer workflows with AWS profile integration, multi-session support, and team collaboration.

AWS SSO support & multi-region browsing

Script-like operations with data chaining

Git-friendly local storage for team sharing

Download Free TrialCompare GUI Clients

No account needed. Install and start using immediately.

• Table browsing across regions
• Flexible query & scan interface
• AWS API logging & debugging

Global Secondary Indexes (GSIs)

What is a Global Secondary Index?

A Global Secondary Index can use any attributes as its partition and sort keys, completely independent from the base table’s key schema. It’s “global” because it spans all partition key values in the base table.

Key Characteristics of GSIs

• Can use any attributes as partition and sort keys
• Can be created or deleted at any time (even after table creation)
• Limited to 20 GSIs per table
• Eventual consistency only (no strong consistency option)
• Have their own provisioned throughput separate from the base table
• No size limitations per partition key

When to Use Global Secondary Indexes

GSIs are best when:

1. You need to query data using completely different attributes
2. You need flexibility to add indexes as your access patterns evolve
3. You have large item collections that might exceed the 10GB LSI limit
4. You want to isolate index traffic from table traffic (separate throughput)

GSI Example

Continuing with our music application, you might want to find songs by genre or popularity:

GSI: GenreIndex
- Partition Key: Genre
- Sort Key: Popularity

With this GSI, you can efficiently query “Get the most popular rock songs” or “Find all jazz songs above a certain popularity threshold”.

LSI vs GSI: Key Differences and Comparison

Here’s a side-by-side comparison to help you choose the right index type:

Feature	Local Secondary Index (LSI)	Global Secondary Index (GSI)
Partition Key	Must match base table	Can be any attribute
Sort Key	Can be any attribute	Can be any attribute
Creation Timing	Only at table creation	Any time
Consistency	Supports strong consistency	Eventual consistency only
Throughput	Shares with base table	Independent throughput
Size Limit	10GB per partition key	No partition size limit
Maximum Per Table	5 LSIs	20 GSIs
Use Cases	Same-partition different sort order	Cross-partition queries, flexible access patterns
Deletion	Cannot be removed once created	Can be deleted any time

Attribute Projections in Indexes

When creating a secondary index, you specify which attributes are “projected” (copied) to the index:

Projection Types

1. KEYS_ONLY: Only the table and index keys are projected
2. INCLUDE: Only the specified attributes are projected
3. ALL: All attributes are projected

Choosing the right projection type is a trade-off between:

• Query flexibility (having all attributes available)
• Storage costs (projecting fewer attributes uses less space)
• Read efficiency (avoiding fetching from the base table)

Projection Recommendation

• Use KEYS_ONLY for checking existence or counting items
• Use INCLUDE when you know exactly which attributes your queries need
• Use ALL when query patterns vary or queries need most attributes

Advanced Indexing Concepts

Sparse Indexes

A sparse index is an advanced pattern where the index only contains items that have the indexed attribute. This is useful for querying a subset of data.

Example of a Sparse Index

If you have an Orders table and want to query only completed orders:

GSI: CompletedOrdersIndex
- Partition Key: IsCompleted
- Sort Key: CompletionDate

By only setting the IsCompleted attribute on completed orders, this GSI becomes a sparse index that only contains completed orders, making them easy to query.

Overloaded Indexes

An overloaded index uses the same index for multiple access patterns by carefully structuring attribute values.

Example of an Overloaded Index

For a social media application, you might create a GSI with:

GSI: EntityIndex
- Partition Key: EntityType (e.g., "POST#", "COMMENT#", "LIKE#")
- Sort Key: EntityID

This allows you to query all posts, all comments, or all likes using the same index, by prefixing the EntityType value with the type of entity.

Index Design Patterns

Some common index design patterns include:

1. Adjacency Lists: Using prefixes in partition keys to model many-to-many relationships
2. GSI Overloading: Using one GSI for multiple access patterns to stay within the 20 GSI limit
3. Composite Sort Keys: Combining multiple attributes in the sort key for flexible querying
4. Inverted Indexes: Creating indexes that reverse the relationship between items

Real-World Example: Order Management System

Let’s examine a complete example of a DynamoDB table with strategically designed indexes:

Familiar with these Dynamodb Challenges ?

• Writing one‑off scripts for simple DynamoDB operations
• Constantly switching between AWS profiles and regions
• Sharing and managing database operations with your team

You should try Dynomate GUI Client for DynamoDB

• Create collections of operations that work together like scripts
• Seamless integration with AWS SSO and profile switching
• Local‑first design with Git‑friendly sharing for team collaboration

Download Free TrialCompare GUI Clients

Base Table: Orders

Table: Orders
- Partition Key: CustomerID
- Sort Key: OrderID

With this base table, you can efficiently find all orders for a specific customer.

Index 1: GSI for Status-Based Queries

GSI: StatusIndex
- Partition Key: OrderStatus
- Sort Key: OrderDate

This GSI lets you:

• Find all pending orders
• Find all orders delivered on a specific date
• Find all canceled orders from last month

Index 2: LSI for Customer Order Dates

LSI: CustomerDateIndex
- Partition Key: CustomerID (same as base table)
- Sort Key: OrderDate

This LSI enables queries like:

• Find a customer’s most recent orders
• Find a customer’s orders from a specific time period

Index 3: GSI for Product-Based Queries

GSI: ProductIndex
- Partition Key: ProductID
- Sort Key: OrderDate

This GSI allows you to:

• Find all orders for a specific product
• Analyze product sales over time

With this structure, the application can efficiently handle diverse query requirements without resorting to expensive table scans.

Best Practices for DynamoDB Indexes

Design Considerations

1. Start with access patterns: Design your indexes based on query requirements, not data structure
2. Minimize index count: Each index increases costs and write latency
3. Choose projection attributes carefully: Project only what you need to minimize storage costs
4. Be mindful of item sizes: Remember the 400KB item size limit applies to indexes too

Cost Optimization

1. Monitor unused indexes: Delete indexes that are no longer needed
2. Use sparse indexes where possible to reduce index size and cost
3. Consider KEYS_ONLY projections for simple existence checks
4. Set appropriate provisioned capacity on GSIs to avoid over-provisioning

Performance Optimization

1. Avoid table scans: Always design indexes to support your query patterns
2. Distribute write activity: Avoid hot partitions by using high-cardinality partition keys
3. Use LSIs for strong consistency when needed
4. Consider caching for frequently accessed data

Index Limitations and Gotchas

1. LSI creation timing: Remember LSIs can only be created when the table is created
2. 10GB partition limit: Watch for the LSI partition size limit for high-volume partitions
3. Attribute projection: If an attribute isn’t projected, you’ll need an additional fetch from the base table
4. Throughput considerations: GSIs have their own throughput but LSIs share table throughput
5. Eventually consistent GSIs: GSI replication may have slight delays (typically milliseconds)
6. Sparse index limitations: Be aware that items without the indexed attribute won’t appear in the index

Switching from Dynobase? Try Dynomate

Developers are switching to Dynomate for these key advantages:

Better Multi-Profile Support

• Native AWS SSO integration
• Seamless profile switching
• Multiple accounts in a single view

Developer-Focused Workflow

• Script-like operation collections
• Chain data between operations
• Full AWS API logging for debugging

Team Collaboration

• Git-friendly collection sharing
• No account required for installation
• Local-first data storage for privacy

Privacy & Security

• No account creation required
• 100% local data storage
• No telemetry or usage tracking

Try Dynomate Free for 7 DaysDynomate vs. Dynobase

Conclusion

DynamoDB secondary indexes are powerful tools that can dramatically improve the performance and flexibility of your NoSQL database. By understanding the differences between LSIs and GSIs and following the best practices outlined in this guide, you can design a data model that efficiently supports all your application’s access patterns.

Remember:

• Use Local Secondary Indexes (LSIs) when you need alternate sort keys within the same partition or when strong consistency is required
• Use Global Secondary Indexes (GSIs) when you need completely different key structures or flexibility to add indexes later
• Always design your indexes based on your query patterns, not your data structure
• Monitor and optimize your indexes to control costs and maintain performance

For more advanced DynamoDB topics, check out our related articles:

• DynamoDB Query Examples
• Global Secondary Indexes Deep Dive
• DynamoDB Data Modeling Guide
• Understanding DynamoDB Throttling

Need help managing and visualizing your DynamoDB tables and indexes? Dynomate provides an intuitive interface for designing, managing, and monitoring your DynamoDB resources, making it easier to implement the best practices described in this article.