# RisingWave

> Streaming database keeping materialized views always current

RisingWave is a PostgreSQL-compatible streaming database that maintains materialized views incrementally rather than recomputing them, storing state and tables in object storage so compute and storage scale separately.

Website: https://risingwave.com

## Use it when

- You want the pipeline collapsed into a database: ingest, transform, serve, and store in one PostgreSQL-compatible system, with materialized views kept current incrementally.
- State is big; tables and state live in object storage through the Hummock LSM store, so cost scales with S3, not cluster disks.
- Rescaling must be online; adaptive parallelism changes without restarts.
- The team writes SQL, not Java; sources span Kafka, Pulsar, Kinesis, MQTT, and CDC from Postgres, MySQL, SQL Server, and MongoDB, with around 27 sinks including Iceberg.

## Think twice when

- The logic exceeds SQL; Flink's DataStream API expresses computations RisingWave cannot, and UDFs only stretch so far.
- Late data needs routing; watermarks are declared per source and late rows are dropped, with no side outputs.
- Sub-millisecond point serving is the goal; an elastic SSD cache fronts object storage, but a dedicated store may still win.

## How it runs

Frontend, compute, compactor, and meta nodes over object storage, with a Postgres, MySQL, or SQLite meta store; a single-binary standalone mode serves development. Query views directly over the PostgreSQL wire. Apache-2.0 and free to self-host; RisingWave Cloud is the managed option.

## Details

### General

| Attribute | Value |
| --- | --- |
| License | Open source (permissive) |
| SPDX identifier | Apache-2.0 |
| Deployment | Self-hosted, Managed, Hybrid |
| Workload | Streaming, Interactive |
| Operational complexity | Medium |
| Pricing | Free, Subscription |
| Language | Rust |
| Repository | https://github.com/risingwavelabs/risingwave |
| Documentation | https://docs.risingwave.com |
| Stars | 9.3k |

### Stream Processing

| Attribute | Value |
| --- | --- |
| Processing model | Incremental materialized view maintenance; batch queries over the same tables |
| APIs | PostgreSQL-compatible SQL; UDFs in Python, JavaScript, Rust and Java |
| What you run | Frontend, compute, compactor and meta nodes, plus object storage and a Postgres, MySQL or SQLite meta store; single-binary standalone mode for development |
| Connectors | Kafka, Pulsar, Kinesis, Pub/Sub, NATS, MQTT, S3, GCS, Azure Blob, Iceberg; Postgres, MySQL, SQL Server and MongoDB CDC; around 27 sinks |
| Windowing | Tumbling, hopping, session |
| Event time and lateness | Watermarks declared on the source with WATERMARK FOR; late rows are dropped, no side outputs |
| State backend | Hummock: LSM store on object storage, local SSD cache |
| Delivery guarantee | Exactly-once; end-to-end depends on the sink |
| Reading results | Query materialized views directly over the PostgreSQL wire; sinks optional |
| Scaling | Online: adaptive parallelism by default, or ALTER ... SET PARALLELISM, no restart |

## Capabilities

- [Stream Processing](https://matca.io/capabilities/stream-processing)

---

Source: https://matca.io/risingwave
Last updated: 2026-08-31T11:40:47.110Z
