AWS DynamoDB: Keys, GSIs & Single-Table Design

Q: Query or Scan?

Always prefer Query, which targets a partition via the key and reads only matching items. Scan reads the entire table and is slow and costly at scale — design your keys and GSIs so you never need it for normal access.

AWS DynamoDB

DynamoDB is AWS's fully managed NoSQL database, delivering consistent single-digit-millisecond performance at virtually any scale with no servers to manage. It's a favorite for serverless architectures because it scales seamlessly and bills per request or capacity.

The mental shift is the hard part: DynamoDB is not "serverless SQL." You design the table around the exact access patterns you'll run, and the partition key is the most consequential decision you'll make.

TL;DR

Fully managed; predictable performance at scale, ideal for serverless.
Design for key-based access — your partition key choice is critical.
Model around known query patterns (single-table design is common).
Use GSIs for alternate access patterns; Query, never Scan, for reads.

Quick Example

You fetch by key, not by arbitrary filters — Query targets a partition efficiently:

Core Concepts

Table / item — a table holds items (records of attributes).
Partition key — hashes to distribute data; determines which partition stores an item.
Sort key — optional; orders items within a partition and enables range queries.
GSI (Global Secondary Index) — an alternate key schema for other access patterns.

Data Modeling

Start from access patterns, not entity diagrams — list every query first.
Single-table design is common: multiple entity types share one table, keyed for each query.
Use GSIs to support queries the main key can't.
Keep items small and bounded; avoid attributes that grow without limit.

Best Practices

Choose partition keys that spread load — avoid hot keys that throttle.
Use on-demand capacity for spiky/unknown traffic, provisioned for steady, predictable load.
Use TTL to auto-expire ephemeral data.
Plan backups (point-in-time recovery) — managed doesn't mean automatic DR.

Comparison: DynamoDB vs a relational DB

Common Mistakes

Scanning instead of querying

Hot partitions

FAQ

When should I use DynamoDB?

For workloads with well-known access patterns that need to scale seamlessly with minimal ops — session stores, user profiles, high-scale key-value access, and serverless apps. If you need flexible ad-hoc queries or rich relationships, a relational database is a better fit.

Why is the partition key so important?

It decides how data is distributed across partitions and how you read it back. A good key spreads load evenly and matches your queries; a poor one creates hot partitions that throttle and forces expensive scans. You can't easily change it later.

What is single-table design?

A DynamoDB pattern where multiple entity types live in one table, with composite keys crafted so each access pattern is a single efficient query. It minimizes round trips and cost but requires upfront modeling of all your queries.

Query or Scan?

Always prefer Query, which targets a partition via the key and reads only matching items. Scan reads the entire table and is slow and costly at scale — design your keys and GSIs so you never need it for normal access.