// the find
risingwavelabs/risingwave
Event streaming platform for agentic AI. Continuously ingest, transform, and serve event streams in real time, at scale.
RisingWave is a streaming SQL database that replaces the Debezium+Kafka+Flink+serving-DB stack with a single system. It ingests from CDC, Kafka, webhooks, and S3; maintains materialized views incrementally; and serves results at low latency over the PostgreSQL wire protocol. Aimed at teams building real-time feature stores, dashboards, or monitoring pipelines who are tired of operating four systems to do one job.
Incremental computation is the core mechanic and it's done right — only affected rows are recomputed on upstream changes, not full re-scans. State is stored in object storage (S3) rather than RAM, which makes horizontal scaling and recovery tractable without the data-rebalancing pain you get with Flink. The PostgreSQL wire protocol compatibility means psql, JDBC, and most ORMs work without custom drivers. The Iceberg integration is genuinely useful: it handles compaction and snapshot cleanup internally, and the data stays readable by DuckDB, Spark, or Trino without any ETL.
The 'replace your entire streaming stack' pitch is ambitious and the operational surface is large — one system doing CDC, message brokering, stateful processing, and low-latency serving means one system's failure mode affects all of them. Self-hosting complexity is real: the Kubernetes operator, meta nodes, compute nodes, and object storage all need wiring together before you see anything useful. The SQL dialect has gaps vs standard PostgreSQL — some things that look like they should work (complex window functions, certain lateral joins) silently behave differently or aren't supported. Rust codebase is impressive but the build times will punish anyone trying to contribute or fork it locally.