RisingWave is an Apache-2.0, Rust-written event streaming platform for agentic AI that continuously ingests data from databases, event streams and webhooks, processes it incrementally, and serves fresh results at low latency, and it is aimed at teams building agents, real-time applications and streaming data pipelines that need always-current, queryable data.

What it is

RisingWave is an open-source streaming database that unifies ingestion, incremental processing, low-latency serving and durable storage in a single system. It lives in the Infrastructure & Operations / Databases category and speaks the PostgreSQL wire protocol, so it works with psql, JDBC and any Postgres-compatible tooling. Internally it maintains state, tables and materialized views in object storage such as S3, holds query results in an internal row store for serving, and writes long-term data to Apache Iceberg tables through a hosted Iceberg REST catalog.

The concrete problem it solves is the chained real-time stack. The standard approach links Debezium for change data capture, Kafka for transport, Flink for processing and a database for serving, and every hop in that chain adds latency and operational overhead. RisingWave replaces the whole stack — ingest, process, serve, store — with one system whose results are recomputed incrementally, meaning only the affected results are recalculated when upstream data changes.

Key capabilities

• Ingests across the full data spectrum: HTTP webhooks, native CDC from PostgreSQL and MySQL via transaction log reading, event streams from Kafka, Pulsar and Kinesis, and batch data from S3 and data warehouses, all under one SQL interface where streams and tables join freely.
• Performs incremental computation over materialized views with end-to-end freshness under 100 ms, without full recomputation on every query.
• Serves results from an internal row store at 10–20 ms p99 latency, queried directly with standard SQL — no polling, cache warming or TTL management.
• Writes to Apache Iceberg tables, hosting the Iceberg REST catalog itself and handling compaction, small-file optimization and snapshot cleanup without external tooling.
• Executes Iceberg queries through Apache DataFusion, a vectorized query engine, keeping data readable by Spark, Trino and DuckDB because Iceberg is an open format.
• Provides an MCP server, a CLI and Skills so agents can query and operate RisingWave without custom integration.
• Stores internal state in object storage roughly 100x cheaper than RAM, with an elastic disk cache that pins hot data on local SSD or EBS for latency-sensitive workloads.

Who uses it and how

• Agentic AI applications query the serving layer directly with SQL, and operate the system through the MCP server, CLI and Skills rather than bespoke integration code.
• Monitoring and alerting pipelines continuously evaluate streaming metrics against thresholds.
• Feature stores compute batch and streaming features over the same pipeline and serve them from the same system.
• Live dashboards run on incrementally updated materialized views, with no scheduled refreshes.
• Streaming lakehouse workloads ingest continuously and exactly once into open-format tables with automated compaction and snapshot management.

Getting started

The fastest path runs curl -L https://risingwave.com/sh | sh, which installs and starts the system in about 60 seconds. Docker, Kubernetes and other options are documented in the quick start guide.

How it compares

The tools it consolidates are Debezium, Kafka, Flink and a serving database, so the comparison is less about licence than about count: RisingWave is one Apache-2.0 system where that stack is four, and the open Iceberg layer keeps data readable by Spark, Trino and DuckDB rather than trapped in a proprietary store. Teams already standardized on managed brokers and stream processors should weigh that consolidation against existing operational knowledge.

When to use it — and when not to

A self-hoster must run object storage such as S3 or an equivalent for state and tables, and for latency-sensitive work should add local SSD or EBS for the disk cache; there is no separate catalog service to operate because the Iceberg REST catalog is hosted internally. It is a poor fit for teams that need only periodic batch analytics, or that are unwilling to adopt a new streaming engine in place of an existing Kafka and Flink investment. The repository carries a substantial open-issue count of 1687, which is worth reviewing before committing to it as the single system behind production serving.

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