Snowflake semantic views, compared with a semantic layer in code
How to define and query a Snowflake semantic view, what reads it, how access policies apply, and how the same model looks when it lives in your application code instead of the warehouse.
Definition
What is a Snowflake semantic view?
A semantic view is a Snowflake schema object that stores a semantic model: logical tables, how they join, and named facts, dimensions and metrics with descriptions and synonyms. You query it by naming the dimensions and metrics you want, and Snowflake writes the joins and aggregation.
It is the model behind Cortex Analyst and Cortex Agents, Snowflake’s natural-language and agent features, and BI tools can query it directly. Because it lives in Snowflake, it uses Snowflake’s privileges and policies, and it only covers data in Snowflake.
How it works
CREATE SEMANTIC VIEW, then query it two ways
TABLES is the only required clause. The optional clauses follow in order: RELATIONSHIPS, FACTS (row-level values), DIMENSIONS and METRICS. Synonyms and comments are informational; they help Cortex Analyst and agents pick the right field. Creating one needs CREATE SEMANTIC VIEW on the schema and SELECT on the tables it references.
You can query the view with the SEMANTIC_VIEW() clause, or, since March 2026, with ordinary SQL that wraps each metric in AGG(). Snowflake rewrites the second form into the first. A dimension’s table must be related to the metric’s table at the same or a coarser grain, which is why customer country works with an orders metric.
Facts to know
Where Snowflake semantic views stand in late 2026
Status
Definitions GA since June 2025, the SEMANTIC_VIEW clause since August 2025, standard SQL since March 2, 2026. CREATE OR ALTER, range joins and level-of-detail metrics are in preview.
Ways to author
SQL DDL, YAML through a system function, the Snowsight Semantic View Autopilot (which also ingests Tableau and Power BI files), or dbt with the dbt_semantic_view package.
Agents
Cortex Agents use a semantic view as a tool but generate SQL against the physical tables. The managed MCP server exposes semantic views through Cortex Analyst.
Materializations
Setting MAX_STALENESS (120 seconds minimum) and a warehouse pre-computes results, but only for semantic SQL queries; Cortex queries that run physical SQL do not use them.
The same model in code
The sales view as a code-defined semantic layer
The same tables, join, dimension and metrics as hypequery datasets. Labels and descriptions play the part of synonyms and comments for agents. The difference is the tenant key: instead of a row access policy that depends on which database role runs the query, the backend passes the signed-in customer on every request.
| Snowflake semantic view | hypequery | Notes |
|---|---|---|
Logical table in TABLES | Dataset | One per table; source is the physical table. |
PRIMARY KEY and RELATIONSHIPS | belongsTo, hasOne | To-one joins, one hop deep. |
FACTS | Numeric dimensions | Row-level values that measures aggregate. |
DIMENSIONS | dimension.string(), timestamp() and so on | Time grains come from timeKey and by, not one dimension per grain. |
METRICS | measure.sum(), avg(), derived() | Derived measures combine others with symbolic formulas. |
NON ADDITIVE BY | No direct equivalent | Model semi-additive balances as their own dataset. |
WITH SYNONYMS, COMMENT | label, description | Exposed to agents through MCP schema introspection. |
| Row access policy on base tables | tenantKey | Filled from the authenticated session per request. |
SEMANTIC_VIEW() or AGG() | analytics.execute() | Or the Serve HTTP API and React hooks. |
| Cortex Analyst, managed MCP server | hypequery MCP server | Tools are generated from the datasets. |
Comparison
Snowflake semantic views vs a semantic layer in code
Checked against Snowflake’s docs and release notes on November 10, 2026.
| Snowflake semantic views | Code-defined (hypequery) | |
|---|---|---|
| Where definitions live | A schema-level object in Snowflake, created with SQL DDL, YAML, the Snowsight wizard or a dbt package | TypeScript or Python files in your application repo |
| How consumers query | SEMANTIC_VIEW() clause or standard SQL with AGG(); Cortex Analyst; Cortex Agents; Snowflake’s managed MCP server; BI tools such as Sigma and Hex | Direct calls in your backend, a typed HTTP API, React hooks and an MCP server |
| Databases | Snowflake only | ClickHouse |
| Per-customer data | Row access and masking policies set on base tables propagate to the view. Agents querying through Cortex Analyst also need SELECT on the base tables | A tenant key on the dataset, filled from the authenticated session; a query without it fails |
| Change process | CREATE OR REPLACE, or CREATE OR ALTER (preview); Terraform support is planned | A pull request, reviewed and deployed with the code that uses it |
| Types | Validated by Snowflake when the view is created | Checked by the TypeScript compiler from dataset to response row |
| Portability | Exports its own YAML and Apache Ossie YAML; exports Tableau data sources (preview) | Plain code; no Ossie export today |
| Price | No separate charge is documented: queries use warehouse compute. Cortex Analyst bills per message | Apache 2.0, free; runs on your ClickHouse |
An honest answer
When a Snowflake semantic view is the better choice
- Your data is in Snowflake, and that is where the metrics should be governed.
- You want Cortex Analyst, Cortex Agents or Snowflake’s MCP server to answer questions in plain language.
- Analysts and BI tools are the consumers, and Snowflake roles and policies are already your access model.
- You want nothing new to run: the view is metadata, and queries use the warehouses you already pay for.
A code-defined layer fits when the metrics feed your own product rather than internal BI, and when that product reads from ClickHouse rather than Snowflake. If you use both, the Open Semantic Interchange spec is the likely way definitions will move between them, though there is no ClickHouse converter yet.
Questions
Snowflake semantic views FAQ
What is a Snowflake semantic view?
A semantic view is a schema-level Snowflake object that stores logical tables, the relationships between them, and named facts, dimensions and metrics. Snowflake treats it as metadata. Cortex Analyst, Cortex Agents and BI tools use it to turn business questions into correct SQL.
How do you query a Snowflake semantic view?
Two ways. The SEMANTIC_VIEW clause lists DIMENSIONS and METRICS, as in SELECT * FROM SEMANTIC_VIEW(sales DIMENSIONS customers.country METRICS orders.revenue). Or put the view in FROM and wrap metrics in AGG(), as in SELECT country, AGG(revenue) FROM sales GROUP BY country. The standard SQL form does not allow joins, window functions or QUALIFY.
Are Snowflake semantic views generally available?
Yes. Defining semantic views became generally available in June 2025, querying with the SEMANTIC_VIEW clause in August 2025, and querying with standard SQL on March 2, 2026. A few clauses, such as range joins and level-of-detail metrics, are still in preview.
Do row access policies apply to semantic views?
Policies cannot be set on semantic view attributes, but row access and masking policies on the underlying tables and columns propagate to the semantic view and are enforced. Sample values stored in the view are metadata and are not masked.
Can I define semantic views in YAML or dbt?
Yes. SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML creates one from YAML and SYSTEM$READ_YAML_FROM_SEMANTIC_VIEW exports it. The Snowflake-Labs dbt_semantic_view package adds a semantic_view materialization to dbt.
Do Snowflake semantic views support Open Semantic Interchange?
Yes. SYSTEM$CREATE_SEMANTIC_VIEW_FROM_OSSIE_YAML imports an Apache Ossie (formerly OSI) model, supporting spec version 0.1.1, and SYSTEM$READ_OSSIE_YAML_FROM_SEMANTIC_VIEW exports one. Snowflake-only features are kept in vendor extensions.
Guides
More on semantic layers
What is a semantic layer
What a semantic layer is, the five places one can live, and how dbt MetricFlow, Snowflake semantic views, Databricks metric views and OSI compare with a layer defined in code.
Read
dbt Semantic Layer and MetricFlow
Semantic models, metric types and the Semantic Layer APIs, compared with a semantic layer defined in code.
Read
Databricks metric views
Unity Catalog metric views in YAML, the MEASURE() function and Genie, compared with a semantic layer defined in code.
Read
Open Semantic Interchange (OSI)
The vendor-neutral spec for exchanging semantic models: who is behind it, what the format covers and what it leaves out.
Read
ClickHouse semantic layer
Define datasets, measures and tenant keys for ClickHouse in TypeScript or Python.
Read
hypequery vs Cube
A code-first library compared with a standalone semantic layer service.
Read
Sources
Vendor pages used for this page, all read on November 10, 2026.
- Snowflake docs
- docs.snowflake.com/en/user-guide/views-semantic/overview
- docs.snowflake.com/en/sql-reference/sql/create-semantic-view
- docs.snowflake.com/en/user-guide/views-semantic/querying
- docs.snowflake.com/en/user-guide/views-semantic/sql
- docs.snowflake.com/en/user-guide/views-semantic/best-practices-dev
- docs.snowflake.com/en/user-guide/views-semantic/validation-rules
- docs.snowflake.com/en/sql-reference/stored-procedures/system_create_semantic_view_from_yaml
- docs.snowflake.com/en/sql-reference/stored-procedures/system_create_semantic_view_from_ossie_yaml
- docs.snowflake.com/en/sql-reference/functions/system_read_ossie_yaml_from_semantic_view
- Snowflake release notes and Cortex
- docs.snowflake.com/en/release-notes/2025/june-summit
- docs.snowflake.com/en/release-notes/2025/9_25
- docs.snowflake.com/en/release-notes/2026/other/2026-03-02-semantic-views-standard-sql
- docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst
- docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents-mcp
- docs.snowflake.com/en/developer-guide/cortex-ai-cookbook/multi-tenant-agents
- github.com/Snowflake-Labs/dbt_semantic_view
Next step
Define a semantic layer in your own codebase
hypequery datasets are TypeScript or Python files: dimensions, measures, joins and a tenant key, served to your API, React hooks and AI agents over MCP. Open source, for ClickHouse.