Tables, Items, and Primary Keys

Amazon DynamoDB is a fully managed, serverless key-value and document database designed for single-digit millisecond performance at any scale. Unlike relational databases, DynamoDB is schema-less—each item can have a different set of attributes as long as the primary key is present.

DynamoDB stores data in tables, which are the top-level container analogous to a SQL table. Tables are spread across multiple storage nodes across AZs automatically, providing built-in redundancy without any configuration required from you.

A DynamoDB table holds a collection of items, each of which is a collection of attributes. Attributes are typed values: String (S), Number (N), Binary (B), Boolean (BOOL), Null (NULL), List (L), Map (M), and Set types (SS, NS, BS).

Every item in a table must include the primary key attributes—all other attributes are optional and can differ between items. A single item can be at most 400 KB in size, including all its attribute names and values.

A simple primary key consists of a single attribute called the partition key (also called the hash key). DynamoDB applies an internal hash function to the partition key value to determine which storage partition holds the item. All items with the same partition key value are stored together.

With a simple primary key, no two items in the table can have the same partition key value—it uniquely identifies each item. This design suits tables where you always access data by a unique identifier, such as a user ID or order ID.

A composite primary key uses both a partition key and a sort key (also called the range key). Items with the same partition key are stored together and sorted by the sort key value, enabling range queries within a partition.

This design is extremely flexible: multiple items can share the same partition key as long as their sort keys differ. For example, a Orders table might use CustomerId as partition key and OrderDate as sort key, allowing you to query all orders for a customer sorted by date.

Choosing the right partition key is the most important DynamoDB design decision. A good partition key has high cardinality (many distinct values) and distributes access evenly across partitions. Poor choices lead to hot partitions where one partition receives disproportionate traffic, causing throttling.

Anti-patterns to avoid: using a boolean flag (only two values), a date that groups all today's writes together, or a low-cardinality status field. Good choices: user ID, device ID, random UUID, or composite values like tenantId#entityType.

The three fundamental DynamoDB item operations are:

• PutItem: writes a new item or completely replaces an existing one with the same primary key
• GetItem: retrieves a single item by its exact primary key (requires the full key—partition key and, if composite, sort key)
• DeleteItem: removes an item by its exact primary key

All three operations are atomic at the item level. By default, GetItem uses eventually consistent reads; adding --consistent-read forces a strongly consistent read that always returns the latest written value.

UpdateItem modifies specific attributes of an existing item without replacing it entirely, unlike PutItem. You can add attributes, remove attributes, or perform arithmetic on Number attributes atomically (e.g., increment a counter).

Conditional expressions let you specify that an operation should only succeed if a condition is true. For example, only update an item's status if it is currently PENDING. This implements optimistic locking patterns without transactions and is a key DynamoDB design technique.

Query retrieves items that share the same partition key value, optionally filtered by sort key conditions. Query is efficient—it reads only the targeted partition. You can use sort key conditions like begins_with, between, =, <, > to narrow results within the partition.

Scan reads every item in the table and then applies an optional filter expression. Scans are expensive for large tables and should be avoided in production query patterns. If you find yourself needing frequent Scans, reconsider your table design or add a Global Secondary Index.

DynamoDB stores three copies of your data across multiple AZs. Eventually consistent reads (the default) may return a slightly stale value if a recent write has not propagated to all copies yet—but they consume half the read capacity units of strongly consistent reads.

Strongly consistent reads always return the latest committed write but cost twice the RCUs and are not available on Global Secondary Indexes. Choose eventually consistent reads for high-throughput read-heavy workloads and strongly consistent reads only when your application requires the absolute latest data.

DynamoDB supports ACID transactions via TransactWriteItems and TransactGetItems. A transaction can group up to 100 write operations across multiple items and even multiple tables, ensuring all succeed or all are rolled back atomically.

Use transactions for scenarios like transferring money between accounts (debit one item, credit another) or booking a seat (check availability and reserve it atomically). Transactions cost twice the normal RCUs/WCUs, so use them only when atomicity across multiple items is genuinely required.

DynamoDB's 400 KB per-item limit influences data modelling. For large payloads (e.g., images, large documents), store the binary data in S3 and store only the S3 object key in DynamoDB. For deeply nested hierarchical data, model each node type with its own partition key pattern using single-table design—one table holds multiple entity types differentiated by the partition key prefix and sort key pattern.

Single-table design minimises the number of tables and enables efficient access patterns by co-locating related items in the same partition. It is an advanced technique that reduces operational overhead and improves performance for complex access patterns.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: DynamoDB tables hold schema-less items limited to 400 KB, simple primary keys use a partition key alone while composite keys add a sort key for range queries, and high-cardinality partition keys prevent hot partitions. Use Query instead of Scan for efficient access. Next up we explore provisioned vs on-demand capacity modes.