“Materialized view” means two very different things depending on the engine. In a traditional database it’s a snapshot you recompute. In a streaming engine like RisingWave it’s a result that maintains itself. The distinction decides whether you can build real-time systems on it.
The traditional kind
A PostgreSQL materialized view runs its query once and stores the output. It’s stale until you REFRESH it, which re-runs the query (incrementally diffing, with CONCURRENTLY, but still triggered on a schedule or by hand). Freshness is whatever your refresh cadence is.
The streaming kind
A streaming materialized view is continuously maintained. When a new event arrives, the engine updates only the parts of the result that change, with no full re-run and no timer. The view is always current to within milliseconds because maintaining it is the act of ingesting. This is what “incremental” means: the cost is proportional to what changed, paid continuously, not to the whole dataset paid on a schedule.
Why it enables real-time
If your detection logic is a streaming MV, “has this agent exceeded its rate?” is answered the instant the threshold is crossed, because the count updated as the event landed. There’s no window to wait for. That’s the property micro-batch can’t offer: micro-batch still has an interval, just a short one. Incremental has no interval at all.
The trade-off
Continuous maintenance costs continuous compute and memory (the engine holds windowed state). For genuinely real-time needs it’s worth it; for a report that’s fine being an hour old, a traditional refreshed view is far cheaper. Don’t run a streaming engine to power a daily dashboard.
Takeaway
Traditional MV: recompute on demand, stale between refreshes. Streaming MV: self-maintaining, always current, costs continuous resources. Reach for incremental views when the answer must be true now, and only then.
