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
| Dimension | RisingWave | Materialize |
| Compute model | Distributed actors with shared-nothing architecture | Timely Dataflow workers with differential dataflow |
| State storage | Hummock (LSM-tree on object storage) | In-memory with Persist layer for durability |
| Storage-compute coupling | Fully decoupled | Compute holds active state in memory |
| Scaling model | Add/remove compute nodes independently | Scale via cluster replicas |
| Memory pressure handling | Spills to object storage naturally | Constrained 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:
| Query | Throughput (kr/s) | Per-Core Efficiency (kr/s/core) | Query Type |
| q1 (Currency Conversion) | 893.2 | 37.2 | Simple projection |
| q2 (Selection) | 764.6 | 127.4 | Filtered selection |
| q5 (Hot Items) | 451.3 | 18.8 | Sliding window aggregation |
| q7 (Highest Bid) | 312.8 | 13.0 | Tumbling window join |
| q7-rewrite | 770.0 | 32.1 | Optimized tumbling window |
| q9 (Winning Bids) | 285.4 | 11.9 | Complex multi-way join |
| q18 (Find Last Auction) | 398.7 | 16.6 | Windowed 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
| Metric | RisingWave | Materialize |
| Peak throughput (simple queries) | 893 kr/s | Not publicly benchmarked at scale |
| Per-core efficiency | Up to 127 kr/s/core | Competitive for in-memory workloads |
| Barrier latency | Sub-second (1s checkpoints) | Sub-second for in-memory state |
| Large-state handling | Scales to object storage | Memory-bound |
| Consistency model | Eventual 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
| Feature | RisingWave | Materialize |
| PostgreSQL wire protocol | Yes | Yes |
| Incremental materialized views | Yes | Yes |
| Window functions in MVs | Yes | Yes |
| Temporal filters | Yes | Yes |
| CDC sources (PostgreSQL, MySQL) | Yes | Yes |
| Kafka source/sink | Yes | Yes |
| Iceberg sink | Yes | Limited |
| UDFs (Python, Java, JS) | Yes | Limited (SQL-only UDFs) |
| SUBSCRIBE/Change streams | Yes (via sinks) | Yes (native SUBSCRIBE) |
| EXPLAIN for streaming plans | Yes | Yes |
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:
- The Meta Node injects barrier markers into the data stream.
- Compute nodes align barriers across parallel inputs.
- When barriers arrive, each node snapshots its operator state to Hummock (on object storage).
- 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
| Aspect | RisingWave | Materialize |
| Recovery mechanism | Checkpoint-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 tolerance | Minimal (checkpoints to object storage) | 2x+ compute (each replica runs full computation) |
| State durability | Object 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 Factor | RisingWave (Self-Hosted) | RisingWave Cloud | Materialize Cloud |
| Compute (monthly) | ~$500 (3x r6i.xlarge) | ~$650 (estimated) | ~$2,100+ (3x cluster units) |
| Storage (monthly) | ~$5 (S3) | Included | Included |
| Fault tolerance overhead | Minimal (checkpoints) | Minimal | 2x compute for replicas |
| Self-hosting option | Yes (Apache 2.0) | N/A | Limited (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
| Category | Feature | RisingWave | Materialize |
| Architecture | Compute engine | Distributed actors (Rust) | Timely Dataflow (Rust) |
| State backend | Hummock (LSM on object storage) | In-memory + Persist layer | |
| Storage-compute separation | Full | Partial | |
| SQL | PostgreSQL compatibility | Wire-compatible | Wire-compatible |
| Incremental MVs | Yes | Yes | |
| Joins in MVs | Inner, left, right, full, semi, anti | Inner, left, right, full, cross | |
| Window functions | Yes | Yes | |
| UDFs | Python, Java, JavaScript | SQL-based | |
| Connectors | Kafka source/sink | Yes | Yes |
| PostgreSQL CDC | Yes | Yes | |
| MySQL CDC | Yes | Yes | |
| Iceberg sink | Yes | Limited | |
| S3 source | Yes | No | |
| Kinesis source | Yes | No | |
| Pulsar source | Yes | No | |
| Performance | Nexmark peak throughput | 893 kr/s (q1) | Not publicly benchmarked |
| Barrier latency | Sub-second | Sub-second | |
| Large state handling | Object storage spillover | Memory-bound | |
| Operations | Scaling | Elastic (add/remove nodes) | Cluster replicas |
| Recovery mechanism | Checkpoint + replay | Active replication | |
| Recovery time | Seconds | Near-zero (with replicas) | |
| Recovery cost | Low (checkpoints to S3) | High (2x+ compute) | |
| Licensing | License | Apache 2.0 | BSL 1.1 (Apache 2.0 after 4 years) |
| Self-hosted | Full features | CE capped at 24 GiB | |
| Cloud offering | AWS, GCP, Azure | AWS (Materialize Cloud) | |
| Cost | Entry price (cloud) | $0.227/RWU/hr | $0.98/hr |
| Self-hosted cost | Infrastructure only | Free (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.

