Index capacity and cost in DynamoDB - Deep Dive

Overview - Index capacity and cost

What is it?

In DynamoDB, indexes are special data structures that help you find data quickly without scanning the entire table. They come in two main types: Global Secondary Indexes (GSI) and Local Secondary Indexes (LSI). Each index uses read and write capacity units, which affect how much it costs and how fast it can respond. Understanding index capacity and cost means knowing how indexes consume resources and how to manage them efficiently.

Why it matters

Without understanding index capacity and cost, you might create indexes that slow down your app or make your bill unexpectedly high. Indexes speed up data retrieval but use extra capacity, so balancing performance and cost is key. If you ignore this, your database might become expensive or slow, hurting user experience and your budget.

Where it fits

Before learning about index capacity and cost, you should know basic DynamoDB concepts like tables, items, and primary keys. After this, you can explore advanced topics like capacity auto-scaling, adaptive capacity, and cost optimization strategies.

Mental Model

Core Idea

Indexes in DynamoDB are like extra sorted lists that speed up searches but need their own read and write resources, which cost money and affect performance.

Think of it like...

Imagine a library where the main catalog is a big book listing all books. An index is like a special card catalog for a specific topic that helps you find books faster, but maintaining this card catalog takes extra librarian time and space.

┌─────────────┐       ┌───────────────┐
│   DynamoDB  │       │    Indexes    │
│    Table    │──────▶│  GSI and LSI  │
└─────────────┘       └───────────────┘
       │                      │
       │ Uses capacity units   │
       ▼                      ▼
┌─────────────┐        ┌─────────────┐
│ Read/Write  │        │ Read/Write  │
│ Capacity    │        │ Capacity    │
│ Units       │        │ Units       │
└─────────────┘        └─────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding DynamoDB Capacity Units

Concept: Learn what read and write capacity units are and how they measure throughput.

DynamoDB uses read capacity units (RCUs) and write capacity units (WCUs) to control how much data you can read or write per second. One RCU allows you to read up to 4 KB of data per second for strongly consistent reads (or 8 KB for eventually consistent reads), and one WCU allows you to write up to 1 KB per second. These units help DynamoDB manage performance and cost.

Result

You understand that capacity units limit how fast you can read or write data and that bigger items use more units.

Knowing capacity units is essential because indexes consume these units separately, affecting your overall throughput and cost.

2

Foundation

What Are DynamoDB Indexes?

Concept: Introduce Global Secondary Indexes (GSI) and Local Secondary Indexes (LSI) and their purpose.

Indexes let you query data using different keys than the main table's primary key. GSIs are separate tables that can have different partition and sort keys, while LSIs share the same partition key but have different sort keys. Both improve query flexibility but use extra capacity.

Result

You see that indexes are extra data structures that speed up queries but need their own resources.

Understanding index types helps you plan how capacity units will be used and how indexes affect cost.

3

Intermediate

How Indexes Consume Capacity Units

🤔Before reading on: do you think indexes share the same capacity units as the main table or have their own? Commit to your answer.

Concept: Explain that indexes have separate capacity units from the main table and how this impacts cost.

Each index has its own read and write capacity units. When you write to the main table, DynamoDB also writes to the indexes, consuming write capacity units for each index. Similarly, reading from an index consumes read capacity units from that index, not the main table. This means indexes increase your total capacity usage and cost.

Result

You realize that adding indexes increases your capacity needs and monthly bill.

Knowing that indexes have separate capacity units helps you predict and control costs by managing how many indexes you create and how much traffic they get.

4

Intermediate

Differences in Capacity Cost Between GSI and LSI

🤔Before reading on: do you think LSIs and GSIs cost the same in capacity units? Commit to your answer.

Concept: Highlight how GSIs and LSIs differ in capacity consumption and cost implications.

LSIs share the same partition key as the main table and do not consume extra write capacity units on writes, but they do consume read capacity units when queried. GSIs have their own partition key and consume write capacity units on every write to the main table, plus read capacity units when queried. GSIs generally cost more because they replicate data separately.

Result

You understand that GSIs are more expensive to maintain than LSIs due to extra write capacity usage.

Knowing these differences helps you choose the right index type to balance performance and cost.

5

Intermediate

Impact of Item Size on Index Capacity

Concept: Explain how the size of items affects capacity unit consumption for indexes.

Capacity units are based on item size. Larger items consume more read and write capacity units. When an item is written to the main table, the entire item or projected attributes are written to the index, consuming capacity units proportional to their size. This means bigger items or indexes with many projected attributes cost more.

Result

You see that item size directly affects how much capacity and cost indexes use.

Understanding item size impact helps you optimize indexes by projecting only needed attributes to save capacity and cost.

6

Advanced

Managing Capacity with Auto Scaling and Adaptive Capacity

🤔Before reading on: do you think DynamoDB automatically adjusts capacity for indexes or do you have to do it manually? Commit to your answer.

Concept: Introduce how DynamoDB can automatically adjust capacity for indexes to handle traffic changes.

DynamoDB offers auto scaling to adjust read and write capacity units for tables and GSIs based on traffic patterns. Adaptive capacity helps redistribute unused capacity to hot partitions, improving performance without manual intervention. These features help manage index capacity efficiently and control costs.

Result

You learn that DynamoDB can help optimize capacity usage for indexes automatically.

Knowing about auto scaling and adaptive capacity lets you design systems that handle traffic spikes without over-provisioning capacity.

7

Expert

Surprising Costs: Sparse Indexes and Write Amplification

🤔Before reading on: do you think indexes always increase write costs by a fixed amount or can it vary? Commit to your answer.

Concept: Explain how sparse indexes and write amplification can cause unexpected capacity costs.

Sparse indexes only include items with certain attributes, which can reduce index size and cost. However, write amplification happens because every write to the main table that affects an index consumes write capacity units for that index, even if only a small attribute changes. This can cause higher costs than expected, especially with many GSIs or large items.

Result

You discover that index costs can be unpredictable and require careful design and monitoring.

Understanding sparse indexes and write amplification helps you avoid hidden costs and optimize index design for production.

Under the Hood

DynamoDB stores indexes as separate tables internally. When you write to the main table, DynamoDB synchronously replicates the relevant data to each index, consuming write capacity units for each. Reads from indexes consume capacity units from the index's provisioned or on-demand capacity. This separation allows fast queries on different keys but requires managing capacity for each index independently.

Why designed this way?

This design balances fast query performance with scalability. By separating indexes, DynamoDB can optimize queries on different keys without scanning the main table. The tradeoff is extra storage and capacity cost. Alternatives like scanning the main table would be slower and less scalable, so this design prioritizes speed and flexibility.

┌───────────────┐      ┌───────────────┐      ┌───────────────┐
│   Main Table  │─────▶│    GSI Table  │      │    LSI Table  │
│ (Primary Key) │      │ (Separate PK) │      │ (Same PK, Diff│
└───────────────┘      └───────────────┘      │  Sort Key)    │
       │                      │               └───────────────┘
       │                      │                      ▲
       │                      │                      │
       │                      │                      │
       ▼                      ▼                      │
┌───────────────┐      ┌───────────────┐            │
│ Write to Main │      │ Write to GSI  │◀───────────┘
│ consumes WCU  │      │ consumes WCU  │
└───────────────┘      └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think adding an index does not affect write costs? Commit yes or no.

Common Belief: Adding an index only affects read performance and cost, not writes.

Reality: Indexes increase write costs because every write to the main table that affects an index also writes to that index, consuming additional write capacity units.

Why it matters: Ignoring this leads to underestimating costs and capacity needs, causing throttling or unexpected bills.

Quick: Do you think LSIs can be added after table creation? Commit yes or no.

Common Belief: You can add Local Secondary Indexes anytime after creating the table.

Reality: LSIs must be defined when the table is created and cannot be added later.

Why it matters: Planning indexes incorrectly can force costly table redesigns or data migrations.

Quick: Do you think projecting all attributes to an index always improves performance? Commit yes or no.

Common Belief: Projecting all attributes to an index is always better for query speed.

Reality: Projecting all attributes increases index size and write costs, which can hurt performance and cost efficiency.

Why it matters: Over-projecting wastes capacity and money, so careful attribute selection is crucial.

Quick: Do you think DynamoDB automatically shares capacity units between table and indexes? Commit yes or no.

Common Belief: DynamoDB automatically shares capacity units between the main table and its indexes.

Reality: Each index has its own capacity units; they are not shared with the main table.

Why it matters: Misunderstanding this causes capacity planning errors and unexpected throttling.

Expert Zone

1

Sparse indexes can reduce write costs by only including items with specific attributes, but they require careful query design to avoid missing data.

2

Write amplification means that even small updates to items can cause multiple write capacity unit charges if multiple GSIs exist, impacting cost unpredictably.

3

Adaptive capacity helps hot partitions in indexes get more throughput without manual scaling, but it does not eliminate the need for proper capacity planning.

When NOT to use

Avoid using many GSIs on write-heavy tables because write amplification can cause high costs and throttling. Instead, consider denormalizing data or using single-table design patterns. For queries that don't need fast lookups, scanning or filtering might be cheaper.

Production Patterns

In production, teams often limit GSIs to essential queries, use sparse indexes to reduce size, and enable auto scaling to handle traffic spikes. Monitoring index usage and capacity consumption is standard to optimize cost and performance.

Connections

Caching

Builds-on

Understanding index capacity helps decide when to use caching layers to reduce read load and save capacity units.

Cost Optimization

Builds-on

Knowing index costs is key to optimizing cloud spending and designing cost-effective data architectures.

Supply Chain Inventory Management

Analogy in resource allocation

Just like managing warehouse space and restocking costs, managing index capacity balances resource use and cost for efficient operations.

Common Pitfalls

#1 Creating many GSIs without considering write capacity impact.

Wrong approach:

Create 5 GSIs on a write-heavy table without adjusting write capacity units or monitoring costs.

Correct approach:

Limit GSIs to essential queries, monitor write capacity usage, and enable auto scaling to handle increased load.

Root cause:

Misunderstanding that each GSI consumes write capacity units on every write causes unexpected throttling and high costs.

#2 Projecting all attributes to indexes by default.

Wrong approach:

Define GSIs with ProjectionType = ALL regardless of query needs.

Correct approach:

Project only necessary attributes to indexes to reduce size and write costs.

Root cause:

Assuming more data in indexes always improves performance leads to higher costs and slower writes.

#3 Trying to add LSIs after table creation.

Wrong approach:

Attempt to add an LSI to an existing table using update commands.

Correct approach:

Define LSIs only during table creation or redesign the table if needed.

Root cause:

Not knowing LSIs are fixed at table creation causes wasted effort and delays.

Key Takeaways

DynamoDB indexes improve query speed but consume separate read and write capacity units, affecting cost and performance.

Global Secondary Indexes (GSIs) consume write capacity units on every write, while Local Secondary Indexes (LSIs) share partition keys and have different cost behaviors.

Item size and projected attributes directly impact index capacity consumption; careful design reduces unnecessary costs.

Auto scaling and adaptive capacity help manage index capacity dynamically but do not replace thoughtful capacity planning.

Misunderstanding index capacity leads to unexpected costs, throttling, and poor application performance.