Wide-Column NoSQL
Rows indexed by a partition key, with potentially millions of columns per row, optimized for huge time-series and append-heavy workloads.
What it is
Wide-column stores (Cassandra, ScyllaDB, HBase, BigTable) organize data as rows where each row can have a different set of columns, grouped into column families. The data is partitioned by a hash of the partition key and sorted within partitions by clustering columns. The storage engine is typically an LSM (Log-Structured Merge-tree), optimized for high write throughput. The query model is restricted: you can only efficiently query by partition key and range-scan within a partition. Despite the name, it's not really a column store (those are analytical — Parquet, ClickHouse).
Why senior interviewers ask
Wide-column stores are the right answer for a narrow set of problems (massive time-series, append-only event logs) and the wrong answer for almost everything else. Knowing which is a senior signal.
Key points
- Partition key determines node placement; clustering columns determine sort order within a partition.
- LSM-tree storage: writes are extremely fast, reads can require merging multiple SSTables.
- No joins, no secondary indexes worth using (Cassandra's secondary indexes are anti-patterns at scale).
- Tunable consistency per query (Cassandra: ONE, QUORUM, ALL).
- Compaction is the operational tax — tuning it badly destroys performance.
- Wide rows model time-series naturally: partition key = sensor_id, clustering key = timestamp.
- Eventually consistent by default in Dynamo-lineage systems (Cassandra, ScyllaDB).
Pros
- Linear write scalability — add nodes, throughput grows linearly.
- Massive datasets (petabytes) on commodity hardware.
- Tunable consistency lets you pick per-query.
- Natural fit for time-series and event logs.
- No single point of failure (leaderless in Cassandra-style systems).
Cons
- Query model is restrictive — you must design tables per access pattern.
- Bad partition key choice creates hot partitions that throttle the whole cluster.
- Operating Cassandra at scale is genuinely hard (compaction, repairs, GC tuning).
- Read amplification from LSM SSTables can hurt p99 latency.
- Multi-partition transactions are basically not a thing.
When to choose
- Time-series at massive scale (IoT sensor data, metrics, telemetry).
- Append-heavy event logs with simple read patterns.
- Activity feeds, message timelines, audit logs.
- Workloads where write throughput >> read complexity.
When to avoid
- Anything requiring ad-hoc queries or joins.
- Small teams without distributed-systems operational expertise.
- Strongly consistent multi-row transactions.
- Workloads where reads dominate and need sub-millisecond latency on arbitrary fields.
Real systems
Interview probe
'How would you pick the partition key for your Cassandra table?' Answer: name the access pattern, ensure cardinality is high enough to spread load, and verify no single key gets disproportionate traffic. Hot partitions are the #1 cause of Cassandra outages.