ClickHouse and Cassandra get compared often because both are distributed, both store data in columns in some sense, and both handle enormous write volumes. But the comparison is mostly a category error. ClickHouse is an OLAP column store built to scan billions of rows and aggregate them in milliseconds. Cassandra is a wide-column store built to serve millions of point reads and writes per second by partition key, across datacenters, with no single point of failure. They are not competing answers to the same question - they are answers to different questions, and the fastest way to a bad architecture is picking one to do the other's job.
Two Different Data Models
Despite the "column" terminology, the storage models diverge completely. ClickHouse is truly columnar: each column of a MergeTree table is stored as its own compressed file, data is physically sorted by an ordering key, and a sparse primary index with one mark per 8,192-row granule lets queries skip irrelevant data and scan only the columns they touch. The design goal is throughput per query: read a few columns across billions of rows, aggregate with vectorized SIMD execution, return in milliseconds.
Cassandra's "wide-column" model is row-oriented within partitions. Data is distributed across the cluster by consistent hashing of a partition key, and within each partition, rows are stored sorted by clustering columns. The storage engine is a log-structured merge tree: writes land in a commit log and memtable, then flush to immutable SSTables that compact in the background. That makes writes extremely cheap - effectively sequential appends - and point reads by partition key fast and predictable. The design goal is operations per second: locate one partition, read or write a bounded set of rows, at single-digit-millisecond latency, forever, regardless of total data size.
The irony is that both engines are LSM-shaped underneath (ClickHouse parts and merges, Cassandra SSTables and compaction). Similar bones, opposite optimization targets: ClickHouse organizes data for scans across keys, Cassandra for lookups within a key.
Consistency and Replication
Cassandra's replication story is its crown jewel. Every node is a peer - there are no primaries - and each write goes to N replicas per the keyspace's replication strategy, including rack- and datacenter-aware placement. Consistency is tunable per query: a client can demand ONE, QUORUM, LOCAL_QUORUM, or ALL acknowledgments, trading latency against consistency on each read and write. With LOCAL_QUORUM in each datacenter, Cassandra delivers genuine multi-DC active-active writes: users in Europe and the US both write locally, and replication converges in the background with mechanisms like hinted handoff and read repair. This is why Apple runs tens of thousands of Cassandra nodes, Netflix keeps petabytes in it, and Discord stores billions of messages in it - workloads where write availability across regions is non-negotiable.
ClickHouse replication is narrower in ambition. ReplicatedMergeTree replicates asynchronously and multi-master per table, coordinated through ClickHouse Keeper: an insert commits on one replica and ships to the others in the background (a insert_quorum setting exists for synchronous acknowledgment, at a latency cost). This is fine for analytics, where losing a second of replication lag matters little, but ClickHouse has nothing like per-query tunable consistency or first-class multi-region active-active semantics. If cross-datacenter write availability with predictable conflict handling is a requirement, Cassandra wins outright.
Query Capabilities
Here the advantage flips completely. ClickHouse speaks full analytical SQL: joins of all types, subqueries, CTEs, window functions, and hundreds of aggregate and approximate functions, executed with vectorized brute force. A query like "daily p95 latency per service over the last 90 days, joined against a deployments table" is a single fast statement over raw events.
CQL looks like SQL but is deliberately restricted to what a distributed key-value store can do efficiently. Queries must generally filter by partition key; filtering on arbitrary columns requires an index or the explicitly discouraged ALLOW FILTERING, which degrades to a cluster-wide scan. There are no joins, and aggregations across partitions mean touching every node - Cassandra's own documentation steers you toward denormalizing one table per query pattern instead. Cassandra 5.0's storage-attached indexes (SAI) meaningfully improve filtering on non-key columns, and 5.0 added vector search as well, but none of this turns Cassandra into an analytics engine. Historically, teams bolted Spark on top of Cassandra for analytics - which is exactly the sign that the analytical workload belongs in a different system.
When Cassandra Wins
Pick Cassandra when the workload is operational: sustained high-throughput writes with strict low-latency point reads by key. Session stores, user profiles, device state, messaging inboxes, shopping carts, time-ordered feeds read per user. Its linear write scalability, masterless topology, and multi-DC active-active replication are unmatched in ClickHouse, and its latency stays flat as row counts grow into the trillions because reads never depend on total dataset size, only partition size. ClickHouse is actively wrong for this shape of workload: it has no fast update-by-key path, point lookups waste a scan-oriented engine, and frequent small single-row writes fight the MergeTree design, which wants large batched inserts.
When ClickHouse Wins
Pick ClickHouse when the workload is analytical: aggregations, group-bys, time-series rollups, funnels, percentiles, ad hoc slicing over large event streams. On this shape, the difference is structural, not incremental - Cassandra must read entire partitions row by row across nodes, while ClickHouse reads only the referenced columns, compressed and sorted, often skipping most granules entirely. Observability and event analytics at Cloudflare and OpenAI run on ClickHouse for exactly this reason. Features like materialized views for continuous rollups and TTL-based tiering make it a natural home for metrics and logs. Using Cassandra for dashboard-style aggregation queries is a well-worn path to pain.
When to Choose Which
| Dimension | ClickHouse | Cassandra |
|---|---|---|
| Category | OLAP columnar database | Wide-column OLTP / key-value store |
| Optimized for | Scans and aggregations over many rows | Point reads/writes by partition key |
| Write pattern | Large batched inserts | Millions of small writes per second |
| Updates by key | Awkward (ReplacingMergeTree, mutations) | Native, cheap |
| Query language | Full SQL with joins, window functions | CQL, no joins, partition-key-first |
| Consistency | Async replication, eventually consistent replicas | Tunable per query (ONE to ALL) |
| Multi-DC active-active | Not a first-class pattern | Core strength |
| Analytics at scale | Core strength | Requires external engines (e.g. Spark) |
| Typical use | Logs, metrics, events, BI, user-facing analytics | Profiles, sessions, messaging, device state |
Using Both Together
Because the systems are complementary, running both is a common and sound pattern: Cassandra serves the operational path (current state by key, user-facing reads and writes), while the same event stream - usually via Kafka or CDC - lands in ClickHouse for aggregation, dashboards, and retention-heavy history. Each system does the job it was built for, and neither is forced into its worst-case access pattern.
There is even a small direct integration: ClickHouse can use Cassandra as a dictionary source, letting ClickHouse queries enrich analytical rows with reference data read from a Cassandra table. It is a convenience for lookups, not a replication mechanism - for the full events-to-analytics flow you still want a streaming pipeline - but it underlines that the two are more often neighbors than rivals.
The Bottom Line
This is not a benchmark contest; it is a categorization exercise. If your queries start with "get/set this key" and your constraints include multi-region write availability, Cassandra is the right tool and ClickHouse is not a substitute. If your queries start with "aggregate these events" and your constraints include sub-second dashboards over billions of rows, ClickHouse is the right tool and Cassandra will fight you at every step. Teams that find themselves choosing between the two usually have both workloads - and the honest answer is one of each, connected by a stream.
