Materialized Views Explained: From Databases to Streaming (2026)
A materialized view is a precomputed query result stored as a table that can be queried directly — unlike a regular view, which re-executes its query every time. In streaming databases like RisingWave, materialized views update automatically and incrementally as source data changes, providing sub-second data freshness without manual refresh commands.
How Materialized Views Work
Traditional (PostgreSQL)
CREATE MATERIALIZED VIEW sales_summary AS
SELECT region, SUM(amount) as total FROM orders GROUP BY region;
-- Must manually refresh
REFRESH MATERIALIZED VIEW sales_summary; -- Recomputes entirely
Problem: Full recomputation is expensive. A billion-row table takes minutes to refresh, and data is stale between refreshes.
Streaming (RisingWave)
CREATE MATERIALIZED VIEW sales_summary AS
SELECT region, SUM(amount) as total FROM orders_stream GROUP BY region;
-- Automatically updates within milliseconds of new data
Solution: Incremental view maintenance — only process the changes, not the entire dataset.
Types of Materialized View Refresh
| Type | How It Works | Freshness | Cost | Used By |
| Full refresh | Recompute entire query | Minutes-old | High | PostgreSQL, dbt |
| Incremental refresh | Process only changes | Seconds-old | Medium | Databricks, ClickHouse |
| Streaming (continuous) | Update on every event | Sub-second | Low per-update | RisingWave, Materialize |
Cascading Materialized Views
In RisingWave, you can stack materialized views — downstream views automatically update when upstream views change:
-- Base aggregation
CREATE MATERIALIZED VIEW regional_sales AS
SELECT region, SUM(amount) as revenue FROM orders GROUP BY region;
-- Derived view (automatically updates when regional_sales changes)
CREATE MATERIALIZED VIEW top_regions AS
SELECT * FROM regional_sales WHERE revenue > 1000000 ORDER BY revenue DESC;
This composability makes complex streaming pipelines easy to build and maintain.
When to Use Materialized Views
Use materialized views when:
- Queries are known in advance and run frequently
- Data freshness matters (seconds, not hours)
- Multiple consumers need the same aggregation
- You want to precompute expensive joins/aggregations
Use regular queries when:
- Queries are ad-hoc and exploratory
- Data doesn't change frequently
- Storage cost is a concern
Frequently Asked Questions
What is the difference between a view and a materialized view?
A regular view re-executes its query every time you read it — it's just a saved query. A materialized view stores the precomputed result, so reads are instant. The trade-off is that materialized views consume storage and must be refreshed (manually in PostgreSQL, automatically in streaming databases).
Do materialized views work with streaming data?
Yes. Streaming databases like RisingWave and Materialize maintain materialized views that update continuously as new data arrives. This is called incremental view maintenance — only the changes are processed, not the entire dataset.
Can I use materialized views instead of a cache?
In many cases, yes. A streaming materialized view serves fresh, precomputed results via SQL — replacing Redis or Memcached for read-heavy workloads where the "cache" is a precomputed aggregation.

