DynamoDB Secondary Indexes
Explore how DynamoDB secondary indexes enable multiple efficient query patterns without full-table scans. Understand the structural differences between global and local secondary indexes, how projection choices impact costs and query performance, and manage write amplification to optimize database operations. This lesson guides you through designing indexes aligned with application access patterns for scalable DynamoDB implementations.
In the previous lesson, you learned how to group related items into item collections under shared partition keys and how adjacency patterns model many-to-many relationships efficiently. That modeling work gives you one well-designed access path through the base table’s primary key. Real applications, however, rarely need just one way to look up data. An order-management system might query orders by customer ID through the base table key, but it also needs to retrieve orders by status, by date range, or by fulfillment warehouse. Each of those queries demands a different lookup attribute, and without a mechanism to support them, the only fallback is a full-table scan with a FilterExpression. That fallback reads every item in the table before discarding non-matching rows, which means it consumes the same read capacity whether the filter returns one item or ten thousand.
Secondary indexes solve this problem. They let DynamoDB maintain additional, automatically synchronized data structures that support alternate query patterns without duplicating tables or accepting the cost of scans. AWS provides two types, global secondary index (GSI) and local secondary index (LSI), and understanding when to use each is a core DynamoDB design skill. This lesson covers three themes that determine whether your indexes help or hurt your workload: index mechanics and the structural differences between GSIs and LSIs, projection trade-offs that control what data lives inside each index, and write-amplification costs that multiply every base-table write across all attached indexes.
Note: FilterExpression is not a substitute for index design. It applies after DynamoDB reads matching items, so it does not reduce consumed read capacity. If you find yourself relying on filters for a frequent access pattern, that pattern almost certainly needs an index.Global vs. local secondary indexes
Choosing between a GSI and an LSI determines how your index relates to the base table's key structure, how it scales, and what consistency guarantees your queries can offer. The distinction is not cosmetic. It affects provisioning, operational behavior, and even when you can create the index.
GSI mechanics
A