Comparison between risingwave and materialize

[sunisdown]

I'm excited to find risingwave project and now we more choice for streaming database, especially risingwave is under Apache 2.0. It seems that both risingwave and materialize have simlar features( streaming, database, materlialize, written in Rust).
I am trying to learn the main architectural differences between these two project. when should we use risingwave?

[yingjunwu]

Thanks for your interest in RisingWave! As the founder of Singularity Data, the startup initiating the RisingWave project, I am probably the best person to answer this question.

First of all, please allow me to express my great respect to the Materialize team, for their excellent work in modernizing the stream processing infra! While sharing lots of common friends in both academia and industry, I have to admit that I haven't had any chance to speak to their team discussing Materialize's roadmap. So it's definitely unfair if I comment too much on their product. But I will still try my best to answer your question in an unbiased manner.

Similarities

• Both teams are great, and both teams have very strong research and engineering background!!!
• Both RisingWave and Materialize are streaming databases - databases that can effectively process streaming data;
• Both RisingWave and Materialize support PostgreSQL protocol and can seamlessly integrate with the PostgreSQL ecosystem;
• Both RisingWave and Materialize are written in Rust.

Differences

• Architecture: The open-source version of Materialize is a single-node streaming database. In contrast, RisingWave is a distributed database that has decoupled database frontend and backend. More importantly, RisingWave is by design built for the cloud: it leverages cloud services such as EBS and S3 (or equivalent services) to reduce performance cost;
• Design: Materialize is a SQL database built on top of Timely Dataflow, a horizontally scalable low-latency dataflow engine. Obviously, Materialize is built in a bottom-up manner: their team designed the computation abstraction first and then built the SQL engine on top of it. In contrast, we chose the opposite way (top-down manner) to build RisingWave: the runtime is specifically optimized for the SQL operators.
• Focus: it's related to the business, so you'd better confirm with Materialize team. But from their blog, it seems that their focus is on delivering strong consistency without compromising performance. RisingWave's focus is quite clear: we want to democratize stream processing, to make stream processing simple, affordable, and accessible. We do care about consistency and performance, just as all other streaming systems do.
• License: Materialize is under BSL, while RisingWave is under Apache 2.0.

Above are my (incomplete) answers. I stopped writing as It's Saturday and I don't want to overwork. For sure there are more differences if you take a deeper look into these two systems. Please feel free to let me know if I missed anything. Thanks!

[ericsyh]

I am also doing some research on streaming database products recently. From materialize's blog, https://materialize.com/blog/next-generation/ seems they already changed from single-node to distributed.

[lmatz]

I am also doing some research on streaming database products recently. From materialize's blog, https://materialize.com/blog/next-generation/ seems they already changed from single-node to distributed.

Yes👍

IIUC, due to Materialize's Business Source License, the user must purchase Materialize's cloud service to use its distributed version. But I can be wrong.

A user can deploy multiple compute nodes of RisingWave in a distributed fashion under Apache 2.0 License.

[ericsyh]

Seems Materialize also changed the License to Apache 2.0 License https://github.com/MaterializeInc/materialize#license. Well, I guess Materialize feels the pressure from the appearance of RisingWave 😄

[xxchan]

Materialize also changed the License to Apache 2.0 License

No. Their license is not changed. It is BSL, and each commit will be converted to Apache 2.0 after 4 years.

[ericsyh]

Yep, your understanding is correct. https://github.com/MaterializeInc/materialize/blob/main/LICENSE#L35

[ianyoung]

Another difference would seem to be with data persistence between the two. RisingWave seems to provide it's own persistence layer:
https://www.risingwave.dev/docs/latest/architecture/

Whereas in Materialize it's all volatile memory:

State is all in totally volatile memory; if materialized dies, so does all of the data.
https://materialize.com/docs/overview/architecture/#sources-ingesting-data

Materialize strives to be a correct, deterministic system. But because Materialize does not itself store data, it can only provide correctness and determinism if the sources it connects to provide the same guarantee. In particular, a given source must be capable of producing the same data repeatedly. In other words, if Materialize restarts, it must be able to replay the source from the beginning of time and receive exactly the same data.
https://materialize.com/docs/overview/volatility/

[chuck-alt-delete]

Clarification on this -- Materialize (the cloud product) has its own persistence layer and independently scalable compute and serving layers. The single-node binary (now in long term support and not actively developed) was limited to memory. Those docs pages have been removed as they no longer apply.

[maingoh]

What are the main differences between TimelyDataflow and RisingWave engine in term of performance and consistency ? Why not relying on TimelyDataflow (MIT Licensed) for RisingWave ?

We do care about consistency and performance, just as all other streaming systems do.

From what I read other streaming systems tends to follow eventual consistency ? (except materialize)

[lmatz]

For consistency, I think it's more about what users used to think they want
and learned what they don't want over the years.

Streaming was hard and confusing as users need to deal with two different notion of time, processing time and event time, and thus other concepts such as lateness, watermark etc.

People didn't figure what they really need and don't need at the early stage, e.g. 5-10 years ago. And this affected the design of some other systems.

RisingWave provides strong consistency.

[chuck-alt-delete]

RisingWave provides strong consistency.

Does it guarantee strict serializability like Materialize? In other words, what does "strong consistency" for RisingWave mean in terms of consistency models?

[yingjunwu]

RisingWave provides strong consistency.

Does it guarantee strict serializability like Materialize? In other words, what does "strong consistency" for RisingWave mean in terms of consistency models?

I should be qualified to answer this question, as I did my PhD thesis on this topic and Alan Fekete (one of the authors of the page you shared) was actually on my thesis committee :-)

"Serializable" and "strict serializable" are transactional database concept. RisingWave at version 0.1.16 does not provide tranasctional semantics, and hence it's not "serializable" or "strict serializable". That means, users should not expect to use RisingWave to replace an OLTP database, such as AWS Aurora, Google Spanner, and CockroachDB.

But RisingWave does provide "consistency and completeness" in the stream processing context. You may want to check this blog for detailed explanation: https://www.confluent.io/blog/rethinking-distributed-stream-processing-in-kafka/. A brief summary of what RisingWave can provide:

• consistent read - if you have two MVs, you should always see a consistent state of a certain timestamp;
• exactly-once processing - no matter how many times your system crashes, every single event will be processed once and only once;
• late arrival handling - even if the events come in a disordered manner, users can enforce RisingWave to process them in the correct order using watermark semantics.

I checked a few websites and found that, unfortunately, the term "consistency" is misused and can cause ambiguity. I will write a blog on what "consistency" really means in the context of stream processing, transactional databases, and distributed systems.

[fuyufjh]

As @yingjunwu mentioned, the term "consistency" is quite confusing and ambiguous in the context of streaming processing.

Materialize once published an article that claims that its product provides strict serializable. This looks awesome but note that the transaction here must be read-only or write-only on a single table, which is really tricky if you come from a real transaction database like PostgreSQL - it disallows updating multiple tables simultaneously (i.e. Atomicity of ACID). Besides, for a streaming system, most data comes from external systems rather than written through transactions, so it makes little sense to analyze whether a SELECT happens before or after an event is injected.

RisingWave actually shares a similar design in terms of transactions with Materialize. We both have timestamps (aka. epoch in RisingWave) associated with data rows i.e. MVCC, as a result, both are able to provide a consistent read snapshot. One difference I can tell is that RisingWave doesn't ensure the ordering of writes, which would require and centralized transaction manager or timestamp oracle; while for Materialize, that's trivial because it's running in a single process.

In terms of the user experience, as I mentioned before: "most data comes from external systems rather than transactions", users won't notice any difference between these 2 products. Compared with Flink, both products can ensure the Materialized Views & Tables are consistent with each other if read with the same timestamp, which can't happen in Flink or else.

[tisonkun]

Compared with Flink, both products can ensure the Materialized Views & Tables are consistent with each other if read with the same timestamp, which can't happen in Flink or else.

The basic Flink kernel doesn't maintain storage so mz views among different tasks are unrelated. I'm wondering if the situation changes once flink-table-store is into use. cc @JingsongLi