DynamoDB

Key features

• Partition key alone: must be unique per item. Composite key (partition + sort): partition key can repeat, but the pair must be unique
• Query: efficient, uses the key structure directly. Scan: reads the entire table (or index), filtering happens after the read — expensive at any real table size
• GSI: its own partition/sort key, queryable independently — can be added after table creation, up to 20 per table by default
• LSI: shares the base table's partition key with a different sort key — must be created at table creation time, up to 5 per table
• Every partition delivers up to 3,000 read units and 1,000 write units per second — a single item's size determines exactly how many units each operation consumes
• DynamoDB Streams captures item-level change events (before/after images), retained for 24 hours — often consumed via a Lambda trigger

Signature

Query (key-based, cheap) vs Scan (full read, expensive) · GSI (own key, anytime) vs LSI (shared key, at creation)

Key features

• Single-table design uses generic attribute names (PK, SK) with prefixed values (USER#, ORDER#) to store multiple entity types in one table
• It works by pre-computing every known access pattern into the key structure and a small number of GSIs, fetched with one Query instead of multiple round trips
• It requires access patterns to be known upfront — DynamoDB has no ad hoc joins, so an unanticipated query pattern often means a costly Scan or a redesign
• A relational database fits better when query patterns are genuinely ad hoc/evolving, or when multi-entity ACID transactions and complex joins are core requirements

Command

PK: USER#123      SK: PROFILE       → user profile item
PK: USER#123      SK: ORDER#456     → one of that user's orders, same partition

Key features

• Every partition is capped at 3,000 read units and 1,000 write units per second, regardless of the table's overall provisioned or on-demand capacity
• A hot partition occurs when a disproportionate share of traffic concentrates on one partition key value
• Adaptive capacity automatically and transparently shifts throughput toward frequently-accessed partitions to absorb moderate imbalance
• Larger items consume more units per operation — a 20 KB item consumes 5x the read units of a 4 KB item for the same read type
• Access-pattern-first design (choosing a partition key that spreads load, before choosing anything else) is the primary defense — adaptive capacity is a mitigation, not a substitute for it

Command

Partition key with even value distribution → load spreads across many partitions
Partition key with a dominant/popular value → hot partition, throttling below table capacity

Key features

• TransactWriteItems: up to 100 actions, up to 4 MB aggregate, all-or-nothing, serializable isolation
• Every item in a transaction consumes capacity twice — once to prepare, once to commit — even if the transaction is ultimately canceled
• ConditionExpression on a plain PutItem/UpdateItem enables optimistic concurrency (e.g. "only update if version = 5") without transaction overhead
• Transactions provide ACID guarantees only within a single Region — not supported across Regions in global tables
• AWS's own best practice: avoid grouping operations into a transaction unless correctness genuinely requires it — simpler transactions have higher throughput and success rates

Command

ConditionExpression "version = :expected"   → cheap optimistic concurrency, single item
TransactWriteItems [{Put...}, {Update...}]  → all-or-nothing across multiple items, 2x capacity cost