Build the mental model
A regular view is a saved query evaluated against current tables. A materialized view stores its result, so reads can be faster but remain stale until refreshed. Do not treat a view as the only security boundary; privileges and row-level security still matter.
Connect it to a real scenario
Expose a stable published-catalog interface with a view and store daily analytics in a materialized view. `REFRESH MATERIALIZED VIEW CONCURRENTLY` requires a suitable unique index.
Try the working example
CREATE VIEW app.published_catalog AS
SELECT tutorial_id, title, slug, published_at
FROM app.tutorials
WHERE is_published = true;
CREATE MATERIALIZED VIEW app.tutorial_stats AS
SELECT t.tutorial_id, count(l.lesson_id) AS lesson_count
FROM app.tutorials t
LEFT JOIN app.lessons l USING (tutorial_id)
GROUP BY t.tutorial_id;
CREATE UNIQUE INDEX ON app.tutorial_stats (tutorial_id);
REFRESH MATERIALIZED VIEW CONCURRENTLY app.tutorial_stats;You have a live catalog view and a refreshable statistics view.5-minute try-it
Create a view that exposes only public profile columns for active users.
One important caution
A materialized view without an explicit refresh schedule can quietly serve stale reports.
PostgreSQL — Views — PostgreSQL Global Development Group