RisingWave: One SQL Engine to Replace the Kafka-Flink-Serving DB Chain

What RisingWave Actually Replaces

The README is explicit about the problem: agents and real-time applications need fresh, queryable data at low latency, and the standard stack chains Debezium for CDC, Kafka for transport, Flink for processing, and a database for serving. Each hop adds latency and operational overhead. RisingWave collapses that stack into one system that ingests, processes, serves, and stores. The target user is a developer building agentic AI or live dashboards who does not want to run four different stateful services. The pitch is consolidation: one SQL interface for streaming and batch, one system to operate. That is a real value proposition, but it also means you are betting on one vendor's implementation of a very complex problem.

The Incremental Computation Mechanism

The core mechanism is incremental computation over materialized views. When upstream data changes, only affected results are recomputed, not the whole view. The README claims end-to-end freshness under 100 ms. That is a strong claim, but the architecture supports it: queries are maintained continuously in an internal row store, served at 10-20 ms p99 latency. There is no polling or cache warming. This is fundamentally different from a traditional database that recomputes on query. The trade-off is that you must define your queries as materialized views, not ad-hoc queries. If your access pattern is unpredictable, the incremental model may not fit. The documentation likely covers how to create such views, but the README does not give a SQL example, so you should check the quick start before assuming it matches your workload.

Ingestion Sources and the Unified SQL Interface

RisingWave ingests from webhooks via HTTP, database changes via native CDC from PostgreSQL and MySQL, event streams from Kafka, Pulsar, and Kinesis, and historical data from S3 and data warehouses. All sources are unified under the same SQL interface, and streams and tables can be joined freely. That is a wide net, but the README does not list specific versions or configuration details for each source. For example, CDC from MySQL requires binlog settings, and Kafka integration may need schema registry support. The claim of a unified interface is attractive, but you must verify that your specific source connector is mature. The repository does not show connector code, so the depth of support is unknown from this material alone.

Serving and Storage: Row Store vs. Iceberg

RisingWave serves low-latency queries from an internal row store, while long-term retention goes to Apache Iceberg tables. The row store is for serving, Iceberg is for durable, open-format storage and analytical queries. RisingWave hosts the Iceberg REST catalog directly and handles table maintenance like compaction and snapshot cleanup without external tooling. Iceberg queries are executed via Apache DataFusion, a vectorized engine, and the data is readable by Spark, Trino, and DuckDB. This dual-layer design is sensible: you get fast point lookups and durable analytics. But it means you have two storage systems to manage, even if they are in one product. The README claims object storage is roughly 100x cheaper than RAM, which drives the cost efficiency story, but it also implies that latency-sensitive workloads need the elastic disk cache to keep p99 at 10-20 ms. That cache is an extra configuration to tune.

Getting Started and Deployment Options

The quick start is a single curl command: curl -L https://risingwave.com/sh | sh. That installer is convenient, but piping a shell script from a URL carries supply-chain risk; you should inspect it before running. For production, the README lists Docker Compose, Kubernetes with Helm, and Kubernetes with an Operator. There is also a managed cloud option. The README does not provide the exact Helm chart name or operator installation command, so you will need to read the deployment docs. Given that RisingWave is a distributed system written in Rust, self-hosting will require planning for object storage, networking, and resource allocation. The 60-second installer is for a quick trial, not a production deployment.

Limitations and Failure Modes

The biggest limitation is that RisingWave is not a general-purpose stream processor. It is optimized for materialized views and SQL queries. If you need complex event-time windows, custom stateful operators, or functions that are not expressible in SQL, you will hit a wall. The README emphasizes incremental computation, but it does not mention exactly-once semantics for all sources, nor does it detail failure recovery beyond 'seconds' due to object storage. Another failure mode: the Row Store and Iceberg layers must stay consistent. If the Iceberg write path fails, you could have stale serving data. The README claims exactly-once ingestion into Iceberg, but that is a strong guarantee that requires careful implementation. Also, telemetry is enabled by default via Scarf and anonymous usage statistics; you must opt out if that is a concern. These are not deal-breakers, but they are reasons to test thoroughly before adopting.

Alternative: The Composable Stack vs. the Integrated Platform

The obvious alternative is the traditional stack that RisingWave aims to replace: Debezium, Kafka, Flink, and a serving database like PostgreSQL or Redis. That approach gives you best-of-breed components. Flink, for instance, offers mature windowing and state management, and Kafka is the de facto standard for event transport. The difference in approach is that the traditional stack is modular: you can swap out Flink for a different processor, or use a different CDC tool. RisingWave is an integrated platform, which reduces operational overhead but locks you into its SQL dialect and storage model. If your team already runs Kafka and Flink, migrating to RisingWave is a big change. If you are starting fresh and want one system, RisingWave is the more direct path. The choice hinges on whether you value flexibility or simplicity.

Maintenance and License Considerations

RisingWave is licensed under Apache-2.0, which is permissive and allows commercial use without copyleft obligations. The README does not specify a contribution process beyond a developer guide, so maintenance cost is on you if you self-host. The project has regular releases: v3.0.3 in August 2026, v3.0.2 in July, and v3.0.1 in June, indicating an active release cadence. But that also means you need to track upgrades. The telemetry is a maintenance consideration: you must configure opt-outs if your organization requires it. The documentation link for telemetry is provided, but the exact config key is not in the README. For a production deployment, you should plan for version upgrades and test them, as with any distributed system. The Apache-2.0 license is a positive for adoption, but it does not imply vendor support unless you pay for RisingWave Cloud.

Editorial conclusion

Adopt RisingWave if you are building agentic AI or real-time applications that need sub-100ms freshness, want to avoid operating multiple streaming systems, and can accept the operational cost of a distributed Rust service. Do not use it if your team is already deeply invested in Kafka and Flink and needs advanced stream processing features like event-time windows and complex stateful operations that RisingWave's SQL may not cover. Before committing, verify that your sources (CDC, Kafka, webhooks) are supported and that your query patterns fit the materialized view model. Test the 60-second installer in a sandbox, and check the telemetry opt-out if that matters to you.

Official sources

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