Materialize vs RisingWave: Which Streaming Database Should You Choose?

Two streaming databases dominate the conversation when engineering teams need SQL over continuously updating data: Materialize and RisingWave. Both speak PostgreSQL. Both maintain incrementally updated materialized views. Both promise that you can write a CREATE MATERIALIZED VIEW statement and get fresh results without running a batch job.

But beneath that shared surface, the two systems diverge sharply. Materialize is built on Differential Dataflow, a research-grade incremental computation framework from Microsoft Research. RisingWave is built on a purpose-built streaming engine written in Rust, with a cloud-native storage architecture that pushes all state to S3-compatible object storage.

This comparison covers every dimension that matters for a real production decision: architecture, storage model, PostgreSQL compatibility, source connectors, performance, open-source status, and operational cost. The goal is a fair assessment -- not a sales pitch -- so you can evaluate the trade-offs against your specific requirements.

What Both Systems Have in Common

Before diving into differences, it helps to understand why Materialize and RisingWave are often compared in the first place.

Both are purpose-built streaming databases -- not stream processing frameworks bolted onto an external serving layer. Both expose results through the PostgreSQL wire protocol, which means any PostgreSQL client library works out of the box: psql, JDBC, psycopg2, pgx, and others. Both maintain materialized views incrementally, propagating only the changes caused by new input data rather than recomputing from scratch.

Both also target a similar audience: data engineering teams that want to build real-time pipelines without writing Java or Scala, and without managing a separate serving database downstream of their stream processor.

The similarities end there.

Architecture: Differential Dataflow vs DAG-Based Incremental Computation

Materialize: Differential Dataflow and Timely Dataflow

Materialize is built on Timely Dataflow and Differential Dataflow, frameworks originally developed at Microsoft Research. The core idea behind Differential Dataflow is treating data as collections of diffs -- each record is a tuple of (data, time, change) where change is +1 (addition) or -1 (retraction). Operators process these diffs incrementally, propagating only what changed through the computation graph.

This representation is mathematically elegant and enables certain workloads -- particularly iterative graph computations and recursive queries -- that are difficult to express in other incremental models. Differential Dataflow's join, group, and iterate operators are built around this diff algebra.

Materialize's architecture has three logical layers:

• Storage (Persist): Handles data ingestion and durable storage, backed by blob storage and a consensus service. Input data and state changes are persisted here.
• Adapter: Manages the PostgreSQL-compatible SQL interface, session handling, and query planning.
• Compute: Runs Timely Dataflow workers that execute the incremental dataflow graph. Active state is held in memory by compute workers.

Crucially, compute workers hold the working set of materialized view state in memory. Materialize does have a Persist layer backed by blob storage for durability, but the data being actively processed and served lives in the memory of compute replicas. This is a deliberate design choice that enables low-latency query serving for datasets that fit in memory.

Materialize's consistency model is strict serializability across all sources and views. This means every query sees a consistent snapshot of the world, even when multiple sources are involved, and there are no anomalies from concurrent updates. This is a strong correctness guarantee that requires coordination overhead.

RisingWave: DAG-Based Incremental Computation with S3-Native Storage

RisingWave uses a directed acyclic graph (DAG) based streaming engine where each node in the graph is a stateful operator: a filter, a projection, an aggregation, a join, or a materialized view. Operators communicate through message-passing channels, and state is maintained incrementally as new input arrives.

What distinguishes RisingWave's architecture is the storage layer. RisingWave built Hummock, a purpose-built LSM-tree storage engine that writes all state directly to S3-compatible object storage (S3, GCS, or Azure Blob Storage). There is no local RocksDB. There are no local disks that constitute primary state storage. Local memory and NVMe SSD serve only as a read cache.

The four node types in a RisingWave cluster have clear, separated responsibilities:

• Streaming nodes: Execute the DAG-based streaming operators and write state changes to Hummock.
• Serving nodes: Parse and plan SQL queries, serve ad-hoc reads via the PostgreSQL wire protocol, and handle client connections.
• Compactor nodes: Run background LSM-tree compaction on Hummock, merging SSTables and removing obsolete entries without blocking the streaming pipeline.
• Meta node: Coordinates the cluster, manages Hummock metadata, orchestrates checkpointing, and handles job lifecycle.

Because all durable state lives in object storage, compute nodes are stateless with respect to persistence. Adding a streaming node means the node fetches state from S3 on demand (assisted by the local cache) and joins the processing graph. Removing a node requires no state migration. This makes horizontal scaling and failure recovery fundamentally different from any architecture where state lives on local disks.

RisingWave's consistency model uses barrier-based checkpointing. Barriers flow through the DAG periodically (default: every one second), and each barrier marks a consistent snapshot. Materialized view results are fresh within one barrier interval, giving sub-second freshness under normal operating conditions.

Architecture Comparison

Storage: EBS-Backed Compute vs S3-Disaggregated State

Storage architecture is where the two systems diverge most consequentially for production operations.

Materialize's Storage Model

Materialize separates storage (Persist) from compute, but the compute layer holds active materialized view state in memory during processing. When you create a cluster replica in Materialize, that replica's workers maintain the state for the indexes and materialized views assigned to it in RAM.

For production deployments, this means provisioning cluster replicas with enough memory to hold the working set of your materialized views. A high-cardinality aggregation over millions of users requires proportionally more RAM on the compute cluster. When state grows beyond available memory, the system needs larger replicas -- which in practice means larger EC2 instance types with attached EBS volumes or higher-tier managed instances.

Materialize's managed offering runs on EBS-backed compute instances. Persistence through the Persist layer provides durability and recovery, but the serving path goes through in-memory state on compute replicas.

RisingWave's Disaggregated Storage Model

RisingWave's Hummock storage engine is disaggregated from compute by design. The write path works as follows:

1. Incoming state changes are buffered in memory (mem-tables) on streaming nodes.
2. At flush time (triggered by memory pressure or a checkpoint barrier), mem-tables are serialized into immutable, sorted SSTable files and uploaded to S3.
3. Background compactor nodes merge SSTables, remove obsolete entries (tombstones), and optimize read performance.
4. Reads are served from a multi-level cache: first the in-memory block cache on streaming/serving nodes, then local NVMe SSD cache, then S3.

The practical result: state size is bounded by S3 capacity, which is effectively unlimited. A materialized view with terabytes of state is not a special case that requires a larger node type -- it is handled the same way as a view with megabytes of state, because the overflow destination is always S3.

Storage cost is also dramatically different. S3 storage runs approximately $0.023 per GB per month in most AWS regions. EBS gp3 storage runs approximately $0.08 per GB per month -- more than three times as expensive. For workloads with hundreds of gigabytes or terabytes of materialized view state, this difference compounds significantly.

Storage Model Comparison

PostgreSQL Compatibility

Both systems advertise PostgreSQL compatibility, but the depth of that compatibility differs in ways that affect real applications.

Materialize's PostgreSQL Compatibility

Materialize supports the PostgreSQL wire protocol and a significant subset of PostgreSQL SQL. You can connect with psql, JDBC, and most PostgreSQL client libraries. Materialize supports:

• Standard SELECT queries with WHERE, GROUP BY, ORDER BY, LIMIT
• Materialized views and indexes
• Window functions
• CTEs
• Data types compatible with PostgreSQL (int, text, jsonb, timestamptz, and others)
• SUBSCRIBE for streaming change feeds from views

Materialize does not support the full PostgreSQL DDL and extension ecosystem. Stored procedures, triggers, and certain PostgreSQL-specific functions are not available. The system is PostgreSQL-compatible at the wire protocol and query layer, not at the storage or administration layer.

One notable feature: Materialize supports the SUBSCRIBE command, which lets you stream incremental changes from a materialized view directly to a client over a long-lived connection. This is useful for building reactive applications that consume the diff stream rather than polling for results.

RisingWave's PostgreSQL Compatibility

RisingWave targets wire-level compatibility with PostgreSQL 13 and implements a large portion of the PostgreSQL SQL dialect. RisingWave's SQL reference covers the full command set. Supported capabilities include:

• PostgreSQL wire protocol (connect with psql, JDBC, psycopg2, pgx, pgwire)
• Standard DDL: CREATE TABLE, CREATE MATERIALIZED VIEW, CREATE INDEX, CREATE SINK, CREATE SOURCE
• Full DML: INSERT, UPDATE, DELETE on regular tables
• Window functions: ROW_NUMBER, RANK, DENSE_RANK, LAG, LEAD, and aggregate window functions
• Streaming window functions: TUMBLE, HOP (sliding windows) natively in SQL
• CTEs and recursive CTEs
• JSONB operations and operators
• User-defined functions in Python, Java, and JavaScript
• EXPLAIN for both streaming and batch query plans
• SHOW commands for session variables, materialized view progress, and more

RisingWave also supports cascading materialized views -- where one materialized view reads from another -- enabling multi-stage pipeline construction entirely in SQL. The intermediate results of each stage are also queryable.

PostgreSQL Compatibility Comparison

Source Connectors

Connector breadth determines whether a streaming database can fit into your existing data infrastructure.

Materialize's Sources

Materialize's primary source connector is Kafka. Materialize reads from Kafka topics using its native Kafka source and supports Avro (with Schema Registry), Protobuf, and JSON encodings. Materialize also provides:

• PostgreSQL CDC: Direct CDC from PostgreSQL via logical replication.
• MySQL CDC: Direct CDC from MySQL.
• Webhook sources: HTTP endpoints that accept incoming events.
• Load generators: Built-in data generators for testing (auction, counter, marketing).

Materialize's Kafka integration is mature and well-documented. The system handles out-of-order messages and retractions through its Differential Dataflow model. For teams whose data flows through Kafka, Materialize's connector is production-ready.

The connector ecosystem is focused rather than broad. If your sources include Kinesis, Pulsar, S3 files, or database systems beyond PostgreSQL and MySQL, Materialize currently requires routing data through Kafka first.

RisingWave's Sources

RisingWave has a broader connector catalog covering more source systems natively. The RisingWave connector documentation lists the full set. Core sources include:

• Kafka: Native source with Avro, Protobuf, JSON, CSV, and Debezium encoding support. Mature connector with tunable parallelism.
• Amazon Kinesis: Native source for AWS event streaming.
• Apache Pulsar: Native source.
• Redpanda: Compatible via the Kafka protocol.
• PostgreSQL CDC: Direct logical replication source.
• MySQL CDC: Direct binlog-based source.
• MongoDB CDC: Supports change streams.
• SQL Server CDC: Native CDC support.
• S3 / GCS: Batch ingestion from object storage files.
• Iceberg: Source from Apache Iceberg tables.
• Google Pub/Sub: Native source for GCP environments.
• NATS JetStream: Lightweight messaging source.

RisingWave's Kafka source is the most mature and highest-throughput connector, having been optimized across multiple releases. The Kafka source supports consumer group management, topic partition discovery, and configurable offset resets. For teams running Kafka, this is the recommended entry point.

The broader connector list matters when your organization has heterogeneous data sources. Being able to join a Kafka stream with a PostgreSQL CDC feed and an S3 snapshot in a single SQL query -- without building a separate ETL pipeline to normalize everything into Kafka first -- is a significant operational advantage.

Connector Comparison

Working Example: Building a Pipeline in RisingWave SQL

The following examples are verified against a local RisingWave 2.8.0 instance. They illustrate the SQL patterns you would use when building a streaming analytics pipeline.

Create Base Tables and Sources

For a local or batch-ingestion scenario, you create regular tables. In production, you would replace these with CREATE SOURCE pointing at Kafka or CDC.

CREATE TABLE matcmp_orders (
    order_id BIGINT,
    user_id BIGINT,
    product_id BIGINT,
    amount DECIMAL,
    region VARCHAR,
    status VARCHAR,
    created_at TIMESTAMPTZ
);

CREATE TABLE matcmp_product_inventory (
    product_id BIGINT,
    product_name VARCHAR,
    category VARCHAR,
    quantity INT,
    updated_at TIMESTAMPTZ
);

CREATE TABLE matcmp_page_views (
    view_id BIGINT,
    user_id BIGINT,
    page_url VARCHAR,
    session_id VARCHAR,
    viewed_at TIMESTAMPTZ
);

In a production deployment reading from Kafka, the source definition looks like this (not executed here since no Kafka cluster is available, but syntax is valid):

-- Example Kafka source (requires a running Kafka broker)
CREATE SOURCE matcmp_orders_kafka (
    order_id BIGINT,
    user_id BIGINT,
    product_id BIGINT,
    amount DECIMAL,
    region VARCHAR,
    status VARCHAR,
    created_at TIMESTAMPTZ
)
WITH (
    connector = 'kafka',
    topic = 'orders',
    properties.bootstrap.server = 'kafka:9092'
)
FORMAT PLAIN ENCODE JSON;

Continuous Aggregation by Region

This materialized view updates incrementally as new rows arrive in matcmp_orders. No batch job, no scheduled refresh.

CREATE MATERIALIZED VIEW matcmp_revenue_by_region AS
SELECT
    region,
    COUNT(*) AS total_orders,
    SUM(amount) AS total_revenue,
    AVG(amount) AS avg_order_value
FROM matcmp_orders
GROUP BY region;

Query it like a regular table at any time:

SELECT * FROM matcmp_revenue_by_region WHERE region = 'us-east';

Tumbling Window Aggregation

RisingWave extends standard SQL with streaming window functions. TUMBLE divides the time axis into non-overlapping fixed-size windows:

CREATE MATERIALIZED VIEW matcmp_order_counts_per_minute AS
SELECT
    window_start,
    window_end,
    region,
    COUNT(*) AS order_count,
    SUM(amount) AS window_revenue
FROM TUMBLE(matcmp_orders, created_at, INTERVAL '1 MINUTE')
GROUP BY window_start, window_end, region;

This view maintains a per-minute, per-region revenue count that is continuously updated as new orders arrive.

Join Enrichment Across Two Streams

Joining a fast-moving orders stream against a slower-moving inventory table is a common pattern. RisingWave handles this as a streaming join:

CREATE MATERIALIZED VIEW matcmp_enriched_orders AS
SELECT
    o.order_id,
    o.user_id,
    o.amount,
    o.region,
    o.status,
    p.product_name,
    p.category
FROM matcmp_orders o
JOIN matcmp_product_inventory p ON o.product_id = p.product_id;

Cascading Materialized Views

You can build a second materialized view on top of matcmp_enriched_orders, creating a multi-stage pipeline entirely in SQL. Each stage is independently queryable:

CREATE MATERIALIZED VIEW matcmp_category_revenue AS
SELECT
    category,
    COUNT(*) AS order_count,
    SUM(amount) AS total_revenue
FROM matcmp_enriched_orders
GROUP BY category;

matcmp_enriched_orders and matcmp_category_revenue update together whenever new data arrives in the base tables. You query either view at any time.

Top-N Users by Engagement

CREATE MATERIALIZED VIEW matcmp_top_users_by_sessions AS
WITH session_counts AS (
    SELECT
        user_id,
        COUNT(DISTINCT session_id) AS session_count,
        COUNT(*) AS total_views
    FROM matcmp_page_views
    GROUP BY user_id
)
SELECT
    user_id,
    session_count,
    total_views
FROM session_counts
ORDER BY total_views DESC
LIMIT 10;

This Top-N pattern is natively supported by RisingWave's incremental computation engine. The result set is maintained continuously without scanning all rows on every query.

Query Plan Inspection

RisingWave exposes query plans for both streaming and batch paths:

EXPLAIN SELECT * FROM matcmp_revenue_by_region WHERE region = 'us-east';

Output shows a BatchScan with a pushed-down predicate on the materialized view's storage, confirming that the filter is applied at the storage layer and not as a post-scan filter.

Performance Benchmarks

Benchmarking streaming databases is genuinely difficult because performance depends on query complexity, data volume, state size, hardware configuration, and consistency requirements. With those caveats stated, here is what public data shows.

RisingWave Nexmark Benchmark

RisingWave publishes Nexmark benchmark results for version 2.3, tested on three compute nodes (8 vCPUs, 16 GB RAM each). The Nexmark benchmark simulates an online auction system and is the standard suite for evaluating streaming systems.

RisingWave achieves sub-second barrier latency across all queries, meaning results are fresh within one second of the event arriving.

Materialize Performance Profile

Materialize does not publish a comparable public Nexmark benchmark suite with equivalent methodology. Their architecture optimizes for a different profile: strict serializability and low-latency serving for in-memory workloads.

For datasets that fit in the compute cluster's memory, Materialize delivers low query latency with strong consistency guarantees. Differential Dataflow's diff propagation is efficient for workloads with many small updates to a large existing dataset, because only the diffs need to flow through the graph rather than full recomputation.

The practical performance limit for Materialize is memory capacity. As materialized view state grows beyond available RAM on compute replicas, the system needs larger (and more expensive) instances. For RisingWave, the practical performance limit is I/O throughput to and from S3, which scales independently of compute.

In third-party evaluations and community benchmarks, RisingWave consistently shows higher throughput at scale for Nexmark-style workloads, while Materialize shows competitive latency for smaller, memory-resident datasets.

Pricing and Open-Source Status

This dimension has the sharpest contrast between the two systems.

RisingWave: Apache 2.0 Open Source

RisingWave is fully open source under the Apache 2.0 license. The source code is on GitHub and you can run it anywhere: a single developer laptop, a bare-metal server, or a Kubernetes cluster on any cloud provider.

For self-hosted deployments, there is no licensing fee. You pay only for the infrastructure you provision. Because RisingWave's state lives in S3, storage costs are dramatically lower than systems that require local SSD for state management.

RisingWave Cloud offers a managed service with a consumption-based pricing model. You pay for the compute and storage you use, with no fixed cluster sizing required. The managed service handles upgrades, backups, and monitoring.

This open-source approach means there is no vendor lock-in at the licensing level. You can self-host indefinitely without a commercial license, switch cloud providers, or migrate between the self-hosted and managed versions without data format changes.

Materialize: Commercial SaaS

Materialize is a closed-source commercial product delivered as a fully managed cloud service. There is no self-hosted option available to the general public. Pricing is based on cluster credits consumed by compute replicas and storage used.

Materialize's pricing model makes cost predictability straightforward for teams that prefer managed infrastructure, but it introduces vendor dependency that is absent with RisingWave. If Materialize raises prices, changes its offering, or experiences a service disruption, you do not have a self-hosted fallback.

For teams in regulated industries or with data residency requirements, the lack of a self-hosted option may be a blocking constraint.

Pricing Model Comparison

Operational Model

Running Materialize

Materialize is operated entirely as a managed service. You provision cluster replicas through the web console or Terraform, configure sources and sinks via SQL, and observe system behavior through built-in monitoring. There is no infrastructure to manage at the server level.

The operational simplicity of a managed service is real: no Kubernetes to configure, no storage backends to tune, no upgrade procedures to coordinate. However, that simplicity comes at the cost of control. You cannot inspect internal storage files, tune compaction behavior, or run the system in environments where Materialize does not operate.

Cluster sizing is the primary operational lever. Selecting the right replica size for your workload requires estimating the memory footprint of your materialized views, which is not always straightforward for complex queries over high-cardinality data.

Running RisingWave

RisingWave offers both self-hosted and managed operation.

For self-hosted deployments, a development environment runs as a single binary: risingwave playground. A production deployment uses the Kubernetes Helm chart, which configures streaming, serving, compactor, and meta node groups with independent replica counts. Because state lives in object storage, there are no local disks to provision for state management -- you only need compute node sizing for CPU and the in-memory cache.

Operational tasks in a self-hosted RisingWave cluster:

• Scaling compute: adjust the replica count in the Helm values file and apply.
• Upgrading: rolling upgrade via Kubernetes, no manual savepoint management.
• Monitoring: Prometheus metrics exposed natively, with Grafana dashboards available in the operator.
• Backup: snapshots are S3 files; backup involves S3 versioning or cross-region replication.

For teams without dedicated platform engineering capacity, RisingWave Cloud eliminates all of the above. The managed service handles upgrades, scaling, and monitoring automatically.

Full Feature Comparison Table

When to Choose Materialize

Materialize is the right choice when:

You need strict serializability. If your application requires guarantees that all sources are observed at the same consistent point in time, with no anomalies from concurrent updates, Materialize's consistency model provides that guarantee out of the box.

Your state fits in memory and latency is the priority. For datasets where the working set resides in RAM, Materialize's in-memory approach delivers predictable low-latency query serving without cache misses.

You want fully managed operations with no infrastructure overhead. If your team has no interest in running infrastructure and prefers to pay for a service rather than manage a cluster, Materialize's SaaS model eliminates operational work.

You rely on Differential Dataflow's unique capabilities. If your use case involves recursive queries, iterative graph computations, or workloads that specifically benefit from the Timely/Differential programming model, Materialize exposes those capabilities through SQL.

When to Choose RisingWave

RisingWave is the better fit when:

Your state size is large or unpredictable. If your materialized views hold hundreds of gigabytes or terabytes of state, RisingWave's S3-native storage eliminates memory capacity as a bottleneck. State growth is a billing event (S3 storage), not an operational incident.

Cost efficiency is a priority. S3 storage costs roughly one-third as much per GB as EBS. For large-state workloads, the difference in storage cost alone can justify the choice. Self-hosting on your own cloud account eliminates managed service margins entirely.

You need broad connector coverage. If your data sources include Kinesis, Pulsar, MongoDB, SQL Server, or S3 files -- in addition to Kafka -- RisingWave's native connector catalog avoids the need to funnel everything through Kafka first.

You want open-source flexibility. Running RisingWave on your own infrastructure, in any cloud or on-premises, gives you control over data residency, upgrade timing, and long-term vendor independence.

You are building high-throughput Kafka pipelines. RisingWave's Kafka connector is highly optimized for throughput and has been tested at production scale across multiple releases. For teams with high-volume Kafka-to-analytics pipelines, RisingWave's architecture absorbs scale more naturally because compute and storage scale independently.

You need higher-throughput streaming. For Nexmark-class workloads, RisingWave's publicly benchmarked throughput numbers exceed what Materialize has published. If raw processing throughput is a requirement, RisingWave's published data provides a concrete reference point.

Frequently Asked Questions

Is Materialize open source?

No. Materialize is a proprietary, closed-source commercial product delivered as a managed cloud service. The source code is not publicly available, and there is no self-hosted version available to the general public. By contrast, RisingWave is fully open source under the Apache 2.0 license, with source code on GitHub and an active contributor community.

How do Materialize and RisingWave handle large state?

Materialize holds active materialized view state in memory on compute replicas. As state grows, you need larger (and more expensive) replica instances. RisingWave stores all state in S3-compatible object storage via the Hummock engine, with local memory serving as a cache. State size is bounded only by object storage capacity, making RisingWave significantly more cost-effective for workloads with hundreds of gigabytes or terabytes of state.

Which system has better Kafka integration?

Both Materialize and RisingWave have mature Kafka source connectors with Avro, Protobuf, and JSON encoding support. Materialize's Kafka integration handles out-of-order messages and retractions elegantly through Differential Dataflow's native diff model. RisingWave's Kafka connector is optimized for high throughput and supports configurable parallelism -- you can scale Kafka ingestion independently of downstream processing. For teams running high-volume Kafka pipelines, RisingWave's architecture tends to sustain higher sustained throughput because compute and storage scale independently.

Can I self-host either system?

RisingWave can be self-hosted anywhere: a laptop, a bare-metal server, or Kubernetes on any cloud provider. It runs as a single binary for development and as a multi-node Kubernetes deployment for production. No license fee applies for self-hosted deployments. Materialize does not offer a self-hosted option for general availability -- all deployments run on Materialize's managed cloud.

Conclusion

Materialize and RisingWave are serious, production-grade streaming databases built by strong engineering teams. The choice between them comes down to a small number of decisive factors:

If your working state fits in memory, you need strict serializability, and you want a fully managed service with no infrastructure work, Materialize is a strong fit. Its Differential Dataflow foundation handles certain workloads elegantly, and its managed-only model removes operational overhead.

If your state is large or growing, cost efficiency matters, you need connectors beyond Kafka, or you want the flexibility of open-source self-hosting, RisingWave's architecture is better matched to those requirements. The S3-native storage model is a fundamental advantage for large-state workloads -- not a configuration option, but an architectural guarantee. The Apache 2.0 license means no vendor dependency on licensing, and the Kafka connector has the throughput headroom to grow with your pipeline.

For most data engineering teams building real-time analytics pipelines, RisingWave's combination of PostgreSQL-compatible SQL, cloud-native storage, and open-source availability positions it as the more flexible long-term foundation. For teams with smaller datasets and a preference for fully managed infrastructure, Materialize's polished SaaS offering reduces friction.

The best path forward: run a proof of concept with your actual queries and data volumes. Both systems support PostgreSQL-compatible SQL, so migrating a test pipeline is a matter of hours, not weeks.