Bird
Raised Fist0
DynamoDBquery~5 mins

Composite primary key in DynamoDB

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Introduction

A composite primary key helps you organize data by using two parts together to find each item uniquely.

When you want to store orders where each order has many items, and you want to find items by order and item ID.
When you have users and their posts, and you want to find posts by user and post date.
When you want to keep track of events by date and event type.
When you want to group related data and still find each piece easily.
When you want to avoid duplicate entries that share one key but differ in another.
Syntax
DynamoDB
TableName:
  PartitionKey: <PartitionKeyName> (Type: String or Number)
  SortKey: <SortKeyName> (Type: String or Number)

Example:
  PartitionKey: UserID (String)
  SortKey: OrderID (String)

The PartitionKey is like the main folder where data is stored.

The SortKey helps sort and find items inside that folder.

Examples
This setup lets you find invoices for each customer easily.
DynamoDB
PartitionKey: CustomerID (String)
SortKey: InvoiceID (String)
This helps group products by category and find each product by its ID.
DynamoDB
PartitionKey: ProductCategory (String)
SortKey: ProductID (Number)
This lets you find user actions sorted by time.
DynamoDB
PartitionKey: UserID (String)
SortKey: Timestamp (Number)
Sample Program

This example creates a table with a composite primary key using OrderID and ItemID. It adds two items to the same order and then queries all items for that order.

DynamoDB
CreateTable {
  TableName: "Orders",
  KeySchema: [
    { AttributeName: "OrderID", KeyType: "HASH" },  # Partition Key
    { AttributeName: "ItemID", KeyType: "RANGE" }   # Sort Key
  ],
  AttributeDefinitions: [
    { AttributeName: "OrderID", AttributeType: "S" },
    { AttributeName: "ItemID", AttributeType: "S" }
  ],
  ProvisionedThroughput: {
    ReadCapacityUnits: 5,
    WriteCapacityUnits: 5
  }
}

# Insert items
PutItem TableName="Orders" Item={"OrderID": "123", "ItemID": "A1", "Product": "Book", "Quantity": 2}
PutItem TableName="Orders" Item={"OrderID": "123", "ItemID": "B2", "Product": "Pen", "Quantity": 5}

# Query items for OrderID = "123"
Query TableName="Orders" KeyConditionExpression="OrderID = :orderId" ExpressionAttributeValues={":orderId": {"S": "123"}}
OutputSuccess
Important Notes

Composite primary keys let you store multiple related items under one main key.

PartitionKey decides the partition where data is stored; SortKey orders items inside that partition.

Using composite keys helps avoid duplicates and improves query speed for grouped data.

Summary

A composite primary key uses two attributes: PartitionKey and SortKey.

It helps organize and find related data easily.

Use it when you want to group items and still keep each item unique.

Practice

(1/5)
1.

What is a composite primary key in DynamoDB?

easy
A. A key that allows duplicate items
B. A key made of only one attribute
C. A key made of two attributes: PartitionKey and SortKey
D. A key used only for indexing

Solution

  1. Step 1: Understand primary key types in DynamoDB

    DynamoDB supports simple primary keys (one attribute) and composite primary keys (two attributes).
  2. Step 2: Identify composite primary key components

    A composite primary key consists of a PartitionKey and a SortKey to uniquely identify items.
  3. Final Answer:

    A key made of two attributes: PartitionKey and SortKey -> Option C
  4. Quick Check:

    Composite primary key = PartitionKey + SortKey [OK]
Hint: Composite key always has PartitionKey and SortKey [OK]
Common Mistakes:
  • Thinking composite key has only one attribute
  • Confusing composite key with secondary indexes
  • Believing composite key allows duplicates
2.

Which of the following is the correct way to define a composite primary key in DynamoDB table creation?

{
  "TableName": "Orders",
  "KeySchema": [
    {"AttributeName": "CustomerId", "KeyType": "HASH"},
    {"AttributeName": "OrderDate", "KeyType": "RANGE"}
  ]
}
easy
A. Use KeyType RANGE for both attributes
B. Use KeyType RANGE for PartitionKey and HASH for SortKey
C. Use KeyType HASH for both attributes
D. Use KeyType HASH for PartitionKey and RANGE for SortKey

Solution

  1. Step 1: Recall KeyType meanings

    In DynamoDB, HASH means PartitionKey and RANGE means SortKey.
  2. Step 2: Match KeyType to attributes

    PartitionKey must be HASH and SortKey must be RANGE for composite keys.
  3. Final Answer:

    Use KeyType HASH for PartitionKey and RANGE for SortKey -> Option D
  4. Quick Check:

    PartitionKey=HASH, SortKey=RANGE [OK]
Hint: HASH = PartitionKey, RANGE = SortKey in KeySchema [OK]
Common Mistakes:
  • Swapping HASH and RANGE roles
  • Using same KeyType for both keys
  • Confusing attribute names with KeyType
3.

Given a DynamoDB table with composite primary key (UserId as PartitionKey, Timestamp as SortKey), what will this query return?

{
  "TableName": "UserActivity",
  "KeyConditionExpression": "UserId = :uid and Timestamp > :time",
  "ExpressionAttributeValues": {
    ":uid": {"S": "user123"},
    ":time": {"N": "1609459200"}
  }
}
medium
A. All activities of user123 with Timestamp greater than 1609459200
B. All activities of all users with Timestamp greater than 1609459200
C. All activities of user123 regardless of Timestamp
D. Syntax error due to missing SortKey in query

Solution

  1. Step 1: Understand KeyConditionExpression

    It filters items by PartitionKey equality and SortKey condition.
  2. Step 2: Analyze the query conditions

    UserId = :uid restricts to user123; Timestamp > :time filters timestamps after 1609459200.
  3. Final Answer:

    All activities of user123 with Timestamp greater than 1609459200 -> Option A
  4. Quick Check:

    PartitionKey + SortKey condition filters items [OK]
Hint: PartitionKey = value AND SortKey condition filters items [OK]
Common Mistakes:
  • Thinking query returns all users' data
  • Ignoring SortKey condition
  • Assuming syntax error without SortKey equality
4.

What is wrong with this DynamoDB query using composite primary key (UserId as PartitionKey, OrderId as SortKey)?

{
  "TableName": "Orders",
  "KeyConditionExpression": "OrderId = :oid",
  "ExpressionAttributeValues": {
    ":oid": {"S": "order789"}
  }
}
medium
A. PartitionKey UserId is missing in KeyConditionExpression
B. SortKey OrderId cannot be used in KeyConditionExpression
C. ExpressionAttributeValues syntax is incorrect
D. TableName is invalid

Solution

  1. Step 1: Recall query requirements for composite keys

    Queries must specify PartitionKey equality in KeyConditionExpression.
  2. Step 2: Check the given query

    Only SortKey OrderId is used; PartitionKey UserId is missing, causing error.
  3. Final Answer:

    PartitionKey UserId is missing in KeyConditionExpression -> Option A
  4. Quick Check:

    PartitionKey must be in query condition [OK]
Hint: Always include PartitionKey equality in query [OK]
Common Mistakes:
  • Using only SortKey in query condition
  • Assuming SortKey alone can identify items
  • Ignoring required PartitionKey in queries
5.

You want to store blog posts in DynamoDB. Each post has a AuthorId and a PostDate. You want to quickly find all posts by an author sorted by date. Which composite primary key design is best?

hard
A. PartitionKey: PostDate, SortKey: AuthorId
B. PartitionKey: AuthorId, SortKey: PostDate
C. PartitionKey: AuthorId only, no SortKey
D. PartitionKey: PostDate only, no SortKey

Solution

  1. Step 1: Identify query pattern

    You want to find all posts by an author, sorted by date.
  2. Step 2: Choose PartitionKey and SortKey accordingly

    PartitionKey should be AuthorId to group posts by author; SortKey should be PostDate to sort posts by date.
  3. Final Answer:

    PartitionKey: AuthorId, SortKey: PostDate -> Option B
  4. Quick Check:

    Group by author, sort by date = AuthorId + PostDate [OK]
Hint: PartitionKey groups, SortKey sorts related items [OK]
Common Mistakes:
  • Swapping PartitionKey and SortKey roles
  • Using only one key losing sorting ability
  • Choosing SortKey that doesn't support query pattern