DynamoDB basics: NoSQL on AWS and when to reach for it

DynamoDB rewards designing around your access patterns up front and punishes designing it like a relational database — no JOINs, no flexible ad-hoc queries, and a primary key structure that has to be decided correctly before you have much data in the table at all.

Intermediate

4 min read

The mental model shift: design for access patterns, not entities

A relational database schema starts from "what are the entities and their relationships" (users, orders, products) and lets you query them flexibly afterward with JOINs and WHERE clauses. DynamoDB inverts this: you design the table starting from the specific queries your application will actually run, because the key structure you choose determines what's efficiently queryable — and unlike RDS, there's no JOIN to fall back on if you guessed wrong.

Partition keys and sort keys: the two-part primary key

Every DynamoDB table has a partition key (required) and optionally a sort key, together forming the primary key:

Partition key only: each item is looked up directly by an exact partition key value — like a dictionary lookup.
Partition key + sort key: items sharing the same partition key are grouped together and sorted by the sort key — enabling "give me all items for this partition key, in this key range" queries.

Table: Orders
  Partition key: customerId
  Sort key: orderDate

customerId=alice, orderDate=2024-01-15  -> {order details}
customerId=alice, orderDate=2024-03-02  -> {order details}
customerId=bob,   orderDate=2024-02-10  -> {order details}

A query for customerId = "alice" efficiently returns all of Alice's orders, sorted by date, without scanning the whole table — because DynamoDB physically partitions data by the partition key, and sorts within each partition by the sort key.

Query vs Scan: the difference that determines whether your table scales

Query: looks up items by partition key (and optionally a sort key condition) — efficient, uses the table's actual index structure, cost scales with the size of the result set.
Scan: reads every item in the entire table, then optionally filters — cost scales with the size of the whole table, regardless of how few items match the filter.

# Query — efficient, uses the partition key directly
response = table.query(
    KeyConditionExpression=Key('customerId').eq('alice')
)
 
# Scan — reads the entire table, then filters; avoid this at any real scale
response = table.scan(
    FilterExpression=Attr('customerId').eq('alice')
)

A table that works fine in development with 50 items and falls over in production with 5 million is, overwhelmingly often, a table being Scanned instead of Queried — the access pattern that looked fine at small scale was never actually efficient, it just wasn't big enough yet to expose the cost.

Secondary indexes: querying by something other than the primary key

A Global Secondary Index (GSI) lets you query by a different attribute than the table's primary partition/sort key, at the cost of additional storage and (for provisioned-capacity tables) its own throughput:

resource "aws_dynamodb_table" "orders" {
  name         = "Orders"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "customerId"
  range_key    = "orderDate"
 
  attribute {
    name = "customerId"
    type = "S"
  }
  attribute {
    name = "orderDate"
    type = "S"
  }
  attribute {
    name = "status"
    type = "S"
  }
 
  global_secondary_index {
    name            = "StatusIndex"
    hash_key        = "status"
    projection_type = "ALL"
  }
}

This adds an efficient "find all orders with status = X, across all customers" query path, without which that same query would require a full table Scan.

Capacity modes: provisioned vs on-demand

Provisioned capacity: you specify read/write capacity units upfront (cheaper at steady, predictable load, but under-provisioning causes throttled requests).
On-demand (PAY_PER_REQUEST): pay per actual request, scales automatically with no capacity planning — simpler and safer for unpredictable or new workloads, generally more expensive per-request at sustained high volume.

This is the same on-demand-vs-reserved trade-off from the Cloud Computing domain's pricing-models lesson, applied specifically to DynamoDB's own capacity model: start on-demand while traffic patterns are unknown, consider provisioned capacity once usage is predictable enough to forecast confidently.

When DynamoDB is the right choice, and when RDS still is

DynamoDB fits well when: access patterns are known and stable, data is naturally key-value or hierarchical (a user's own data, a session store, a shopping cart), and the workload needs to scale to very high request volumes with predictable low latency. RDS fits better when: the data genuinely needs flexible, ad-hoc querying (reporting, analytics with unpredictable filter combinations), relationships between entities are complex and JOIN-shaped, or the team's query patterns are still actively evolving and locking in a key structure prematurely would be costly to redo.

DynamoDB basics: NoSQL on AWS and when to reach for it

Intermediate

4 min read

The mental model shift: design for access patterns, not entities

Partition keys and sort keys: the two-part primary key

Every DynamoDB table has a partition key (required) and optionally a sort key, together forming the primary key:

Partition key only: each item is looked up directly by an exact partition key value — like a dictionary lookup.
Partition key + sort key: items sharing the same partition key are grouped together and sorted by the sort key — enabling "give me all items for this partition key, in this key range" queries.

Table: Orders
  Partition key: customerId
  Sort key: orderDate

customerId=alice, orderDate=2024-01-15  -> {order details}
customerId=alice, orderDate=2024-03-02  -> {order details}
customerId=bob,   orderDate=2024-02-10  -> {order details}

Query vs Scan: the difference that determines whether your table scales

Query: looks up items by partition key (and optionally a sort key condition) — efficient, uses the table's actual index structure, cost scales with the size of the result set.
Scan: reads every item in the entire table, then optionally filters — cost scales with the size of the whole table, regardless of how few items match the filter.

# Query — efficient, uses the partition key directly
response = table.query(
    KeyConditionExpression=Key('customerId').eq('alice')
)
 
# Scan — reads the entire table, then filters; avoid this at any real scale
response = table.scan(
    FilterExpression=Attr('customerId').eq('alice')
)

Secondary indexes: querying by something other than the primary key

resource "aws_dynamodb_table" "orders" {
  name         = "Orders"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "customerId"
  range_key    = "orderDate"
 
  attribute {
    name = "customerId"
    type = "S"
  }
  attribute {
    name = "orderDate"
    type = "S"
  }
  attribute {
    name = "status"
    type = "S"
  }
 
  global_secondary_index {
    name            = "StatusIndex"
    hash_key        = "status"
    projection_type = "ALL"
  }
}

This adds an efficient "find all orders with status = X, across all customers" query path, without which that same query would require a full table Scan.

Capacity modes: provisioned vs on-demand

Provisioned capacity: you specify read/write capacity units upfront (cheaper at steady, predictable load, but under-provisioning causes throttled requests).
On-demand (PAY_PER_REQUEST): pay per actual request, scales automatically with no capacity planning — simpler and safer for unpredictable or new workloads, generally more expensive per-request at sustained high volume.

DynamoDB basics: NoSQL on AWS and when to reach for it

The mental model shift: design for access patterns, not entities

Partition keys and sort keys: the two-part primary key

Query vs Scan: the difference that determines whether your table scales

Secondary indexes: querying by something other than the primary key

Capacity modes: provisioned vs on-demand

When DynamoDB is the right choice, and when RDS still is

Further reading

DynamoDB basics: NoSQL on AWS and when to reach for it

The mental model shift: design for access patterns, not entities

Partition keys and sort keys: the two-part primary key

Query vs Scan: the difference that determines whether your table scales

Secondary indexes: querying by something other than the primary key

Capacity modes: provisioned vs on-demand

When DynamoDB is the right choice, and when RDS still is

Further reading