DynamoDB and Cassandra

DynamoDB and Cassandra descend from the same idea: a table whose primary key decides placement, replicated with a quorum, able to take writes on many nodes. You talk to them when the access pattern is known and the write rate will not fit one Postgres primary. You do not talk to them because NoSQL sounds scalable.

Model the query first

The partition key is the unit of placement and the unit of hotness. All items with that key live together. A sort key orders items inside the partition (DynamoDB) or forms the rest of the primary key (Cassandra clustering columns).

Example: messages partitioned by conversation_id, sorted by sent_at. Loading a conversation is one partition read. Loading a user’s inbox is a different query and a different table, inbox_by_user, that you write at send time. If you do not want to write that second table, you do not get that query.

Cassandra secondary indexes and DynamoDB GSIs can serve another pattern. A GSI is another table Amazon maintains, with its own capacity and its own lag. A hot GSI key is a hot partition you do not control as directly. Prefer an explicit table when the second pattern is hot.

Consistency and contention

Default reads can be stale. Ask for a strongly consistent read when the next screen must show the write, and pay the latency. Conditional writes (attribute_not_exists, compare-and-set) are how you implement idempotency and optimistic concurrency. They are not a general multi-row transaction. DynamoDB transactions exist across items in one account and have a size and cost limit. Cassandra lightweight transactions use Paxos and are much slower than a normal write. Say the limit if you rely on them.

Counters need a counter type or an event log you sum. Last-writer-wins on a numeric column drops increments.

Capacity

DynamoDB will throttle a single partition well before the table’s nominal throughput is exhausted. Cassandra will too, in practice, because one key’s replicas are three machines, not the cluster. When a key is hot, write key#bucket and merge, or queue in front of that key.

Neither store is a good home for a query you invent next month. If the product is still discovering its queries, stay on Postgres.