Materialize
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.
LicenseSource-available· BUSL-1.1
DeploymentManagedSelf-hosted
PricingFreeSubscription
Operational complexityMedium
WorkloadStreamingInteractive
LanguageRust
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
CompareHow Materialize answers the questions Stream Processing turns on.
Stream Processing
| How it works | |
| 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 |
| 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 |
| Running it | |
| 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 |
| Scaling | ALTER CLUSTER SET SIZE, graceful by default since v26.35, new replicas hydrate before the old retire |
| Connections | |
| 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 |
Alternatives to Materialize
