Wide-Column Stores

Bigtable lineage

Google Bigtable (2006) established the wide-column model: sparse billions of rows, columns grouped in column families, sorted by row key within a tablet. Cassandra, HBase, and Scylla inherit this design.

Row key → { column_family:qualifier → timestamped cell value }

Not SQL "columns" — more like a sorted map of maps per row.

Partition key and clustering

In Cassandra:

• Partition key — hashes to a token range, determines which nodes store the row
• Clustering columns — sort order within the partition

All rows sharing a partition key live on the same replica set — colocation enables efficient range scans inside one partition.

Query-first data modeling

You design tables around queries, not entities. Denormalization is normal — multiple tables for different access paths (events_by_user, events_by_device).

Anti-pattern: ALLOW FILTERING or queries without partition key → full cluster scan.

LSM under the hood

Cassandra/Scylla use LSM trees (SSTables + memtable). Writes are append-fast; reads may touch multiple SSTables until compaction. Tunable via compaction strategy (Size-Tiered, Leveled, Time-Window).

Tunable consistency (N, R, W)

Per-operation:

• N — replicas participating
• W — write acks required
• R — read responses required

When R + W > N, you often get strong read-your-writes (with caveats for concurrent writers — see Distributed Systems → Quorums).

Wide rows vs normalization

A partition can hold millions of clustering rows (time-series). Keep partitions bounded — hot partitions are the wide-column equivalent of a bad shard key.

vs document stores

	Document (MongoDB)	Wide-column (Cassandra)
Default unit	Whole JSON document	Row with sorted columns
Schema	Flexible per doc	Defined per column family
Cross-partition query	Possible, slower	Discouraged by design
Best fit	Rich objects, secondary indexes	Write-heavy, time-series, KV-at-scale

Senior-level signal

Choosing Cassandra for a workload needing ad-hoc cross-partition joins is a category error. Ask: "What's the partition key on every query?"

Where this goes next

Key-Value & Specialized Stores — when even the column model is too much structure.