DynamoDB Secondary Indexes
Explore how DynamoDB secondary indexes enable multiple query patterns beyond a table's primary key. Understand differences between global and local secondary indexes, learn about projection types that affect storage and efficiency, and grasp write amplification impacts on throughput. This lesson helps you design indexes that improve query flexibility and optimize cost and performance.
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 nonmatching rows, which means it consumes the same read capacity whether the filter returns one item or 10,000.
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 ...