Cassandra
A distributed wide-column store designed for high write throughput and availability across data centers, with no single point of failure. It uses partitioned rows and tunable consistency. You model queries first.
- Time-series, event logs, write-heavy multi-DC workloads.
- When availability > consistency.
- Workloads needing joins or flexible queries.
- Small datasets where Postgres is simpler.
Definition
Cassandra is a masterless, partitioned row store using a partition key to distribute data and a clustering key to order rows within a partition. Consistency is tunable per query (ONE/QUORUM/ALL). Writes append to an immutable SSTable via a commitlog and memtable.
Why it exists
For write-heavy, always-on workloads across multiple data centers where relational DBs can't scale horizontally and downtime is unacceptable. It trades query flexibility for scale and availability.
How it works
Write to memtable + commitlog; flush to SSTable; compaction merges them. Reads reconcile multiple replicas per consistency level. Replication factor and consistency level set the read/write tradeoff. No joins; denormalize for each query.
Scaling limits
Only partition-key and clustering-key queries; no ad-hoc joins or secondary indexes at scale. Tombstones from deletes hurt reads. Hot partitions if the partition key is skewed. Compaction strategy tuning is critical.
Cost shape
Self-hosted: many nodes for RF and throughput. Cheap storage (commodity disks). Blow-ups: over-replication, tombstone-heavy reads, and wide partitions.
Alternatives
- DynamoDB — Managed equivalent, less control, AWS-only.
- ScyllaDB — C++ rewrite with much better throughput per node.
Failure modes
- Wide partitions causing hot nodes and timeouts.
- Tombstone build-up slowing reads.
- Inconsistent schema across nodes.