Skip to main content
Applies to: Embedded ❌, Enterprise ✅ A view is the lightest way to derive a feature-engineered dataset: it stores a query, not rows, so there is nothing to refresh and nothing that can fall out of date. Reach for one before a computed column or a materialized view when the underlying query is cheap enough to simply re-run on every read.

​
Define a view

A view over a products table, selecting and deriving a few columns:
The statement resolves the view’s schema from the query at creation time. Anything the SQL dialect supports can define one: joins, predicates, aggregates, window functions — the same expressiveness as a computed column’s SQL expression, just over a whole derived table instead of one column.

​
Read it like a table

Every read runs the saved query against current data, so sale_price reflects whatever price is right now — there is no staleness window to reason about, unlike a materialized view between refreshes. A predicate applied when reading the view composes with the query inside it, rather than filtering the view’s output afterward, so a selective filter does not pay for rows the view would have produced and then discarded.

​
When to use a view instead

Reach for a view when the query is cheap, or when reading a stale value would be wrong for the workload. Reach for a computed column or a materialized view when the query is expensive and the data changes less often than it is read. See View for the full SQL reference comparison, including the separate privileges each one needs.

​
What to read next

View

CREATE VIEW, DROP VIEW, and listing views alongside tables.

Create a materialized view

The stored-rows counterpart, and when a refresh is worth paying for.