Why users are migrating from ClickHouse to StarRocks
NO JOINED TABLE SUPPORT
LIMITED SUPPORT FOR DATA CHANGES
LACK OF CONCURRENCY
CHALLENGING TO SCALE
StarRocks vs. ClickHouse
2.2x
GREATER PERFORMANCE IN WIDE-TABLE SCENARIOS OUT OF THE BOX
2.3x
#1
CLASS-LEADING MULTI-TABLE JOIN PERFORMANCE
Free yourself from denormazlied tables
Join relationships are the foundation of modern analytics, but they also pose a challenge to query performance.
ClickHouse has tried to circumvent this challenge by focusing on single-table query performance. Because of this, ClickHouse users have to flatten normalized tables into a single flat table before data ingestion. This step not only makes the analytics inflexible, but also adds complexity to the data processing pipeline.
StarRocks' native support for distributed JOIN algorithms and its cost-based optimizer best-in-class query performance against both single and multi-table joined queries. With StarRocks, users get to keep their normalized tables and do JOIN operations on the fly, simplifying their data ingestion pipeline, improving data freshness, and cutting down on ETL costs.
Even more great reasons to migrate
Embrace mutable data
Mutable data is a common byproduct of business activities. It can be caused by glitches in the underlying data pipeline or it can simply be a part of normal business logic.
ClickHouse, like most other analytical databases, doesn't have native support for UPDATE and DELETE operations. Instead, it provides a MUTATION operation to asynchronously ALTER TABLE. ClickHouse's asynchronous MUTATION operations can cause degraded and unpredictable query latency when there are frequent data ingestions. This is not suitable for real-time analytics with data mutations.
StarRocks' primary key table is designed to handle mutated data analytics natively. Using its primary key index, data changes are resolved at data ingestion, delivering uncompromising query performance to users.
Scale your analytics seamlessly
ClickHouse's performance only lasts as long as you're doing aggregation queries. Once scenarios become more demanding, like complex, high-concurrency queries, performance starts to crater.
StarRocks has none of these limitations. With a blazing-fast execution engine and a suite of advanced features like its built-in cost-based optimizer, StarRocks accelerates queries by reusing cached and saved query results. This makes it great for scaling concurrency in any scenario.
StarRocks' materialized view (MV) works seamlessly with the supports of incremental updated (sync' MV only) and automatic query rewrite.
StarRocks' query cache can save intermediate computation results of executed queries. New queries that are (partially) semantically equivalent can reuse the cached results.
Compare ClickHouse to StarRocks
Comparison
|
ClickHouse |
StarRocks |
Architecture |
Legacy scatter-gather architecture | Modern MPP architecture |
SQL syntax support |
Only partial SQL syntax support |
Full SQL syntax support |
Real-time updates |
Asynchronous updates, not real-time |
Synchronized real-time updates |
Concurrency support |
Supports limited number of concurrent users |
High concurrency with 10,000+ QPS |
3rd party dependencies |
Zookeeper-based operations |
No 3rd party dependencies |
Cost based optimizer |
No cost based optimizer
|
Built-in cost based optimizer |
Distributed joins |
No distributed joins
|
Distributed joins |
Data lake query support |
Rudimentary data lake query support |
Query support for Hive, Hudi, Iceberg, and Delta |
Support for federated queries |
No support for federated queries |
Federated queries with Hive, MySQL, ES, and JDBC sources |
Featured success stories
Talk to an engineer