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.

Compression[13][14]

RisingWave applies both naive compression and prefix compression at block-level. It uses LZ4 and Zstd for naive compression.

Concurrency Control[15]

RisingWave does not support concurrency control in its compute engine. However, it does employ Multi-version Concurrency Control (MVCC) in its cloud-native LSM-Tree-based storage engine.

Data Model[16]

RisingWave uses a relational data model. Relational tables are composed of a list of strongly-typed columns. All columns are implicitly nullable. RisingWave supports primitive data types of: boolean, integer, fixed-point and floating-point numbers, strings, and temporals. Composite data types of struct and list are also supported.

Foreign Keys

Indexes[17][15]

RisingWave does not support traditional index data structures. Instead, index is implemented as a specialized materialized view. RisingWave's storage engine stores materialized view as key-value pairs in log-structured merge trees.

Isolation Levels

Joins[18][19][20]

RisingWave supports join with hash join, nested loop join, and index nested loop join (also called lookup join). RisingWave has two execution modes: the batch-query mode and the streaming mode. All three join strategies are used in the batch-query mode, while only hash join and lookup join are used in the streaming mode. The supported join types are: inner join, left outer join, right outer join, and full outer join. RisingWave supports time window functions, window joins are also supported.

Logging[11]

Parallel Execution[21][22][23][24]

RisingWave supports bushy parallelism in both its batch-query and streaming modes. Consistent hashing is employed to partition data for parallel execution.

Query Compilation

Query Execution[25][16]

RisingWave adopts a top-to-bottom vectorized processing model. Operators emit a Data Chunk in batch-query mode and a Stream Chunk in streaming mode. A Data Chunk consists of multiple columns and a visibility array representing the visibility status of each row (for row filtering purpose). A Stream Chunk consists of multiple columns, visibility array, and an additional ops column marking an operation on each row. Each entry in the ops column can be one of Delete, Insert, UpdateDelete, or UpdateInsert.

Query Interface[26][27]

The RisingWave SQL query interface is mostly compatible with PostgreSQL. It has client library in Java, Node.js, Python, and Go. RisingWave is wire compatible with PostgreSQL, and can be accessed with PostgreSQL terminal psql. As a cloud-native database, RisingWave can be integrated with cloud services such as Confluent Cloud, DataStax, and Grafana Cloud. To support stream processing, RisingWave can be integrated with the following message brokers or streaming services: Kafka, Redpanda, Apache Pulsar, DataStax Astra Streaming, StreamNative Cloud, and Kinesis Data Streams.

Storage Architecture[15][12]

RisingWave has a disk-oriented storage architecture. Files are directly written to a S3-compatible shared storage service by default. Local drives, Google Cloud Storage, and HDFS/WebHDFS are also supported shared storage destinations.

Storage Model[15][28][16]

RisingWave uses the row store format. Each row is encoded into key-value entries.

Storage Organization[15]

RisingWave uses a LSM-Tree based key-value storage engine that provides MVCC read and write capabilities. All key-value pairs are stored in block-based SSTables. Each SST consists of two files. The .data file is composed of 64kb sized blocks containing the actual key-value pairs. A second .meta file contains metadata such as min-max index, Bloom filter, and per-block metadata.

Stored Procedures[29]

RisingWave offers UDF implemented as external functions in Python.

System Architecture[21][30]

Views[31][32][33]

RisingWave supports both views and materialized views. New materialized views can be created based on existing materialized views. RisingWave updates materialized views incrementally as new data is fed into the database.