Cassandra

- provide eventual consistency

-durable high-throughput writes

- its write path — CommitLog + Memtables + SSTables — is optimized to absorb writes fast, unlike Postgres where every write also has to maintain indexes/constraints/WAL in a way that’s comparatively write-heavier per operation at this volume)

-Cassandra is fast at reading a single partition; it’s not designed for atomically checking-and-writing across two different partitions in one guaranteed-consistent operation

-Cassandra does support atomic operations within a single partition via lightweight transactions (LWT) — Paxos-based, linearizable, but only scoped to one partition.

Cassandra — how to describe it:

“Cassandra is a wide-column, horizontally-scalable NoSQL database, originally built at Facebook and inspired by the same Dynamo paper as DynamoDB. It’s self-managed (you run the cluster, or pay for a managed offering), queried via CQL — SQL-like syntax — and gives you fine-grained, per-query consistency tuning (ONE, QUORUM, ALL, etc.), plus native multi-datacenter active-active replication.”

When to reach for it:

• Very high, sustained write throughput with a simple, mostly key-based access pattern (e.g., 2B swipes/day in Tinder)
• You need more query flexibility than DynamoDB’s rigid partition-key model allows (secondary indexes, though used sparingly — idiomatic Cassandra design is “one table per access pattern” instead)
• You need native multi-region, multi-datacenter writes with tunable consistency per query — DynamoDB’s Global Tables can do multi-region too, but Cassandra’s story here is more mature/flexible
• You’re not on AWS, or specifically want to avoid vendor lock-in (open-source, portable)

Its weak spot: you own the operational burden — provisioning, scaling, patching, monitoring the cluster yourself, unlike DynamoDB’s fully-managed model.