What is a Global Secondary Index (GSI) in DynamoDB?
Understand how DynamoDB Global Secondary Indexes enable queries beyond the primary key, and their consistency trade-offs.
Expected Interview Answer
A Global Secondary Index (GSI) in DynamoDB is an alternate partition-and-sort-key view of a table that lets you query items efficiently by attributes other than the base table’s primary key, at the cost of eventually consistent reads and independently provisioned throughput.
DynamoDB’s base table can only be queried efficiently by its own partition key (and sort key, if present); any other attribute requires a slow full-table scan. A GSI projects some or all attributes into a new table-like structure keyed on a different partition key (and optional sort key), which DynamoDB maintains asynchronously as the base table changes. Because that propagation is async, GSI reads are eventually consistent by default, and because a GSI is physically a separate structure, it has its own read/write capacity settings, so a poorly chosen GSI key can create hot partitions independent of the base table.
- Enables efficient queries on non-primary-key attributes
- Avoids expensive full-table scans for common access patterns
- Can project only needed attributes to save storage and cost
- Scales its own throughput independently from the base table
AI Mentor Explanation
A cricket board’s master registry files every player by national ID (the base table key), which is fast for ID-based lookups but useless if you want every player from a given state. The board builds a second cross-reference registry organized by state instead, kept updated shortly after each change to the master file. A DynamoDB GSI is exactly this second registry: a separate, differently-keyed index that answers a query pattern the base table’s key cannot serve directly.
Step-by-Step Explanation
Step 1
Identify the missing access pattern
Find a query the application needs that the base table’s partition/sort key cannot serve efficiently.
Step 2
Choose the GSI partition and sort key
Pick attributes that distribute traffic evenly and match the new query shape.
Step 3
Define the projection
Choose which attributes (ALL, KEYS_ONLY, or INCLUDE specific ones) are copied into the index.
Step 4
Query the GSI directly
Issue Query requests against the index name, accepting eventually consistent results by default.
What Interviewer Expects
- Clear explanation of why a GSI exists (querying by non-primary-key attributes)
- Awareness that GSI reads are eventually consistent, unlike Local Secondary Indexes
- Understanding that a GSI has its own provisioned/on-demand throughput
- Mention of projections and their storage/cost impact
Common Mistakes
- Assuming GSI reads are always strongly consistent like base table reads
- Forgetting a GSI can throttle independently even if the base table has capacity
- Confusing a Global Secondary Index with a Local Secondary Index
- Projecting ALL attributes unnecessarily, inflating storage cost
Best Answer (HR Friendly)
“A Global Secondary Index is like a second, differently organized copy of a DynamoDB table that lets you search by a field other than the main key. It updates shortly after the main table changes rather than instantly, and it has its own capacity, so it is great for enabling fast queries you did not originally design the table for.”
Code Example
-- Base table: Orders, keyed by order_id (partition key)
-- Query need: "find all orders for a given customer_id"
-- GlobalSecondaryIndex definition (conceptual, DynamoDB CLI/CloudFormation style)
{
"IndexName": "CustomerIdIndex",
"KeySchema": [
{ "AttributeName": "customer_id", "KeyType": "HASH" },
{ "AttributeName": "order_date", "KeyType": "RANGE" }
],
"Projection": { "ProjectionType": "INCLUDE", "NonKeyAttributes": ["total", "status"] }
}
-- Equivalent query intent (conceptual SQL translation):
SELECT order_id, order_date, total, status
FROM Orders_CustomerIdIndex
WHERE customer_id = 101
ORDER BY order_date DESC;Follow-up Questions
- How does a Global Secondary Index differ from a Local Secondary Index?
- What happens if a GSI’s write capacity is exceeded but the base table’s is not?
- How do you get strongly consistent reads on data queried by a GSI?
- What is a sparse index and how can a GSI be used to build one?
MCQ Practice
1. By default, reads from a DynamoDB Global Secondary Index are:
GSIs are updated asynchronously from the base table, so DynamoDB only offers eventually consistent reads on them by default.
2. Why would a table need a GSI instead of just scanning?
A GSI provides an alternate key structure so queries on non-primary-key attributes avoid an expensive full-table scan.
3. What can happen if a GSI’s partition key values are highly skewed?
A GSI has its own throughput allocation, so an unevenly distributed key can create hot partitions and throttling on the index alone.
Flash Cards
What is a GSI? — An alternate partition/sort key index in DynamoDB for querying by non-primary-key attributes.
Are GSI reads strongly consistent by default? — No, they are eventually consistent because updates propagate asynchronously from the base table.
Does a GSI have its own throughput? — Yes, a GSI is provisioned or scaled independently from the base table.
What is a projection in a GSI? — The set of attributes copied into the index: ALL, KEYS_ONLY, or a specific INCLUDE list.