DynamoDB Core Concepts: Tables, Items, Attributes, Primary Keys and Partitions

Introduction

DynamoDB starts to make sense when you understand its basic building blocks: tables, items, attributes, primary keys, and partitions. These concepts explain how DynamoDB stores data and why some table designs scale beautifully while others create performance problems.

Imagine you are building an online shopping platform similar to Amazon. You need to store millions of customers, millions of products, billions of orders, shopping carts, payments, and reviews. In a relational database, you usually begin by designing normalized tables and relationships. In DynamoDB, you begin with a different question: how will the application access this data?

That mindset shift is the foundation of DynamoDB data modeling.

Purpose of this lesson

By the end of this lesson, you will understand DynamoDB tables, items, attributes, simple and composite primary keys, partition keys, sort keys, internal partitioning, hot partitions, and practical rules for designing efficient keys.

Understanding the topic

Every piece of data in DynamoDB follows a simple hierarchy. A table contains items, and each item contains attributes.

Internal architecture

A DynamoDB table does not require predefined columns except for the primary key. Different items in the same table can contain different attributes.

This flexibility is useful for evolving applications, but it does not remove the need for careful design. DynamoDB is schema-flexible, not design-free.

{
  "CustomerId": "1001",
  "Name": "Rahul",
  "Email": "rahul@gmail.com"
}

{
  "CustomerId": "1002",
  "Name": "Priya",
  "Email": "priya@gmail.com",
  "Membership": "Gold",
  "RewardPoints": 2000
}

Data flow

Every DynamoDB table requires a primary key. The primary key is how DynamoDB identifies and locates items efficiently.

Visual explanation

The partition key is the most important DynamoDB concept. DynamoDB hashes it to decide which physical partition stores the item.

Step-by-step explanation

1. The application writes an item with a partition key.
2. DynamoDB hashes the partition key value.
3. The hash result maps to a storage partition.
4. If the table grows, DynamoDB creates additional partitions automatically.
5. Queries using the partition key can go directly to the right partition instead of scanning the whole table.
6. A sort key can organize related items under the same partition key for range queries.

Real-world use

Imagine a large marketplace receives 10 million orders in a day. If OrderId is the partition key, DynamoDB can distribute those orders across many partitions. Many servers can process reads and writes in parallel, helping DynamoDB maintain low latency during peak events.

• Customer table: simple key CustomerId for direct profile lookups.
• Orders by customer: composite key CustomerId + OrderDate for order history.
• Product catalog: ProductId for direct product detail pages.
• Shopping cart: UserId plus item-specific sort keys for active cart state.

Scalability analysis

Good partition keys spread data and traffic evenly. Poor partition keys create hot partitions where too many reads or writes hit the same physical partition.

Decision framework

• Use a simple primary key when every item is retrieved by one unique identifier.
• Use a composite primary key when you need multiple related records under the same partition key.
• Use a sort key when you need range queries, latest records, date filtering, or ordered retrieval.
• Choose partition keys with high cardinality and evenly distributed traffic.
• Start from access patterns: what must the application read and write quickly?

Best practices

• Always design the primary key based on access patterns.
• Choose partition keys with high cardinality.
• Avoid sequential or low-cardinality values when they concentrate traffic.
• Use composite keys when range queries are required.
• Keep item sizes as small as practical.
• Plan for future growth before production traffic arrives.

Common mistakes

• Choosing a partition key with very few unique values.
• Treating DynamoDB like a relational database.
• Ignoring access patterns.
• Creating unnecessary tables before knowing query needs.
• Using scans instead of queries.
• Designing the schema before understanding application requirements.

Advanced interview questions

Hands-on exercise

Design a DynamoDB table for an Online Book Store. The system must store book information, track customer orders, retrieve all orders for a customer, and retrieve the latest order quickly.

• What should be the table name?
• What should be the partition key?
• Should you use a sort key? If yes, which attribute?
• List five attributes for each item.
• Explain how your key design supports the application's access patterns.

Summary

DynamoDB data modeling begins with tables, items, attributes, primary keys, and partitions. Tables store items, items store attributes, and primary keys determine how data is located. The partition key is especially important because DynamoDB uses it to distribute data across physical partitions.

A well-designed primary key is the single most important factor in DynamoDB performance. Good keys support application access patterns and spread traffic evenly. Poor keys create hot partitions, scans, throttling, and expensive designs.

Next: Lesson 4 covers DynamoDB read and write capacity, consistency models, on-demand vs provisioned capacity, adaptive capacity, throughput calculations, cost optimization, and production performance tuning.