Most analytics queries do the same work repeatedly: group by a few dimensions, sum or count, filter by a time range. A materialized view runs that work once at ingestion time and keeps the rolled-up result up to date as rows arrive. Reads hit the small precomputed table; the cost of the heavy aggregation is paid in the background.
In real-time analytics, materialized views are the default tool for collapsing high-cardinality event streams into per-minute, per-user, or per-tenant aggregates that an API can serve under p99 latency targets. They differ from a cached query in that they are part of the database, transactional with the source, and recomputed incrementally rather than on a refresh interval.
Common confusions: a materialized view is not a regular view (which re-runs the query every time it is read), and it is not a static snapshot (it stays in sync with the source). In Tinybird, materialized views are defined as pipes that write into a target data source.
Tinybird pipe that materializes hourly request counts
NODE hourly_requests
SQL >
SELECT
toStartOfHour(timestamp) AS hour,
tenant_id,
count() AS requests
FROM events
GROUP BY hour, tenant_id
TYPE materialized
DATASOURCE requests_per_hour_mv