Creates a pre-computed, queryable snapshot of data that can be refreshed on demand or automatically.
Materialized views store the result of a costly query, letting dashboards and APIs read pre-aggregated data instead of re-scanning large tables. This cuts latency and cluster workload.
Use one when the underlying data changes less frequently than it’s queried, and performance matters more than always-current results.Ideal for daily sales summaries, cohort reports, and API endpoints.
Issue CREATE MATERIALIZED VIEW
with distribution, sort keys, and optional AUTO REFRESH
.Define only the columns you actually need to keep the view small.
CREATE MATERIALIZED VIEW sales_summary_mv
AUTO REFRESH YES
DISTKEY(customer_id)
SORTKEY(order_date)
AS
SELECT c.id AS customer_id,
DATE_TRUNC('month', o.order_date) AS month,
SUM(o.total_amount) AS monthly_spend
FROM customers c
JOIN orders o ON o.customer_id = c.id
GROUP BY c.id, DATE_TRUNC('month', o.order_date);
Run REFRESH MATERIALIZED VIEW schema.view_name;
.Schedule it in your orchestrator or let Redshift auto-refresh if the view was created with AUTO REFRESH YES
.
Use DROP MATERIALIZED VIEW
to remove it, or ALTER MATERIALIZED VIEW
to toggle auto-refresh, change backup settings, or rename the view.
Choose DISTKEY and SORTKEY that match common filter columns, store only required columns, and refresh during low-traffic windows.Monitor STV_RECENTS
for lock contention.
Redshift automatically tracks changes with MV logs. Ensure base tables have primary keys to maximize incremental refresh efficiency.
Query SVV_MV_INFO
to inspect last_refresh
, refresh_type
, and if the next automatic refresh is scheduled.
.
During refresh, Redshift locks the view for reads for a short time. Keep queries short and schedule refresh when traffic is low.
Yes—select only the columns you need in the CREATE statement. Fewer columns mean faster refresh and less storage.
Query SVL_MV_REFRESH_STATUS and CloudWatch metrics to track duration, rows scanned, and incremental refresh ratio.