StarRocks vs ClickHouse for Scalable Analytics Workloads
If you search for "StarRocks vs ClickHouse", most of what you find says the same thing: ClickHouse is the king of single-table scans, StarRocks is better at joins and concurrency. That summary was fair in 2022. In late 2026 it's only half true.
Over the last two years, ClickHouse shipped a cost-based join reorderer, column statistics by default, runtime join filters, join spilling and SQL UPDATEs. StarRocks, meanwhile, went all-in on the lakehouse with 4.0 and made shared-data clusters self-balancing in 4.1. Both systems moved toward each other, and a lot of the comparison articles still circulating were written before any of this happened.
In my Bloom filter series we zoomed into one data structure. This post zooms out. We'll compare the two systems along the axes that actually decide whether an analytics platform scales:
- Architecture and storage
- Scaling model: shared-nothing vs shared-data
- Joins and the query optimizer
- Concurrency and workload isolation
- Real-time ingestion and updates
- Materialized views and pre-aggregation
- Lakehouse and open table formats
- Benchmarks, and how to read them
- Operations
- A decision guide
Versions covered: ClickHouse 26.9 (released September 2026) and StarRocks 4.1 (released April 2026, patched through the summer). Both projects move fast, so check the release notes for anything newer.
At a glance
| ClickHouse | StarRocks | |
|---|---|---|
| Origin | Yandex (open-sourced 2016), now ClickHouse Inc. | Fork of Apache Doris (2020), now Linux Foundation project, backed by CelerData |
| Language / protocol | C++; own native protocol + HTTP, MySQL/PostgreSQL wire compatibility | C++ backend, Java frontend; MySQL protocol |
| Node types | One binary (clickhouse-server) + ClickHouse Keeper for coordination | FE (metadata, planning) + BE (storage + compute) or CN (stateless compute) |
| Core storage | MergeTree family: immutable sorted parts, background merges | Segments in tablets; Duplicate / Aggregate / Unique / Primary Key tables |
| Scaling (self-managed) | Shards + replicas, defined by you | Tablets distributed and rebalanced automatically |
| Separation of storage and compute | SharedMergeTree in ClickHouse Cloud; object storage disks self-managed | Shared-data mode (since 3.0), open source |
| Optimizer | Rule-based planner + statistics-based join reordering (default since 25.12) | Cascades-style cost-based optimizer from the start |
| Distributed joins | Parallel hash join, six join algorithms, runtime filters; distributed joins via GLOBAL JOIN / parallel replicas | Broadcast, shuffle, bucket shuffle, colocate joins; local and global runtime filters |
| Updates | Insert-based engines (ReplacingMergeTree, …) + lightweight UPDATE via patch parts (beta) | Primary Key table with Delete+Insert, partial column updates |
| Lakehouse | Iceberg, Delta, Hudi read/write via table functions and data lake catalogs | Iceberg, Hive, Hudi, Delta, Paimon catalogs; native Iceberg writes and compaction |
| Sweet spot | Huge append-heavy tables: logs, events, observability, time series | Star/snowflake schemas, customer-facing dashboards, CDC-fed data, lakehouse acceleration |
1. Architecture and storage
ClickHouse: the MergeTree
ClickHouse is, at its heart, a very efficient columnar storage engine with a query engine on top. Every INSERT creates an immutable, sorted part. Background merges combine parts into bigger ones, which is where deduplication (ReplacingMergeTree), pre-aggregation (AggregatingMergeTree, SummingMergeTree) and now update patches get applied.
Reads are driven by the ORDER BY key: a sparse primary index stores one entry per granule (8,192 rows), and skip indexes (minmax, set, Bloom filter, text) prune further. When people say "ClickHouse is fast", they mostly mean: if your filter matches your sort order, ClickHouse reads astonishingly little data, and when it does read, it reads fast.
Everything runs in a single binary. Coordination for replication lives in ClickHouse Keeper (a Raft-based ZooKeeper replacement). There's no separate "master" node that plans queries: whichever server receives the query becomes the initiator.
StarRocks: FE + BE/CN
StarRocks follows the classic MPP split:
- FE (Frontend), written in Java: metadata, SQL parsing, the cost-based optimizer, scheduling. FEs replicate metadata among themselves.
- BE (Backend) in shared-nothing mode, or CN (Compute Node) in shared-data mode, written in C++: vectorized execution, and in the BE case, storage.
Tables are partitioned (usually by date), then bucketed by hash into tablets, which are the unit of distribution, replication and balancing. Inside a tablet, data lives in columnar segments with a prefix (short key) index, zone maps, and optional Bloom filter, bitmap and inverted indexes. I covered this layout in Inside StarRocks Storage.
The table type is the most important design decision in StarRocks:
| Table type | Behavior | Typical use |
|---|---|---|
| Duplicate Key | Append-only, keeps every row | Logs, events |
| Aggregate Key | Rows with the same key are aggregated on write | Pre-aggregated metrics |
| Unique Key | Merge-on-read upserts (legacy) | Mostly superseded |
| Primary Key | Delete+Insert upserts with an in-memory PK index | CDC, mutable facts, dimensions |
What this means
Neither architecture is "better". ClickHouse is simpler to deploy for a single node and gives you very direct control over physical layout. StarRocks has more moving parts but those parts do more for you: metadata management, tablet placement, rebalancing and join planning are the system's job, not yours.
2. Scaling model: shared-nothing vs shared-data
This is where "scalable" really gets decided, and both systems now offer both models, with an important asymmetry.
Shared-nothing
ClickHouse (self-managed): you define a cluster in config, create a ReplicatedMergeTree table per shard and a Distributed table on top. You pick the sharding key and the number of shards. Adding shards later doesn't move existing data automatically; you rebalance yourself (or write new data with weights). This is predictable and fast, but scaling out is a project, not a button.
StarRocks (shared-nothing): BEs store tablets with multiple replicas. When you add a BE, the FE moves tablets to it in the background. Scaling out is closer to "add nodes and wait".
Shared-data (storage/compute separation)
StarRocks has supported shared-data clusters since 3.0, in the open-source edition. Data lives in object storage (S3, GCS, Azure Blob, MinIO) or HDFS; CNs are stateless and keep only a local cache of hot data. The StarRocks docs state that when the cache is hit, query performance is comparable to shared-nothing, and that CNs can be added or removed without data rebalancing.
StarRocks 4.1 (April 2026) addressed the biggest operational pain of shared-data clusters, which was picking bucket counts up front. Shared-data tables now support range-based distribution with automatic tablet splitting when tablets get too big or too hot, plus large-capacity tablets to cut the tablet count and FE metadata pressure. Tablet merging is shipped behind a config flag for now. In practice this means fewer "we chose the wrong bucket count two years ago" incidents in multi-tenant setups.
ClickHouse solves storage/compute separation with SharedMergeTree, but that engine is exclusive to ClickHouse Cloud (and first-party partner clouds). It keeps data and metadata in shared storage and Keeper, so replicas don't talk to each other, and a table can have hundreds of replicas without sharding. On top of it, ClickHouse Cloud offers compute-compute separation: separate compute groups (for example writers vs readers, or API vs analysts) on the same data.
Self-managed ClickHouse can store ReplicatedMergeTree parts on S3 disks, but each server still owns its own metadata, so you don't get the stateless, elastic behavior.
| ClickHouse | StarRocks | |
|---|---|---|
| Storage/compute separation, open source | Partial (S3 disks, stateful servers) | ✅ Shared-data mode |
| Storage/compute separation, managed | ✅ SharedMergeTree in ClickHouse Cloud | ✅ CelerData Cloud |
| Elastic scale-out without rebalancing | Cloud only | ✅ CNs are stateless |
| Workload groups on the same data | Compute-compute separation (Cloud) | Warehouses / resource groups |
| Automatic re-distribution as data grows | Not for self-managed shards | ✅ Tablet splitting (4.1, shared-data) |
My take: if you need elastic, object-storage-backed analytics and want to run it yourself, StarRocks' shared-data mode is the more complete open-source option. If you're happy on a managed service, ClickHouse Cloud's architecture is extremely mature, and the comparison becomes a pricing and features question.
3. Joins and the query optimizer
This is the section where most existing comparisons are out of date.
StarRocks: designed for joins from day one
StarRocks has had a cost-based optimizer since its early versions, with statistics collection, join reordering and a full menu of distributed join strategies:
- Broadcast join: replicate the small side to every node.
- Shuffle join: redistribute both sides by the join key.
- Bucket shuffle join: shuffle only one side when the other is already bucketed on the join key.
- Colocate join: no data movement at all, when both tables are bucketed identically in a colocation group.
Add local and global runtime filters (covered in Part 2 of the Bloom filter series) and you get a system where a normalized star schema just works. StarRocks 4.0 also added ASOF JOIN for time-series alignment.
ClickHouse: from "denormalize everything" to a real join optimizer
The old ClickHouse advice was: avoid joins, denormalize at ingestion time, use dictionaries for dimensions. Here's what changed (dates from the ClickHouse release blogs and their join engineering write-up):
| Version | Change |
|---|---|
| 24.12 | Parallel hash join becomes the default; automatic join reordering for two tables |
| 25.9 | Global join reordering for multi-table joins, driven by column statistics (statistics created manually at first) |
| 25.10 | Join runtime filters (Bloom filter / exact set pushed into the probe-side scan) |
| 25.12 | Join reordering on by default, up to 10 tables |
| 26.2 | Runtime filters on by default |
| 26.3 | Reordering extended to SEMI, ANTI and FULL OUTER joins |
| 26.4 | Column statistics collected by default on merges; hash joins can spill to disk |
| 26.8 | Statistics also collected on INSERT |
In late October 2026 ClickHouse also published details of a new DPsub-based cost-based join optimizer that handles non-inner joins. On TPC-H-style workloads, the ClickHouse team reports speedups of orders of magnitude from join reordering alone, compared with the naive written order.
So "ClickHouse can't join" is no longer true. On a single node or a single large server, a recent ClickHouse handles star-schema queries well.
Where the gap still is: distributed joins
The remaining difference is data movement across nodes. StarRocks' MPP engine has shuffle and colocate joins as first-class plan operators, chosen by the CBO. In self-managed ClickHouse, distributed joins mean either GLOBAL JOIN (broadcast the right side to all shards) or carefully co-sharded tables, and you decide which one. ClickHouse's parallel replicas and the newer automatic_parallel_replicas_mode help distribute heavy queries, but the shuffle-join toolbox is less mature than StarRocks'.
My take:
- Single node / ClickHouse Cloud, joins of moderate size: close to a tie in 2026.
- Many-table star or snowflake schemas, large fact-to-fact joins across a multi-node cluster: StarRocks is still the more predictable choice.
- Mostly wide, denormalized tables: ClickHouse, and the join question barely matters.
4. Concurrency and workload isolation
"Scalable" often means "1,000 people opened the dashboard at 9:00". This is about how many queries per second you can serve with stable latency, not how fast one query is.
Why the two differ
ClickHouse is optimized to throw all cores at one query. That's why single queries are so fast, but it also means many concurrent heavy queries compete for the same CPU. StarRocks' MPP engine with a pipeline execution model was built with many concurrent users in mind, and the FE-side planning gives it more room to cache and route.
ClickHouse's tools
- Workload scheduling with SQL (
CREATE RESOURCE,CREATE WORKLOAD): hierarchical workloads with priorities and weights for CPU, IO and query slots. Disabled by default, so you have to set it up. - Query-level limits:
max_threads,max_concurrent_queries, quotas, settings profiles. - Compute-compute separation in ClickHouse Cloud: isolate dashboards from ETL by giving them separate compute.
- Query result cache, projections and materialized views to make each query cheaper.
StarRocks' tools
- Resource groups: CPU, memory and concurrency limits per group, with classifiers by user, role, query type or source IP.
- Query queues: admit queries only when resources allow, instead of letting everyone fight.
- Query cache: caches intermediate aggregation results per tablet, so semantically overlapping queries reuse work, even when they aren't identical.
- Async materialized views with automatic query rewrite (see section 6), which turn many dashboard queries into cheap lookups.
Reading the claims carefully
Older StarRocks and CelerData material suggests ClickHouse clusters should stay under ~100 QPS, while StarRocks can serve thousands or even 10,000 concurrent queries. Third-party comparisons (e.g. Tinybird's) repeat that StarRocks holds sub-second P95 at far higher concurrency. These numbers come from vendors with a horse in the race and from older ClickHouse versions, before workload scheduling and Cloud compute groups matured.
What's still fair to say: out of the box, StarRocks gives you more concurrency controls and a planner designed for many small queries. ClickHouse can serve high-QPS workloads too (it powers plenty of customer-facing analytics), but it relies more on data modeling (projections, MVs, tight ORDER BY) and explicit workload configuration.
5. Real-time ingestion and updates
Ingestion
Both ingest millions of rows per second per node when you batch properly.
- ClickHouse: native
INSERT,async_insertfor many small writes, Kafka engine / ClickPipes, S3 queue engines. The golden rule: avoid many tiny inserts, or you'll get "too many parts". - StarRocks: Stream Load (HTTP), Routine Load (Kafka, including Kafka 4.0 in 4.0), Broker Load, Flink/Spark connectors, and Merge Commit to batch small writes into efficient transactions. StarRocks 4.0 also added multi-statement transactions across tables for Stream Load and
INSERT INTO.
Updates: the biggest philosophical difference
StarRocks' Primary Key table was built for mutable data. Updates are turned into Delete+Insert: the in-memory primary key index finds the old row, marks it deleted in a delete vector, and the new version is appended. Reads never have to merge versions, so predicates and indexes push down normally. StarRocks reports 3 to 10× better query performance than the merge-on-read Unique Key model. It also supports partial column updates, which makes "multiple streams each update their own columns" a native pattern. The trade-off: the primary key index uses memory (with a persistent-index option to reduce that).
For CDC from MySQL or PostgreSQL via Flink, this is about as simple as it gets in an OLAP database.
ClickHouse historically handled change through insert-based engines: ReplacingMergeTree (keep the latest version), CollapsingMergeTree, and the newer CoalescingMergeTree. Correct results before merges require FINAL or argMax-style queries, which is workable but leaks into every query.
Since 25.7, ClickHouse also supports standard SQL UPDATE via patch parts: an update writes a small part with only the changed columns and rows, which is applied on read immediately and folded in during merges. The docs (as of today) still mark lightweight updates as beta and position them for updating a modest share of a table (roughly up to 10%); bigger changes should still use ALTER TABLE ... UPDATE mutations. There are a few caveats worth knowing: skip indexes aren't used for parts with pending patches, and projections are skipped while patch parts exist.
| ClickHouse | StarRocks | |
|---|---|---|
| Upsert model | ReplacingMergeTree (eventual) or lightweight UPDATE (beta) | Primary Key table (immediate) |
| Correct reads right after update | With FINAL, or immediately with patch parts | ✅ Always |
| Partial column updates | Patch parts write only changed columns | ✅ Native |
| Deletes | Lightweight DELETE | ✅ Native |
| CDC fit | Good with ReplacingMergeTree + FINAL discipline | Excellent |
My take: if your data is mostly append-only (logs, events, metrics), ClickHouse's model is simpler and faster. If your facts change after they land (orders, payments, user profiles fed by CDC), StarRocks' Primary Key table is still the more natural fit, although ClickHouse has closed a lot of the gap.
6. Materialized views and pre-aggregation
Both systems rely heavily on pre-computation to scale reads, but they take opposite approaches.
ClickHouse materialized views are insert triggers: every block inserted into the source table is transformed and written into a target table (often AggregatingMergeTree). They're cheap and real-time, but you query the target table explicitly. Refreshable materialized views recompute periodically, and since 26.9 they can refresh incrementally for append-only sources. Projections store an alternative sort order or pre-aggregation inside the same table and are picked automatically by the optimizer.
StarRocks has synchronous MVs (rollup-style, per table) and, more importantly, asynchronous materialized views that can join multiple tables, including external lake tables, and refresh on a schedule or on change. The killer feature is transparent query rewrite: the optimizer rewrites queries against base tables to use a matching MV, so the BI tool doesn't need to know the MV exists. StarRocks 4.1 also moved refreshes toward version-range delta processing, so refresh cost follows the amount of changed data.
| ClickHouse | StarRocks | |
|---|---|---|
| Real-time incremental MV | ✅ Insert-triggered, very cheap | Sync MVs (single table) |
| Multi-table MV | Yes, but triggered only by the left-most table | ✅ Async MVs |
| Automatic query rewrite to MV | Projections only | ✅ Across async MVs |
| MVs over lake tables | Via refreshable MVs | ✅ First-class |
7. Lakehouse and open table formats
Both vendors now pitch themselves as lakehouse engines, so this matters for long-term architecture.
StarRocks has been the more aggressive of the two. Its external catalogs cover Hive, Iceberg, Hudi, Delta Lake and Paimon. 4.0 (October 2025) made Iceberg close to a native format: hidden partitions, native writes with global shuffle and local sort to avoid small files, a rewrite_data_files compaction procedure, metadata-based COUNT/MIN/MAX, catalog-centric access control with JWT passthrough to Iceberg REST catalogs, and vended credentials. 4.1 added SQL DELETE on Iceberg (writing position delete files), and a VARIANT type for semi-structured data. CelerData's positioning is clear: StarRocks as the fast query layer over an open lakehouse.
ClickHouse has invested heavily too: reading and writing Iceberg, Delta Lake and Hudi through table functions and data lake catalogs (Unity, Glue, REST), with pruning improvements in nearly every 2026 release. The emphasis is a bit different: ClickHouse is excellent at querying lake data ad hoc and at ingesting it into MergeTree for hot analytics, while StarRocks pushes further on governing and maintaining the lake itself.
My take: if Iceberg is your system of record and you want one engine to query, write, compact and secure it, StarRocks is ahead today. If the lake is a source you mostly read from and you keep hot data in native tables, both are fine.
8. Benchmarks, and how to read them
Every benchmark you'll see in this space comes with a story:
| Benchmark | What it tests | Who tends to win |
|---|---|---|
| ClickBench | ~43 queries on a single wide web-analytics table, no joins | ClickHouse (and it's maintained by ClickHouse) |
| SSB | Star schema: one fact table + dimensions | StarRocks (published by StarRocks) |
| TPC-H / TPC-DS | Complex multi-table joins, subqueries | StarRocks historically; ClickHouse has improved dramatically since 25.9 |
Three rules for reading them:
- Check the version and date. A 2023 TPC-H comparison tells you nothing about ClickHouse with statistics-based join reordering, and a 2024 comparison doesn't include StarRocks 4.x (which StarRocks says is ~60% faster year over year on TPC-DS).
- Check who ran it. Vendor benchmarks aren't lies, but they pick workloads and tuning that favor the vendor.
- Check single-query latency vs throughput. Most published benchmarks run one query at a time. If your problem is concurrency, they barely apply.
The only benchmark that matters is your queries, on your data, at your concurrency. Both systems are easy to spin up in Docker; a week of testing beats a month of reading comparisons (including this one).
9. Operations
| ClickHouse | StarRocks | |
|---|---|---|
| Getting started | One binary, runs on a laptop in seconds | FE + BE/CN containers, also quick with the all-in-one image |
| Cluster coordination | ClickHouse Keeper | FE metadata replication (BDB JE) |
| Rebalancing | Manual (self-managed) | Automatic |
| Schema changes | Fast metadata-only for most; mutations for some | Async alter jobs; fast schema evolution |
| Observability | Rich system.* tables, EXPLAIN indexes = 1, query log | Query profile, EXPLAIN ANALYZE, audit log, Prometheus metrics |
| SQL dialect | ClickHouse SQL (powerful, but its own dialect) | MySQL-compatible, Trino dialect support |
| BI tool compatibility | Native drivers for most tools | Anything that speaks MySQL |
| Managed offerings | ClickHouse Cloud, plus several third parties | CelerData Cloud, plus cloud providers' EMR offerings |
| Community | Very large; huge integration ecosystem | Smaller but fast-growing (500+ contributors, 11k+ GitHub stars per StarRocks' 2025 review) |
Two practical notes:
- ClickHouse's SQL dialect is a big productivity win once you know it (
argMax, arrays,-Ifcombinators,LIMIT BY), but it's a learning curve for teams coming from Postgres/MySQL. StarRocks' MySQL compatibility makes BI tool integration and onboarding easier. - ClickHouse's
systemtables are one of the best introspection surfaces in any database. StarRocks' query profile is more detailed per operator but requires running the query first (we saw this contrast in Part 3 of the Bloom filter series).
10. Decision guide
| Your workload | Lean toward | Why |
|---|---|---|
| Logs, traces, metrics, observability at petabyte scale | ClickHouse | MergeTree + skip/text indexes + compression; ClickStack and OpenTelemetry ecosystem |
| Single huge event table, aggregations by time and a few dimensions | ClickHouse | Best-in-class scan and aggregation speed |
| Star/snowflake schema on a multi-node cluster | StarRocks | CBO + shuffle/colocate joins + global runtime filters |
| Customer-facing dashboards with thousands of concurrent users | StarRocks (by default) | Resource groups, query queues, query cache, MV rewrite; ClickHouse works with more modeling effort |
| CDC from OLTP databases with frequent updates | StarRocks | Primary Key table, partial updates |
| Iceberg as system of record; one engine to query, write and maintain it | StarRocks | Most complete Iceberg integration today |
| Elastic, object-storage-backed cluster, self-managed | StarRocks | Open-source shared-data mode |
| Fully managed service, minimal ops | Either | ClickHouse Cloud and CelerData are both mature |
| Small team, single server, fast time to value | ClickHouse | One binary, enormous docs and community |
| Mixed: hot real-time events + BI over the lake | Both is a valid answer | Plenty of companies run ClickHouse for observability and StarRocks for BI |
Questions to ask before choosing
- Is my data mostly appended, or does it change after it lands?
- Are my queries mostly on one wide table, or across a normalized schema?
- Is my bottleneck single-query latency, or concurrency?
- Do I want to run it myself, and do I need storage/compute separation if I do?
- Is the data lake my source of truth?
If your answers are "appended, one table, latency, either, no", ClickHouse is the natural pick. If they're "changes, normalized, concurrency, self-managed elastic, yes", StarRocks is.
TL;DR
- The 2022 narrative is outdated. ClickHouse now has statistics-based join reordering (default since 25.12), runtime filters, join spilling and SQL
UPDATEs. Joins on a single node are no longer a weakness. - StarRocks still leads on distributed joins and concurrency controls, thanks to its CBO, MPP shuffle/colocate joins, resource groups, query cache and MV rewrite.
- ClickHouse still leads on raw scan speed for wide, append-only tables, and on the observability use case.
- Updates: StarRocks' Primary Key table is the more mature model for mutable data; ClickHouse's patch-part updates are promising but still beta.
- Storage/compute separation: open source in StarRocks (shared-data, now with automatic tablet splitting in 4.1); Cloud-only for ClickHouse (SharedMergeTree).
- Lakehouse: StarRocks pushes further into writing, compacting and governing Iceberg.
- Benchmarks are workload- and version-specific. Test your own queries at your own concurrency.
References
ClickHouse
- ClickHouse release 26.9
- ClickHouse changelog / what's new
- How ClickHouse became fast at joins (Tom Schreiber, 2026)
- ClickHouse release 25.9: automatic global join reordering
- The new cost-based join optimizer with reordering support for non-inner joins (Oct 2026)
- ClickHouse feature journey
- ClickHouse release 25.7: lightweight updates
- ClickHouse docs: the lightweight UPDATE statement
- ClickHouse docs: SharedMergeTree
- The evolution of ClickHouse Cloud: compute-compute separation
- ClickHouse docs: workload scheduling
- ClickBench
StarRocks
- StarRocks docs: architecture (shared-nothing and shared-data)
- StarRocks blog: separation of storage and compute
- StarRocks 4.0 is now available
- StarRocks 4.1 is now available
- StarRocks 4.1 release notes
- StarRocks 2025 year in review
- StarRocks docs: Primary Key table
- StarRocks docs: SSB benchmark
Comparisons (read with the vendor caveat in mind)
- StarRocks blog: ClickHouse or StarRocks? A detailed comparison (2022)
- Tinybird: ClickHouse vs StarRocks
- Are ClickHouse JOINs slow? A 2026 PR-by-PR analysis
From this blog
