Real-Time Data Warehouse Evaluation: ClickHouse vs StarRocks and Synchronization Strategies

This article outlines the author's experience evaluating two popular real‑time data warehouse solutions, ClickHouse and StarRocks , for a project that required fast OLAP queries on rapidly growing MySQL data.

Outline

The discussion covers the characteristics of real‑time warehouses, introduces the two products, and lists the project's specific requirements such as MySQL protocol compatibility, support for massive log‑type and business‑type data, low latency (<30 s), simple architecture, and minimal data transformation.

Research Process

2.1 Requirements

The project needed a solution that could handle billions of log entries (append‑only streams) and tens of millions of business records (change streams) with efficient JOIN performance, while keeping the deployment footprint small.

2.2 ClickHouse Evaluation

ClickHouse excels at analyzing append‑only log streams, supporting billions of rows on a single node and offering materialized views for faster queries. However, its performance degrades for change‑stream data, especially in JOIN scenarios, and its cluster mode requires ZooKeeper and complex distributed tables, making it less suitable for business‑type data.

2.3 StarRocks Evaluation

StarRocks provides a primary‑key model with Delete+Insert semantics that efficiently handles continuously updated business data and delivers superior JOIN performance. Its architecture separates storage and compute without ZooKeeper, simplifying cluster deployment, and it offers near‑full MySQL protocol compatibility.

Real‑Time Synchronization

3.1 ClickHouse Sync

Data is streamed from MySQL to ClickHouse using the open‑source CDC tool Bifrost , which parses binlogs, generates INSERT statements, and batches them directly into ClickHouse, achieving sub‑10‑second latency without intermediate message queues.

3.2 StarRocks Sync

For StarRocks, the pipeline extends Bifrost to write changes to Kafka, then uses StarRocks' Routine Load to consume the Kafka topic. An auxiliary Go program ( Econvert ) generates full‑load scripts via StarRocks' MySQL external table feature. This approach incurs a slightly more complex setup but still meets the 10‑second latency target.

Conclusion

If the primary workload is log‑type analytics, ClickHouse is recommended for its single‑node strength and simplicity. For business‑type analytics requiring frequent updates and strong JOIN capabilities, StarRocks is preferred, especially when deployed as a multi‑node cluster. In mixed scenarios, a single StarRocks deployment can handle both workloads.