RisingWave: A Single System for Event Streaming, Processing, and Serving

What RisingWave Replaces and Why

The standard approach for building real-time data pipelines chains together several systems: Debezium for CDC, Kafka for transport, Flink for stream processing, and a database for serving query results. Each link adds latency and operational overhead. RisingWave's stated goal is to replace the entire chain with a single system.

The README describes the platform as ingesting data from databases, event streams, and webhooks, processing it incrementally, and serving fresh results at low latency. The target audience includes teams building monitoring and alerting systems, feature stores, live dashboards, real-time enrichment pipelines, and streaming lakehouses. The description labels it specifically as an event streaming platform for agentic AI, meaning it also exposes a Model Context Protocol server, a CLI, and Skills so that AI agents can query and operate RisingWave without custom integration.

How Incremental Computation Works in RisingWave

RisingWave's core mechanism is incremental computation. The README explains: when upstream data changes, only the affected results are recomputed. This means materialized views are always up to date without requiring a full recomputation on every query. The system maintains query results in an internal row store and serves them directly at query time.

The README states that end-to-end freshness is under 100 milliseconds and that the row store serves queries at 10 to 20 milliseconds p99 latency. These figures apply to the row store serving layer. For agents and applications, this means querying the system returns current results without polling, cache warming, or TTL management.

The internal state, tables, and materialized views are stored in object storage such as S3 or an equivalent. The README describes this as roughly 100 times cheaper than RAM. An elastic disk cache feature can pin hot data on local SSD or EBS for latency-sensitive workloads, keeping p99 latency in the 10 to 20 millisecond range while retaining the cost advantage of object storage for cold data.

Ingestion Sources and SQL Interface

RisingWave accepts data from four source categories, as listed in the README: webhooks for HTTP-based event ingestion; native CDC from PostgreSQL, MySQL, and other databases via transaction log reading; event streams from Kafka, Pulsar, Kinesis, and other message brokers; and batch ingestion from S3, data warehouses, and other storage systems.

All sources are unified under a SQL interface. Streams and tables can be joined freely. RisingWave connects over the PostgreSQL wire protocol, which means it works with psql, JDBC, and any Postgres-compatible tooling without additional drivers.

A quick-start installation runs in one command:

curl -L https://risingwave.com/sh | sh

For Docker, Kubernetes with Helm, or Kubernetes with an operator, the README points to the quick start guide at docs.risingwave.com. A managed cloud option is available at cloud.risingwave.com.

Apache Iceberg Integration and Long-Term Storage

RisingWave writes to Apache Iceberg tables for long-term retention and analytical access. The README describes the system as hosting the Iceberg REST catalog directly and handling table maintenance automatically: compaction, small-file optimisation, and snapshot cleanup. This removes the need for external tooling to manage Iceberg tables.

The Iceberg layer is separate from the row store. The row store handles low-latency serving; Iceberg provides durable, open-format storage for analytical queries. Because Iceberg is an open format, data in Iceberg tables is also readable by Spark, Trino, DuckDB, and other compatible engines. RisingWave executes Iceberg queries via Apache DataFusion, a vectorized query engine.

The repository's Cargo.toml workspace lists a large number of internal crates, including src/connector, src/stream, src/frontend, src/storage, and src/meta, reflecting a multi-component architecture built in Rust.

When RisingWave Is Not the Right Tool

RisingWave is not a general-purpose OLAP database. The README's row store latency claims apply to materialized views that fit within the designed access patterns. Complex analytical queries that scan large historical datasets are better served by a warehouse-oriented engine.

RisingWave collects anonymous usage statistics by default using Scarf for installation analytics. Both can be opted out. The README points to the telemetry documentation at docs.risingwave.com/operate/telemetry/ for the opt-out procedure. Teams in environments with strict data handling policies should review this before deployment.

The system is built in Rust, which adds to the operational complexity for teams that need to build custom connectors or extend the system. The public extension surface is SQL and the PostgreSQL wire protocol; modifying the internals requires Rust expertise and familiarity with a large codebase. The src/ directory in the repository contains more than 40 crates.

RisingWave Compared to Apache Flink

Apache Flink is the established open-source stream processing engine that RisingWave most directly competes with. Both process event streams continuously using SQL. The architectural difference is scope. Flink is a stream processing engine that requires separate systems for ingestion transport, result serving, and long-term storage. RisingWave combines all four functions in one system.

Flink has a larger ecosystem of connectors and a longer production history. RisingWave's advantage is operational simplicity: one deployment to manage instead of four or five. The README's framing of "replacing Debezium + Kafka + Flink + serving DB" reflects this trade-off directly.

The last push to the repository was on 2026-09-25. The v3.1.0 release shipped on 2026-09-21, and v3.0.4 on 2026-09-16. The project is licensed under Apache-2.0.

Editorial conclusion

RisingWave suits teams building real-time applications, monitoring pipelines, or feature stores that currently chain together multiple systems for ingest, processing, and serving. The Apache-2.0 license and open Iceberg storage mean data is not locked into a proprietary format. Teams evaluating it should test the elastic disk cache configuration for their target p99 latency, verify connector support for their specific CDC sources, and review the telemetry opt-out procedure in the documentation before deploying in environments with strict data policy requirements.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes