# Materialize

> Incremental view maintenance with strict serializability

Materialize incrementally updates SQL results as data arrives rather than recomputing them, built on Timely and Differential Dataflow and reachable over the PostgreSQL wire protocol, with strict serializability by default.

Website: https://materialize.com

## Use it when

- The question is asked constantly and the answer must stay current: views over joins, aggregations, and subqueries update incrementally as data arrives.
- Consumers speak PostgreSQL; SELECT and SUBSCRIBE over the Postgres wire let existing clients and BI tools read results directly, no serving layer.
- Correctness is non-negotiable; strict serializability by default removes eventual-consistency reasoning from the application.
- Sources are operational: Kafka and Redpanda topics, plus Postgres, MySQL, and SQL Server CDC.

## Think twice when

- You need watermark-style windowing and late-data handling; there are no window operators, only temporal filters on mz_now(), and late rows outside the filter are dropped.
- Working state is very large; arrangements live in memory with spill to scratch disk, and memory is the resource you size.
- The license matters: BUSL source-available, not open source.

## How it runs

Managed cloud, or self-managed on Kubernetes (environmentd, clusterd, balancerd) with a PostgreSQL metadata database and S3-class blob storage; a single-container emulator serves development. Clusters resize gracefully with ALTER CLUSTER. The self-managed Community Edition is free up to 24 GiB of memory.

## Details

### General

| Attribute | Value |
| --- | --- |
| License | Source-available |
| SPDX identifier | BUSL-1.1 |
| Deployment | Managed, Self-hosted |
| Workload | Streaming, Interactive |
| Operational complexity | Medium |
| Pricing | Free, Subscription |
| Language | Rust |
| Repository | https://github.com/MaterializeInc/materialize |
| Documentation | https://materialize.com/docs/ |
| Stars | 6.4k |

### Stream Processing

| Attribute | Value |
| --- | --- |
| Processing model | Incremental view maintenance on Timely and Differential Dataflow; no separate batch mode |
| APIs | SQL over the PostgreSQL wire protocol; HTTP and WebSocket APIs |
| What you run | environmentd, clusterd, balancerd and the console on Kubernetes, plus a PostgreSQL metadata database and S3 blob storage; single-container emulator for development |
| Connectors | Kafka and Redpanda, Postgres, MySQL and SQL Server CDC, webhooks; sinks to Kafka, Iceberg on S3 Tables or BigLake, and S3 via COPY TO |
| Windowing | No window operators: temporal filters on mz_now() |
| Event time and lateness | No watermarks: virtual timestamps only; rows outside the temporal filter are dropped, widen it to admit late data |
| State backend | In-memory arrangements with spill to scratch disk; persisted to blob storage |
| Delivery guarantee | Exactly-once: strict serializability by default; Kafka sinks use transactions |
| Reading results | SELECT and SUBSCRIBE over the PostgreSQL wire; indexes serve point lookups; sinks optional |
| Scaling | ALTER CLUSTER SET SIZE, graceful by default since v26.35, new replicas hydrate before the old retire |

## Capabilities

- [Stream Processing](https://matca.io/capabilities/stream-processing)

---

Source: https://matca.io/materialize
Last updated: 2026-08-31T11:40:46.952Z