We do hang out here! And, thankfully, you don't need to know Rust to join Materialize! (I didn't when I first started.) Many of our engineers learn it on the job.

If you're interested, we're actively hiring! You can apply on our site (https://materialize.com/careers/) or reach out to me: jessica@materialize.com.

Hi, we agree! (I work at Materialize.)

eloff, if you see this, I'm shooting you an email!

Materialize | Engineering, Developer Experience, Product, Marketing | NYC HQ + North America Remote + Europe Remote | https://materialize.com/careers

We're hiring at all levels of engineering positions (eng. manager, engineers from new grad to principal), technical writers, developer advocates, and more across product and marketing - for the full list, see https://materialize.com/careers

WHAT: Materialize is a streaming database for real-time applications. We are focused on bottom-up developer adoption, our core software is written in Rust, free to use and source available, our business model is a cloud product built with Python and Typescript that handles management of Materialize and lets businesses focus on building value.

WHO: We are a team of 40 experienced individuals in databases and distributed systems, and looking to add more folks with that interest and/or experience to our team. Our cofounder and chief scientist is Frank McSherry, the primary author of Timely Dataflow (http://timelydataflow.com) and Differential Dataflow (http://differentialdataflow.com), the two open source projects that power Materialize.

WHERE: Primarily based in New York City but also open to remote positions in the EU and NA.

Hi, you mention you’re open for remote, but none of the listings on your career page are tagged remote. Does that mean all positions are potentially remote? If not, which ones are? I’m interested, based in Europe.

EDIT: also don’t see any non-senior positions, but you mentioned new-grad?

It is! We recently added support for S3 sources [0], which you could use to backfill data and union with a stream.

To your other question, we're currently well-suited for streaming applications. Moving forward, as we add support for features like persistence, we could certainly replace at least parts of a traditional data lake.

[0]: https://materialize.com/docs/sql/create-source/json-s3/

We (I work at Materialize) actually do support updates! Our CDC sources support them, as well as any source using an UPSERT envelope (more info here: https://materialize.com/docs/sql/create-source/text-kafka/#u...).

As per your second point, I have a less awkward way for you! Materialize supports a top-k idiom (https://materialize.com/docs/sql/idioms/#top-k-by-group) that is hopefully a bit more clear.

Right, I saw no update in the SQL keyword list, and saw some (I guess old now) talk about Materialize where the speaker mentioned no updates, sorry!

No apologies necessary, we're an active work in progress! (And, hopefully, moving quickly!)

Neat! We're totally on the same page--incremental view maintenance not only makes materialized views a useful building block for data pipelines, it can make them much simpler, too!

So it is CTEs all the way down, a bag of dags. A raw table is just a view over the raw data, a cooked view is just a view of views, repeat.

Do you use any of the ideas of Noria? Cadence?

This is great, but at what COST?!

Mmmh I've been thinking a lot about generated/computed fields as I wanted to use them in pg. They were introduced in pg12 but only materialized.