RisingWave vs Materialize: Performance Benchmark 2026

RisingWave vs Materialize: Performance Benchmark 2026

Choosing between streaming databases is one of the most consequential infrastructure decisions a data engineering team makes. Get it wrong, and you are locked into a system that does not scale with your workload, burns through your cloud budget, or forces painful workarounds every time requirements shift.

RisingWave and Materialize are the two most prominent streaming SQL databases in 2026. Both promise PostgreSQL-compatible SQL over continuously changing data. Both maintain incrementally updated materialized views. But beneath that shared surface, they diverge sharply in architecture, performance characteristics, deployment flexibility, and cost. This benchmark comparison breaks down those differences with concrete data so you can make an informed choice.

By the end of this article, you will understand the architectural trade-offs between Hummock and Timely Dataflow, see how each system performs under Nexmark workloads, and know which system fits your team's requirements for scalability, fault tolerance, and total cost of ownership.

Architecture: Hummock vs Timely Dataflow

The most fundamental difference between RisingWave and Materialize is how they manage state during stream processing.

RisingWave: Hummock Storage Engine

RisingWave uses Hummock, a purpose-built, cloud-native LSM-tree storage engine. Hummock was designed from scratch for streaming workloads. Here is how it works:

  • Write path: Incoming state changes are buffered in memory (mem-tables), then flushed as immutable, sorted SSTables to cloud object storage (S3, GCS, or Azure Blob Storage).
  • Compaction: Background compactor nodes merge SSTables, remove obsolete entries, and optimize read performance without blocking the streaming pipeline.
  • Separation of storage and compute: Compute nodes are stateless with respect to durable state. They fetch from and persist to Hummock, which sits on object storage. This enables independent scaling of compute and storage resources.

The architecture is coordinated by a Meta Node that orchestrates checkpointing, manages Hummock metadata, and assigns compaction tasks. This design means RisingWave can scale horizontally by simply adding compute nodes, while storage scales elastically through the cloud provider's object storage.

Materialize: Timely Dataflow and Differential Dataflow

Materialize is built on Timely Dataflow and Differential Dataflow, frameworks that originated at Microsoft Research. The core insight behind Differential Dataflow is representing data changes as collections of diffs rather than whole relations, enabling efficient incremental computation.

Materialize's architecture is split into three logical components:

  • Storage (including Persist): Handles data ingestion and durable storage of input data and state.
  • Adapter: Manages the PostgreSQL-compatible SQL interface and query planning.
  • Compute: Runs Timely Dataflow operators that process data incrementally.

Timely Dataflow supports inter-query parallelism (different operators on different workers) and intra-operator parallelism (sharding a logical operator across workers). Materialize uses a Persist layer backed by blob storage and a consensus service for durable state, but compute nodes hold state in memory for active processing.

Architectural Trade-offs

DimensionRisingWaveMaterialize
Compute modelDistributed actors with shared-nothing architectureTimely Dataflow workers with differential dataflow
State storageHummock (LSM-tree on object storage)In-memory with Persist layer for durability
Storage-compute couplingFully decoupledCompute holds active state in memory
Scaling modelAdd/remove compute nodes independentlyScale via cluster replicas
Memory pressure handlingSpills to object storage naturallyConstrained by available memory per replica

The practical implication: RisingWave handles large state workloads (joins over big windows, high-cardinality aggregations) more gracefully because state overflows to cheap object storage. Materialize's in-memory approach delivers lower latency for workloads that fit in memory but requires careful capacity planning when state grows.

Nexmark Benchmark Performance

The Nexmark benchmark is the industry-standard suite for evaluating streaming systems. It simulates an online auction system with three event types (persons, auctions, bids) and defines queries that stress different aspects of stream processing: filtering, joins, windowed aggregations, and complex event processing.

RisingWave Nexmark Results

RisingWave publishes Nexmark benchmark results tested on version 2.3 with three compute nodes, each configured with 8 CPU cores and 16 GB RAM. Key throughput numbers:

QueryThroughput (kr/s)Per-Core Efficiency (kr/s/core)Query Type
q1 (Currency Conversion)893.237.2Simple projection
q2 (Selection)764.6127.4Filtered selection
q5 (Hot Items)451.318.8Sliding window aggregation
q7 (Highest Bid)312.813.0Tumbling window join
q7-rewrite770.032.1Optimized tumbling window
q9 (Winning Bids)285.411.9Complex multi-way join
q18 (Find Last Auction)398.716.6Windowed aggregation

RisingWave achieves sub-second barrier latency across these workloads, meaning materialized view results are fresh within one second of the source event arriving.

Materialize Nexmark Context

Materialize does not publish a comparable public Nexmark benchmark suite with the same methodology. Their architecture optimizes for a different profile: strong consistency (strict serializability) across all sources, which adds coordination overhead but guarantees correctness for workloads with mutable data, late arrivals, and out-of-order updates.

In community-reported tests and third-party evaluations, Materialize shows competitive latency for low-to-medium throughput workloads, particularly on queries that benefit from Differential Dataflow's efficient diff propagation. However, throughput tends to plateau earlier than RisingWave's under high event rates because the in-memory state model requires all active state to fit in RAM.

Performance Summary

MetricRisingWaveMaterialize
Peak throughput (simple queries)893 kr/sNot publicly benchmarked at scale
Per-core efficiencyUp to 127 kr/s/coreCompetitive for in-memory workloads
Barrier latencySub-second (1s checkpoints)Sub-second for in-memory state
Large-state handlingScales to object storageMemory-bound
Consistency modelEventual consistency (per-barrier)Strict serializability

SQL Compatibility and PostgreSQL Ecosystem

Both systems use PostgreSQL as their SQL dialect and wire protocol, but implementation depth varies.

RisingWave SQL Support

RisingWave is wire-compatible with PostgreSQL. You can connect with psql, JDBC, Python psycopg2, Go pgx, and any other PostgreSQL client. Supported SQL features include:

  • Materialized views with incremental maintenance (aggregations, joins, distinct, top-N, window functions)
  • Sources and sinks for Kafka, Pulsar, Kinesis, PostgreSQL CDC, MySQL CDC, S3, Iceberg, and more
  • User-defined functions in Python, Java, and JavaScript
  • EXPLAIN for streaming query plans
  • Indexes on materialized views for point-lookup acceleration

RisingWave is fully open source under the Apache 2.0 license, which means you can self-host, modify, and redistribute without restriction.

Materialize SQL Support

Materialize also speaks PostgreSQL wire protocol and supports a broad SQL surface:

  • Materialized views with strict-serializable consistency
  • Sources for Kafka, PostgreSQL CDC, MySQL CDC, and webhooks
  • Sinks for Kafka and other destinations
  • SUBSCRIBE for push-based change notifications
  • Clusters for workload isolation and independent scaling

As of 2025, Materialize offers a Community Edition under the BSL 1.1 license (converting to Apache 2.0 after four years). The CE is capped at 24 GiB memory and 48 GiB disk per installation. Enterprise features and Materialize Cloud require commercial licensing.

SQL Feature Comparison

FeatureRisingWaveMaterialize
PostgreSQL wire protocolYesYes
Incremental materialized viewsYesYes
Window functions in MVsYesYes
Temporal filtersYesYes
CDC sources (PostgreSQL, MySQL)YesYes
Kafka source/sinkYesYes
Iceberg sinkYesLimited
UDFs (Python, Java, JS)YesLimited (SQL-only UDFs)
SUBSCRIBE/Change streamsYes (via sinks)Yes (native SUBSCRIBE)
EXPLAIN for streaming plansYesYes

Scalability: Horizontal Growth Under Load

RisingWave Scalability

RisingWave's decoupled architecture makes horizontal scaling straightforward. Adding compute nodes increases processing capacity without migrating state, because state lives in object storage. The system supports:

  • Elastic scaling: Add or remove compute nodes based on workload. The Meta Node redistributes streaming tasks automatically.
  • Independent storage scaling: Object storage (S3/GCS) scales without any user intervention.
  • Multi-tenancy: Multiple streaming jobs share a cluster with resource isolation.

In practice, teams scale RisingWave from a single node (for development) to dozens of compute nodes (for production) without architectural changes. The RisingWave Cloud offering automates this scaling on AWS, GCP, and Azure.

Materialize Scalability

Materialize scales through cluster replicas. Each cluster is an independent set of Timely Dataflow workers. You can:

  • Add replicas within a cluster for fault tolerance and read scaling.
  • Create separate clusters for workload isolation (e.g., one cluster for ingestion, another for serving queries).
  • Size clusters based on memory and compute requirements.

The constraint is that each cluster must hold its active state in memory. For workloads that exceed a single cluster's memory capacity, you need to partition workloads across multiple clusters manually, which adds operational complexity.

Fault Tolerance and Recovery

RisingWave: Checkpoint-Based Recovery

RisingWave uses the Chandy-Lamport algorithm for distributed snapshots. The process works like this:

  1. The Meta Node injects barrier markers into the data stream.
  2. Compute nodes align barriers across parallel inputs.
  3. When barriers arrive, each node snapshots its operator state to Hummock (on object storage).
  4. Snapshots happen asynchronously in the background, minimizing impact on processing throughput.

When a compute node fails, the Meta Node detects the failure and reschedules tasks to healthy nodes. Those nodes restore state from the last checkpoint in Hummock. Recovery typically completes in seconds because state is already on durable object storage, and only records since the last checkpoint need to be replayed.

Default checkpoint interval is one second, giving a recovery point objective (RPO) of roughly one second.

Materialize: Active Replication

Materialize takes a different approach: active replication via cluster replicas. When you provision multiple replicas for a cluster:

  • Each replica independently processes the same input stream.
  • If one replica fails, the remaining replicas continue serving queries without interruption.
  • The failed replica is replaced and catches up from the Persist layer.

This model provides near-zero recovery time for read queries (surviving replicas serve immediately) but doubles (or more) the compute cost because every replica does the full computation. It is effectively hot standby at the compute level.

Recovery Comparison

AspectRisingWaveMaterialize
Recovery mechanismCheckpoint-based (Chandy-Lamport)Active replication (cluster replicas)
Recovery time (RTO)Seconds (reload from object storage)Near-zero for reads (surviving replicas)
Recovery point (RPO)~1 second (checkpoint interval)Zero (replicas are in sync)
Cost of fault toleranceMinimal (checkpoints to object storage)2x+ compute (each replica runs full computation)
State durabilityObject storage (11 nines durability)Persist layer on blob storage

Cost Analysis: Total Cost of Ownership

Cost is often the deciding factor, especially for teams running streaming workloads 24/7.

RisingWave Pricing

  • Self-hosted (open source): Free under Apache 2.0. You pay only for your cloud infrastructure (compute instances + object storage). Object storage costs are negligible at scale (S3: ~$0.023/GB/month).
  • RisingWave Cloud: Starts at $0.227 per RWU (RisingWave Unit) per hour, with a 7-day free trial. Available on AWS, GCP, and Azure via marketplace. Annual commitments unlock volume discounts.

Materialize Pricing

  • Community Edition (self-managed): Free under BSL 1.1, but capped at 24 GiB memory and 48 GiB disk. No time limit.
  • Self-Managed (enterprise): Requires a commercial license for larger deployments.
  • Materialize Cloud: Starts at $0.98 per hour for the smallest cluster. Credit-based pricing with the Cloud Capacity plan offers volume discounts.

Cost Comparison Scenario

Consider a mid-size streaming workload: 100,000 events/second, 50 GB of active state, running 24/7.

Cost FactorRisingWave (Self-Hosted)RisingWave CloudMaterialize Cloud
Compute (monthly)~$500 (3x r6i.xlarge)~$650 (estimated)~$2,100+ (3x cluster units)
Storage (monthly)~$5 (S3)IncludedIncluded
Fault tolerance overheadMinimal (checkpoints)Minimal2x compute for replicas
Self-hosting optionYes (Apache 2.0)N/ALimited (BSL, capped CE)
Annual estimate~$6,000~$7,800~$25,000+

The cost gap widens significantly for larger workloads. RisingWave's ability to offload state to object storage means you do not need memory-heavy instances, while Materialize's in-memory model requires provisioning enough RAM for all active state plus headroom.

Comprehensive Feature Comparison Table

CategoryFeatureRisingWaveMaterialize
ArchitectureCompute engineDistributed actors (Rust)Timely Dataflow (Rust)
State backendHummock (LSM on object storage)In-memory + Persist layer
Storage-compute separationFullPartial
SQLPostgreSQL compatibilityWire-compatibleWire-compatible
Incremental MVsYesYes
Joins in MVsInner, left, right, full, semi, antiInner, left, right, full, cross
Window functionsYesYes
UDFsPython, Java, JavaScriptSQL-based
ConnectorsKafka source/sinkYesYes
PostgreSQL CDCYesYes
MySQL CDCYesYes
Iceberg sinkYesLimited
S3 sourceYesNo
Kinesis sourceYesNo
Pulsar sourceYesNo
PerformanceNexmark peak throughput893 kr/s (q1)Not publicly benchmarked
Barrier latencySub-secondSub-second
Large state handlingObject storage spilloverMemory-bound
OperationsScalingElastic (add/remove nodes)Cluster replicas
Recovery mechanismCheckpoint + replayActive replication
Recovery timeSecondsNear-zero (with replicas)
Recovery costLow (checkpoints to S3)High (2x+ compute)
LicensingLicenseApache 2.0BSL 1.1 (Apache 2.0 after 4 years)
Self-hostedFull featuresCE capped at 24 GiB
Cloud offeringAWS, GCP, AzureAWS (Materialize Cloud)
CostEntry price (cloud)$0.227/RWU/hr$0.98/hr
Self-hosted costInfrastructure onlyFree (CE limits) or license fee

What Is the Difference Between RisingWave and Materialize?

RisingWave is a cloud-native streaming database that uses Hummock, an LSM-tree storage engine on object storage, to decouple compute from state. Materialize is a streaming SQL database built on Timely Dataflow and Differential Dataflow that holds active state in memory for low-latency incremental computation. The core difference comes down to architecture: RisingWave optimizes for elastic scalability and cost efficiency through its storage-compute separation, while Materialize optimizes for strict consistency guarantees at the expense of higher memory requirements and compute costs.

For teams building high-throughput streaming pipelines with large state (event-driven analytics, IoT aggregations, real-time dashboards), RisingWave's architecture typically delivers better price-performance. For teams that need strict-serializable consistency across all queries and are comfortable with a managed cloud service, Materialize provides stronger correctness guarantees out of the box.

Which Streaming Database Has Better Nexmark Benchmark Performance?

RisingWave publishes detailed Nexmark benchmark results showing throughput up to 893,000 records per second on simple queries and strong per-core efficiency across complex queries involving joins, windows, and aggregations. Materialize does not publish equivalent public benchmarks using the same Nexmark methodology, making a direct apples-to-apples comparison difficult. In general, RisingWave's cloud-native architecture with Hummock gives it an advantage in sustained high-throughput scenarios, while Materialize's in-memory Differential Dataflow engine can deliver very low latency for workloads that fit entirely in memory.

Is RisingWave or Materialize Better for Cost-Sensitive Teams?

RisingWave is significantly more cost-effective for most streaming workloads. Its Apache 2.0 license means you can self-host the full-featured system for free, paying only for infrastructure. The Hummock storage engine uses cheap object storage (S3/GCS) instead of expensive RAM for state, which reduces instance costs substantially. Materialize's Cloud pricing starts at $0.98/hour, and its in-memory model requires memory-optimized instances that cost 2-4x more than general-purpose compute. For a typical mid-size workload running 24/7, the annual cost difference can be $15,000 or more.

Can I Self-Host Materialize in 2026?

Yes, with limitations. Materialize released a Community Edition in 2025 under the BSL 1.1 license that allows self-hosted deployments. However, the CE is capped at 24 GiB memory and 48 GiB disk per installation. For production workloads that exceed these limits, you need either a commercial Self-Managed license or Materialize Cloud. RisingWave, by contrast, is fully open source under Apache 2.0 with no feature gates or resource caps on self-hosted deployments.

Conclusion

Both RisingWave and Materialize are serious streaming SQL databases built by talented engineering teams. The right choice depends on your specific requirements:

  • Choose RisingWave if you need elastic horizontal scaling, cost-efficient handling of large state, a fully open-source license, multi-cloud deployment flexibility, or the broadest connector ecosystem (Kafka, Pulsar, Kinesis, Iceberg, S3, CDC).
  • Choose Materialize if strict-serializable consistency is a hard requirement for your workload, your active state fits comfortably in memory, and you prefer a managed cloud-first experience.

For the majority of streaming analytics and event-driven workloads in 2026, RisingWave offers the better combination of performance, scalability, and cost. Its Hummock storage engine eliminates the memory ceiling that constrains Materialize, its Apache 2.0 license gives you full deployment freedom, and its Nexmark benchmark results demonstrate industry-leading throughput.


Ready to benchmark RisingWave on your own workload? Try RisingWave Cloud free, no credit card required. Sign up here.

Join our Slack community to ask questions and connect with other stream processing developers.

Best-in-Class Event Streaming
for Agents, Apps, and Analytics
GitHubXLinkedInSlackYouTube
Sign up for our to stay updated.