Database View

A view is a named query stored in the database. Reading a view runs its query, so the result reflects data visible under the statement’s transaction snapshot; nothing is copied when the view is created. That makes it the opposite trade-off from a temporary table, which stores rows once and then holds a snapshot that the base tables leave behind.

Views are worth creating when a definition should be shared and stay correct: the agreed filter for “active customers”, a join that everyone gets wrong, a column selection that hides fields a team should not read. Unlike a CTE, the name survives the statement and other people can use it, subject to privileges. An ordinary persistent view survives reconnecting to the same persistent database, and ordinary data changes require no manual refresh of stored rows. A long-lived transaction can still see an older snapshot, and changed schemas or business rules can require a revised definition.

A materialized view is a different object with the same word in its name: it stores the computed rows and must be refreshed, so it behaves like a managed snapshot rather than a live query. Products differ on whether refresh is manual, scheduled, or incremental. Its freshness depends on the refresh policy; some engines maintain it on commit while others refresh asynchronously or on demand. Evaluate storage and maintenance cost as well as read cost.

Two limits are worth stating. A view does not make its query fast; each read pays the cost, and nesting views over views can produce a plan nobody has inspected. And a view is not a security boundary by itself: it can restrict which columns or rows a query returns, but that only helps if the underlying tables are not also readable and the privileges are actually set that way.

References: PostgreSQL CREATE VIEW, PostgreSQL materialized views. See it in use in CTEs and Temporary Tables.