Concepts · Concept

Dynamo db

**
**Partitionkey - hashed to determine which physical partition/node holds the item, and DynamoDB stores all items sharing the same partition key value together, contiguously, on the same partition.

DynamoDB is a fully-managed, horizontally-scalable key-value/document store from AWS. Every item is addressed by a partition key (plus an optional sort key), and the partition key is hashed to determine which physical partition stores that item — items sharing the same partition key live together, contiguously, sorted by sort key if one exists. This means: a lookup by exact partition key is fast and targeted (no scan), and if there’s a sort key, you can efficiently range-query within that partition. It scales horizontally by adding more partitions, and gives you either eventually-consistent or strongly-consistent reads, plus optional transactions across items.

Dynamo vs postgres example:
“The access pattern here is high-frequency, simple key-based reads and writes — 500M score updates/day, plus constant lookups by player ID and a ‘top 100’ query — with no joins or relational complexity anywhere. That requires horizontal write scale as a first-class capability. DynamoDB fits natively: it partitions data across nodes automatically based on partition key, so throughput scales by just adding capacity. Postgres, by contrast, is a single-node relational engine at its core — to handle this volume, I’d have to manually shard it myself: pick a shard key, build application-level routing logic, and deal with resharding pain if one shard gets hot (e.g., a viral player). That’s real engineering overhead DynamoDB gives you for free, since horizontal scaling isn’t Postgres’s core design center — ACID transactions and relational querying are, and this scenario doesn’t need either.”

Note: when any two DB tiebreaker

When both DBs technically satisfy the requirements, the tiebreaker is usually operational — do you want AWS managing this for you, or do you specifically need Cassandra’s extra query flexibility / multi-datacenter write story badly enough to take on the ops burden