DynamoDB: Data Modeling & Core Concepts

DynamoDB is AWS's fully managed NoSQL key-value and document database. It provides single-digit millisecond latency at any scale with automatic horizontal scaling. The data model is fundamentally different from relational databases.

Key Concepts

• Table: collection of items (equivalent to a SQL table but schema-less)

• Item: a single record — like a JSON object, up to 400KB

• Attribute: a field within an item — can be scalar, set, list, map, or binary

• Primary Key: uniquely identifies an item — either simple (Partition Key only) or composite (PK + Sort Key)

• Partition Key (PK / HASH key): determines which partition stores the item — must distribute evenly to avoid hot partitions

• Sort Key (SK / RANGE key): secondary part of composite key — enables range queries within a partition

• Single-table design: store all entities in one table using PK/SK patterns — the recommended approach for most DynamoDB apps

Primary Key Design

The most important design decision in DynamoDB. Poor key design causes hot partitions (throttling) and missing access patterns.

Single-table design example — e-commerce app

PK              SK                  Attributes
-----------     -----------------   ------------------------------------
USER#alice      PROFILE             name, email, createdAt
USER#alice      ORDER#2026-001      total, status, items
USER#alice      ORDER#2026-002      total, status, items
PRODUCT#widget  METADATA            name, price, stock
PRODUCT#widget  REVIEW#alice        rating, comment
ORDER#2026-001  ITEM#1              productId, qty, price

Access patterns this supports:
  - Get user profile:        PK=USER#alice, SK=PROFILE
  - Get all orders for user: PK=USER#alice, SK begins_with ORDER#
  - Get single order:        PK=USER#alice, SK=ORDER#2026-001
  - Get product metadata:    PK=PRODUCT#widget, SK=METADATA
  - Get product reviews:     PK=PRODUCT#widget, SK begins_with REVIEW#

Capacity Modes

• On-demand: pay per request (read/write units) — no capacity planning, auto-scales instantly

• Provisioned: specify RCUs and WCUs in advance — cheaper at predictable load, can use auto-scaling

• RCU (Read Capacity Unit): 1 strongly consistent read of ≤4KB, or 2 eventually consistent reads

• WCU (Write Capacity Unit): 1 write of ≤1KB per second

• Burst capacity: DynamoDB retains up to 5 minutes of unused capacity for bursts

• Hot partitions: if one partition key receives >1000 WCU or 3000 RCU, it throttles — design PKs to distribute load

Consistency Models

• Eventually consistent reads (default): may return stale data — costs 0.5 RCU per 4KB

• Strongly consistent reads: always returns latest data — costs 1 RCU per 4KB, higher latency

• Transactional reads/writes: ACID guarantees across multiple items — costs 2x RCU/WCU

• Use strong consistency for: financial data, inventory, any case where stale data causes bugs

• Use eventual consistency for: read-heavy dashboards, feeds, analytics