[benesch]

(Materialize CTO here.)

> It's becoming more mainstream with Materialize, which is technically open-source, but they are quite aggressive with pushing their expensive cloud and offuscating on-prem usage.

Quick but important clarification: Materialize is source available, not open source. We've been licensed under the BSL [0] from the beginning. We feel that the BSL is the best way to ensure we can build a sustainable business to fund Materialize's development, while still contributing our research advances back to the scientific community.

> Quite underrated, it has so much promise.

I'm glad you think so. We think so too. One of the best parts of my job is watching the "aha" moment our prospects have when they realize how much of the complex code they've been writing is neatly expressed as a SUBSCRIBE over a SQL materialized view.

[0]: https://github.com/MaterializeInc/materialize/blob/main/LICE...

[steeeeeve]

It's crazy to me that the most updated file in your repository is the license - pushing back the open source date by a day every day.

[benesch]

Those updates are not retroactive. They apply on a go forward basis. Each day's changes become Apache 2.0 licensed on that day four years in the future.

For example, v0.28 was released on October 18, 2022, and becomes Apache 2.0 licensed four years after that date (i.e., 2.5 years from today), on October 18, 2026.

[0]: https://github.com/MaterializeInc/materialize/blob/76cb6647d...

[BeefySwain]

I love this concept. Did you all come up with this or is there prior art? Is there a name for this concept?

[benesch]

We did not originate the Business Source License (BSL/BUSL). It was originally developed by the folks behind MariaDB. Wikipedia has a good article that covers the history: https://en.wikipedia.org/wiki/Business_Source_License

Other large projects using the BSL include CockroachDB and (somewhat infamously) Terraform.

We're very glad to have been using the BSL for Materialize since our very first release. Relicensing an existing open source project under the BSL can be a painful transition.

[BeefySwain]

I was actually asking about the automatic timed re-license to Apache :)

[benesch]

Ah, I misunderstood! Yes, we may have invented that. I whipped up the cron job a few years back in response to concerns from our legal team. I’m not aware of any prior art for automatically advancing the change date for the BSL.

[jjovan1]

Hey Benesch, is Materialize used by TimescaleDB to create Materialized View? I noticed a similar approach.

[benesch]

Not to my knowledge. I believe TimescaleDB has their own incremental view maintenance engine.

[jjovan1]

Ok so I was wondering if your solution is faster. I noticed their materialized views are not as fast for real time data.

[benesch]

We haven't benchmarked TimescaleDB, so I can't say. Results tend to vary heavily by workload, too.

What I can say is that the research at the heart of Materialize (https://dl.acm.org/doi/10.1145/2517349.2522738) allows us to efficiently maintain computations that are more complex than what a lot of other IVM systems can handle.

Your best bet is to run your own benchmark of both systems using data that's representative of your workload. We offer a free seven day playground if you'd like to run such a benchmark: https://console.materialize.com/account/sign-up

We also have a community Slack where a number of Materialize employees hang out and answer questions: http://materialize.com/s/chat

[jjovan1]

Thanks!