Skip to main content
We periodically update this article to keep up with the rapidly evolving landscape.

​
Summary

ClickHouseRisingWave
System categoryReal-time OLAP databaseStreaming database
LicenseApache License 2.0Apache License 2.0
ArchitectureColumn-oriented OLAP engine (C++)Cloud-native streaming database (Rust)
Storage engineMergeTree (columnar, local or cloud)Hummock (row-based LSM-tree, object storage)
SQL dialectClickHouse SQL (partial ANSI SQL)PostgreSQL-compatible SQL
Client protocolClickHouse native protocol, HTTP, MySQL wire protocolPostgreSQL wire protocol
Materialized viewsTriggered on INSERT, no incremental maintenanceIncrementally maintained in real time
Primary optimization targetAd-hoc analytical query performanceContinuous computation and result freshness
Typical use casesInteractive analytics, dashboards, log analysisStreaming ETL, monitoring, event-driven applications

​
Introduction

ClickHouse is a column-oriented OLAP database optimized for fast analytical queries; RisingWave is a streaming database optimized for continuous computation and real-time result freshness.

​
ClickHouse

ClickHouse is an open-source column-oriented database designed for online analytical processing (OLAP). It excels at executing complex analytical queries over large datasets with sub-second latency. ClickHouse uses the MergeTree storage engine family, which stores data in sorted, compressed columnar format for efficient scans and aggregations. It is widely used for log analytics, business intelligence dashboards, and ad-hoc data exploration.

​
RisingWave

RisingWave is an open-source streaming database designed for continuous real-time data processing. It uses PostgreSQL-compatible SQL and stores all data in object storage (S3, GCS, Azure Blob) via the Hummock row-based LSM-tree engine. RisingWave focuses on maintaining always-fresh results through incrementally maintained materialized views, with built-in source and sink connectors that eliminate the need for external middleware.

​
Storage engine

ClickHouse uses columnar storage optimized for analytical scans; RisingWave uses row-based storage optimized for incremental updates. ClickHouse’s MergeTree engine stores data in sorted, compressed columns. This layout is highly efficient for analytical queries that scan large ranges of data and compute aggregations — columnar compression ratios are typically 5-10x better than row-based storage for analytical workloads. RisingWave’s Hummock engine uses row-based LSM-tree storage persisted to object storage. This layout is optimized for incremental state updates during stream processing and point queries for serving. Row-based storage is better suited for maintaining streaming state where individual rows are frequently updated. Key difference: ClickHouse is optimized for read-heavy analytical workloads; RisingWave is optimized for write-heavy streaming workloads with frequent state updates.

​
Materialized views

ClickHouse materialized views are triggered on INSERT; RisingWave materialized views are incrementally maintained in real time with full consistency. In ClickHouse, materialized views are triggered on INSERT — they process each incoming block of data as it is inserted into the source table. This means:
  • Materialized views only process new data; they do not reflect updates or deletes to existing rows.
  • There is no support for cascading materialized views (views on views).
  • Joins in materialized views are limited — the materialized view typically processes one table’s inserts.
  • Aggregating materialized views require special -State/-Merge combinator functions and AggregatingMergeTree.
In RisingWave, materialized views are incrementally maintained in real time:
  • Results reflect all changes — inserts, updates, and deletes.
  • Cascading materialized views are supported with strong consistency across layers.
  • Complex multi-way joins, subqueries, and window functions work seamlessly in materialized views.
  • No special functions or engine types required — standard SQL works.

​
Query serving

Both systems serve queries with low latency, but for different query patterns. ClickHouse excels at ad-hoc analytical queries over large datasets. Its columnar engine can scan billions of rows per second, making it ideal for interactive dashboards and exploratory analytics where users run unpredictable queries. RisingWave excels at serving pre-computed results from materialized views. Because results are already computed, serving latency is consistently low (10-20ms p99) regardless of the underlying data volume. RisingWave uses dedicated Serving Nodes for high-concurrency point queries.
ClickHouseRisingWave
Ad-hoc analytical queriesExcellent (columnar scans)Good (row-based storage)
Pre-computed result servingLimited (MV restrictions)Excellent (incremental MVs)
Point queries by keyModerateFast (row-based, indexed)
Query concurrencyModerate (resource-intensive queries)High (lightweight reads from MVs)

​
Data ingestion

ClickHouse ingests data via batch inserts; RisingWave ingests data continuously via streaming connectors. ClickHouse is optimized for batch inserts — inserting data in large blocks (thousands to millions of rows) for optimal MergeTree performance. Real-time ingestion is possible via Kafka Engine tables or materialized views, but this is a secondary use case. ClickHouse does not have native CDC connectors. RisingWave is designed for continuous streaming ingestion. It provides native CDC connectors for PostgreSQL, MySQL, SQL Server, and MongoDB, as well as connectors for Kafka, Pulsar, Kinesis, S3, and many more. Data flows continuously from sources through materialized views to sinks.

​
SQL compatibility

ClickHouse uses its own SQL dialect; RisingWave uses PostgreSQL-compatible SQL. ClickHouse supports a subset of ANSI SQL with many proprietary extensions (e.g., Array, Tuple, Map types, -If/-State/-Merge aggregation combinators, FINAL keyword). The ClickHouse protocol is not compatible with PostgreSQL — you need ClickHouse-specific drivers or the HTTP interface. RisingWave uses PostgreSQL-compatible SQL and the PostgreSQL wire protocol. Any tool or driver that works with PostgreSQL (psql, JDBC, Python psycopg2) works with RisingWave without modification.

​
Common architecture: RisingWave + ClickHouse

RisingWave and ClickHouse are complementary systems that are often used together:
  1. RisingWave ingests streaming data (CDC, Kafka), performs real-time transformations and enrichment.
  2. RisingWave sinks the transformed results to ClickHouse for interactive analytics.
  3. ClickHouse serves ad-hoc analytical queries over the pre-transformed data.
This architecture combines RisingWave’s strengths in continuous ingestion, transformation, and delivery with ClickHouse’s strengths in fast analytical query execution. 
-- In RisingWave: Transform and sink to ClickHouse
CREATE SINK enriched_events_to_clickhouse FROM enriched_events
WITH (
  connector = 'clickhouse',
  type = 'append-only',
  clickhouse.url = 'http://clickhouse:8123',
  clickhouse.database = 'analytics',
  clickhouse.table = 'enriched_events'
);

​
How to choose?

Choose ClickHouse if:
  • Your primary need is fast ad-hoc analytical queries over large historical datasets.
  • You need interactive dashboards with sub-second query latency over billions of rows.
  • Your ingestion pattern is batch-oriented (bulk inserts).
  • You need columnar compression for cost-efficient storage of analytical data.
Choose RisingWave if:
  • You need continuous real-time data processing with always-fresh results.
  • You want incrementally maintained materialized views with full consistency.
  • You need native CDC connectors for database replication without middleware.
  • You want cascading materialized views for multi-layered streaming pipelines.
  • You need a PostgreSQL-compatible interface.
Choose both if:
  • You need real-time streaming transformations (RisingWave) feeding into interactive analytics (ClickHouse).
  • You want the best of both worlds: continuous freshness and fast analytical queries.