DynamoDB Tables, Keys, and Indexes

Effective DynamoDB table design is radically different from relational modelling. Instead of normalising data into many tables and joining them at query time, you denormalise and design your tables around your application's access patterns. This lesson covers key design, secondary indexes, and single-table design — the techniques that unlock DynamoDB's full potential.

---

Key Design Principles

1. Identify Your Access Patterns First

Before creating a table, list every query your application needs to perform. For example, an e-commerce application might need:

1. Get a product by ID
2. List all orders for a customer, sorted by date
3. Get all items in an order
4. Find orders by status (e.g., "shipped")
5. Get the top 10 best-selling products this month

2. Choose Keys That Distribute Evenly

The partition key determines how DynamoDB distributes data across physical partitions. A good partition key has high cardinality — many distinct values — so that no single partition becomes a hot spot.

Good Partition Keys	Bad Partition Keys
userId, orderId, deviceId	status ("active" / "inactive")
date + random suffix	country (too few values)
tenantId (multi-tenant SaaS)	boolean flags

3. Use the Sort Key for Range Queries

The sort key orders items within a partition and supports rich comparison operators:

=   equals
<   less than
>   greater than
<=  less than or equal to
>=  greater than or equal to
BETWEEN ... AND ...
begins_with(...)

---

Secondary Indexes

Sometimes your primary key does not support all of your access patterns. DynamoDB offers two types of secondary indexes:

Global Secondary Index (GSI)

• Has its own partition key and optional sort key — completely independent of the table's primary key
• Can be created at any time (even on an existing table)
• Has its own provisioned throughput or on-demand capacity
• Supports eventually consistent reads only
• Maximum 20 GSIs per table

Example

Your Orders table uses customerId as the partition key and orderDate as the sort key. You need to query orders by status. Create a GSI:

GSI: StatusDateIndex
Partition Key: status
Sort Key: orderDate
Projected Attributes: ALL

Now you can query all "shipped" orders sorted by date without scanning the entire table.

Local Secondary Index (LSI)

• Shares the same partition key as the table but uses a different sort key
• Must be created at table creation time — cannot be added later
• Supports strongly consistent reads
• Maximum 5 LSIs per table
• Shares throughput with the base table

Example

Your Orders table uses customerId (PK) and orderDate (SK). You also want to sort orders by totalAmount:

LSI: AmountIndex
Partition Key: customerId  (same as table)
Sort Key: totalAmount
Projected Attributes: KEYS_ONLY

GSI vs LSI — Quick Reference

Feature	GSI	LSI
Partition key	Different from table	Same as table
Sort key	Optional	Required (different from table)
When created	Any time	Table creation only
Read consistency	Eventually consistent	Eventually or strongly consistent
Throughput	Separate	Shared with table
Maximum per table	20	5

---

Projections