RisingWave is an open-source distributed streaming database targeting real-time analytics and event-driven applications. It uses the incremental computation model to process streaming data with low latency. RisingWave implements a traditional change propagation framework to keep user-defined materialized views up-to-date. An incremental checkpoint mechanism is used to ensure data consistency. It also has an elastic multi-node architecture with separate data and compute nodes. RisingWave is built from scratch with Rust, and is wire compatible with PostgreSQL.[05][06][07]
- Source Code
- https://github.com/risingwavelabs/risingwave[02]
- Developer
- Country of Origin
- US
- Start Year
- 2021
- Project Types
- Commercial, Open Source
- Written in
- Rust
- Operating System
- Linux
- License
- Apache v2
- @RisingWaveLabs[04]
RisingWave is an open-source distributed streaming database targeting real-time analytics and event-driven applications. It uses the incremental computation model to process streaming data with low latency. RisingWave implements a traditional change propagation framework to keep user-defined materialized views up-to-date. An incremental checkpoint mechanism is used to ensure data consistency. It also has an elastic multi-node architecture with separate data and compute nodes. RisingWave is built from scratch with Rust, and is wire compatible with PostgreSQL.[05][06][07]
History[08][09]
RisingWave Database is built by RisingWave Labs (formerly known as Singularity Data), a database systems startup founded in 2021 by former IBM researcher and Amazon Redshift engineer Yingjun Wu.
While working at Amazon Redshift, Wu noticed that existing database systems cannot process streaming data efficiently and existing streaming systems were too complicated for most companies to use. This observation motivated Wu to found RisingWave Labs with a mission to “democratize stream processing”.
Checkpoints[10][11][12]
RisingWave uses the Chandy–Lamport algorithm to create consistent checkpoints.
To ensure that data is correct and consistent, read queries always fetch data from the most recent checkpoint. This means RisingWave does not ensure read-after-write consistency.
A local shared buffer is used to stage uncommitted write batches submitted by operators. The storage manager will notify all operators to commit their buffered writes into the shared storage when checkpoint trigger message has reached all operators.
Citations
12 sources- RisingWave | Streaming Infrastructure for Agentic AI risingwave.com
- GitHub - risingwavelabs/risingwave: Event streaming platform for agentic AI. Continuously ingest, transform, and serve event streams in real time, at scale. · GitHub github.com
- https://docs.risingwave.com/docs/latest/intro risingwave.com
- https://twitter.com/RisingWaveLabs twitter.com
- https://docs.risingwave.com/docs/current/intro risingwave.com
- risingwave/docs at main · risingwavelabs/risingwave · GitHub github.com
- https://www.risingwave.com/products/RisingWaveDatabase/ risingwave.com
- https://www.risingwave.com/company/ risingwave.com
- Streaming data processing platform RisingWave lands $36M to launch a cloud service | TechCrunch techcrunch.com
- https://github.com/risingwavelabs/risingwave/blob/main/docs/checkpoint.md github.com
- https://docs.risingwave.com/docs/current/fault-tolerance risingwave.com
- https://docs.risingwave.com/docs/current/data-persistence risingwave.com