RisingWave
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.
LicenseOpen source (permissive)· Apache-2.0
DeploymentSelf-hostedManagedHybrid
PricingFreeSubscription
Operational complexityMedium
WorkloadStreamingInteractive
LanguageRust
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
CompareHow RisingWave answers the questions Stream Processing turns on.
Stream Processing
| How it works | |
| Processing model | Incremental materialized view maintenance; batch queries over the same tables |
| APIs | PostgreSQL-compatible SQL; UDFs in Python, JavaScript, Rust and Java |
| 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 |
| Running it | |
| 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 |
| Scaling | Online: adaptive parallelism by default, or ALTER ... SET PARALLELISM, no restart |
| Connections | |
| Connectors | Kafka, Pulsar, Kinesis, Pub/Sub, NATS, MQTT, S3, GCS, Azure Blob, Iceberg; Postgres, MySQL, SQL Server and MongoDB CDC; around 27 sinks |
Alternatives to RisingWave
