GUIDE

Materialized Views Explained

Q: Do materialized views consume more storage than regular views?

Yes. Materialized views store their computed results physically, so they consume disk or memory. Regular views store only the query definition and compute results at query time. The trade-off is storage cost for dramatically faster read performance.

Q: Can materialized views include JOINs and aggregations?

Yes. Materialized views can include any SQL constructs — JOINs, GROUP BY, window functions, subqueries, HAVING clauses, and complex expressions. In RisingWave, these are incrementally maintained so that even complex multi-table joins stay fresh automatically.

Q: How often are materialized views refreshed in RisingWave?

RisingWave uses incremental maintenance, not periodic refresh. Materialized views update continuously as new data arrives — typically within milliseconds. There is no refresh interval to configure because updates are event-driven, not schedule-driven.

Q: Can I build materialized views on top of other materialized views?

Yes. RisingWave supports cascading materialized views where one view reads from another. Changes propagate through the entire chain automatically, enabling layered transformations — for example, a raw events view feeding into an aggregation view feeding into an alerting view.

Materialized views pre-compute and store query results for fast reads. Learn the difference between regular views, materialized views, and incrementally maintained materialized views — and how RisingWave keeps them always fresh.

Try RisingWave Free Streaming Database Guide

Pre-Computed

Instant Reads

Query results are stored physically — reads return in milliseconds, not seconds

Incremental

Update Strategy

Only changed rows are recomputed, not the entire dataset — orders of magnitude faster

Cascading

View Chains

Build views on top of views — changes propagate through the entire DAG automatically

Always Fresh

No Manual Refresh

RisingWave updates materialized views continuously as data arrives — no REFRESH command needed

Core Concept

What is a materialized view and how does it work?

A materialized view is a database object that stores the result of a query physically on disk. Unlike a regular view — which re-executes its defining query every time you read from it — a materialized view computes the result once and serves it instantly on subsequent reads, trading storage space for dramatically faster query performance.

Characteristic	Regular View	Materialized View	Incremental MV (RisingWave)
Storage	None (query alias only)	Stores full result set	Stores full result set
Read Speed	Slow (re-executes query)	Fast (pre-computed)	Fast (pre-computed)
Freshness	Always current	Stale until refreshed	Always current (auto-updated)
Update Method	N/A	REFRESH MATERIALIZED VIEW	Automatic incremental updates
Write Cost	None	Full recompute on refresh	Incremental (only changed rows)
Best For	Query reuse, abstraction	Read-heavy batch analytics	Real-time dashboards, streaming

In traditional databases like PostgreSQL, a materialized view must be refreshed manually using REFRESH MATERIALIZED VIEW. This full recomputation can be expensive and creates a window where results are stale. Incremental maintenance — the approach used by RisingWave — eliminates both problems by updating only the rows affected by each incoming change.

→Full refresh: PostgreSQL re-scans the entire source table on every REFRESH command. A 100M-row table takes minutes to refresh.
→Incremental maintenance: RisingWave processes only the delta — if 10 rows change, only those 10 rows are recomputed in the materialized view.
→Cascading updates: when a materialized view depends on another materialized view, incremental changes propagate through the entire chain automatically.
→Consistency: RisingWave uses barrier-based checkpointing to ensure all materialized views reflect a consistent snapshot of the source data.

How It Works

What is the difference between full refresh and incremental maintenance?

Full refresh recomputes the entire materialized view from scratch each time it updates — re-reading all source data and re-executing the full query. Incremental maintenance tracks which source rows changed and updates only the affected output rows. For large datasets, incremental maintenance is orders of magnitude faster and enables real-time freshness.

Sub-Second Freshness

Incremental updates process in milliseconds, keeping materialized views current without manual refresh commands.

Lower Compute Cost

Processing only changed rows uses a fraction of the CPU compared to full recomputation on every refresh cycle.

Consistent Snapshots

Barrier-based checkpointing ensures that all materialized views reflect the same point-in-time state across the system.

Cascading Propagation

Build views on top of views. Changes flow through the entire DAG automatically — no orchestration logic needed.

Getting Started

How do you create and use materialized views in RisingWave?

Creating a materialized view in RisingWave uses standard PostgreSQL syntax: CREATE MATERIALIZED VIEW view_name AS SELECT ... The view begins ingesting and processing data immediately. You query it with a normal SELECT statement, and results reflect the latest state of the underlying streams — no refresh command needed.

→Step 1: Create a source — CREATE SOURCE to connect to Kafka, Pulsar, or a CDC stream from your database.
→Step 2: Define the materialized view — CREATE MATERIALIZED VIEW with your SQL transformation (JOINs, aggregations, filters).
→Step 3: Query the view — SELECT * FROM your_view returns pre-computed, always-fresh results in milliseconds.
→Step 4: Sink to downstream — CREATE SINK to push materialized view updates to Kafka, PostgreSQL, Elasticsearch, or other systems.

Frequently Asked Questions

Do materialized views consume more storage than regular views?

Can materialized views include JOINs and aggregations?

How often are materialized views refreshed in RisingWave?

Can I build materialized views on top of other materialized views?

Ready to try materialized views?

Start building always-fresh materialized views with SQL in minutes.

Try Materialized Views in RisingWave

Streaming Database Guide →Streaming SQL Guide →