Disclosure: This article is published by Upsolve AI. Where our product is mentioned alongside competitors, we aim to provide balanced coverage based on publicly available information. We encourage readers to evaluate all options independently.

Snowflake semantic views are schema-level database objects that store business meaning (logical tables, relationships, facts, dimensions, and metrics) right next to your data. They’re Snowflake’s native semantic layer. Cortex Agents use them to answer natural-language questions, and BI tools and SQL users query them directly for consistent metrics.

A lot changed in 2026. Standard SQL querying went GA in March. Snowflake now recommends Cortex Agents over standalone Cortex Analyst. Snowflake Intelligence was renamed Snowflake CoWork, and materializations and Horizon Context arrived in preview. This guide covers the syntax, how querying works, how Snowflake’s AI uses semantic views (including one detail most guides miss), the limitations, and how semantic views compare with Databricks metric views.

What Is a Snowflake Semantic View?

A semantic view is “a schema-level object that stores business concepts in the database.” It maps cryptic physical columns, like amt_ttl_pre_dsc, to business concepts like gross revenue, and it defines how tables join and how metrics aggregate. Snowflake treats semantic views as metadata, so they don’t copy or move any data.

Semantic View vs Semantic Model

Before semantic views, Cortex Analyst read a semantic model: a YAML file uploaded to a stage. (The term means something else in Power BI; see what a semantic model is.) That still works, but it’s now the legacy path:

You can convert existing YAML with SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML and export a view back to YAML with SYSTEM$READ_YAML_FROM_SEMANTIC_VIEW. YAML and DDL are now two authoring formats for the same object, with near-complete feature parity.

Is Snowflake a Semantic Layer?

Snowflake is a data platform that includes a semantic layer. Semantic views are that semantic layer for data stored in Snowflake. Horizon Context, announced at Summit 2026, is Snowflake’s broader “governed context layer,” and semantic views are its semantic component.

The Five Building Blocks of a Semantic View

Facts and metrics can be marked PRIVATE so they feed calculations without being exposed. Dimensions can’t be private.

How to Create a Snowflake Semantic View

With SQL: CREATE SEMANTIC VIEW

Here’s a trimmed version of Snowflake’s reference example, which runs on the sample data every account has:

CREATE SEMANTIC VIEW tpch_rev_analysis
  TABLES (
    orders AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.ORDERS
      PRIMARY KEY (o_orderkey)
      COMMENT = 'All orders table for the sales domain',
    customers AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.CUSTOMER
      PRIMARY KEY (c_custkey)
      COMMENT = 'Main table for customer data',
    line_items AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.LINEITEM
      PRIMARY KEY (l_orderkey, l_linenumber)
  )
  RELATIONSHIPS (
    orders_to_customers AS orders (o_custkey) REFERENCES customers,
    line_item_to_orders AS line_items (l_orderkey) REFERENCES orders
  )
  FACTS (
    line_items.discounted_price AS l_extendedprice * (1 - l_discount)
      COMMENT = 'Extended price after discount'
  )
  DIMENSIONS (
    customers.customer_name AS customers.c_name
      COMMENT = 'Name of the customer',
    orders.order_year AS YEAR(o_orderdate)
      COMMENT = 'Year when the order was placed'
  )
  METRICS (
    customers.customer_count AS COUNT(c_custkey),
    orders.order_average_value AS AVG(orders.o_totalprice)
      COMMENT = 'Average order value across all orders'
  )
  COMMENT = 'Semantic view for revenue analysis'

CREATE SEMANTIC VIEW tpch_rev_analysis
  TABLES (
    orders AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.ORDERS
      PRIMARY KEY (o_orderkey)
      COMMENT = 'All orders table for the sales domain',
    customers AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.CUSTOMER
      PRIMARY KEY (c_custkey)
      COMMENT = 'Main table for customer data',
    line_items AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.LINEITEM
      PRIMARY KEY (l_orderkey, l_linenumber)
  )
  RELATIONSHIPS (
    orders_to_customers AS orders (o_custkey) REFERENCES customers,
    line_item_to_orders AS line_items (l_orderkey) REFERENCES orders
  )
  FACTS (
    line_items.discounted_price AS l_extendedprice * (1 - l_discount)
      COMMENT = 'Extended price after discount'
  )
  DIMENSIONS (
    customers.customer_name AS customers.c_name
      COMMENT = 'Name of the customer',
    orders.order_year AS YEAR(o_orderdate)
      COMMENT = 'Year when the order was placed'
  )
  METRICS (
    customers.customer_count AS COUNT(c_custkey),
    orders.order_average_value AS AVG(orders.o_totalprice)
      COMMENT = 'Average order value across all orders'
  )
  COMMENT = 'Semantic view for revenue analysis'

CREATE SEMANTIC VIEW tpch_rev_analysis
  TABLES (
    orders AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.ORDERS
      PRIMARY KEY (o_orderkey)
      COMMENT = 'All orders table for the sales domain',
    customers AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.CUSTOMER
      PRIMARY KEY (c_custkey)
      COMMENT = 'Main table for customer data',
    line_items AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.LINEITEM
      PRIMARY KEY (l_orderkey, l_linenumber)
  )
  RELATIONSHIPS (
    orders_to_customers AS orders (o_custkey) REFERENCES customers,
    line_item_to_orders AS line_items (l_orderkey) REFERENCES orders
  )
  FACTS (
    line_items.discounted_price AS l_extendedprice * (1 - l_discount)
      COMMENT = 'Extended price after discount'
  )
  DIMENSIONS (
    customers.customer_name AS customers.c_name
      COMMENT = 'Name of the customer',
    orders.order_year AS YEAR(o_orderdate)
      COMMENT = 'Year when the order was placed'
  )
  METRICS (
    customers.customer_count AS COUNT(c_custkey),
    orders.order_average_value AS AVG(orders.o_totalprice)
      COMMENT = 'Average order value across all orders'
  )
  COMMENT = 'Semantic view for revenue analysis'

CREATE SEMANTIC VIEW tpch_rev_analysis
  TABLES (
    orders AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.ORDERS
      PRIMARY KEY (o_orderkey)
      COMMENT = 'All orders table for the sales domain',
    customers AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.CUSTOMER
      PRIMARY KEY (c_custkey)
      COMMENT = 'Main table for customer data',
    line_items AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.LINEITEM
      PRIMARY KEY (l_orderkey, l_linenumber)
  )
  RELATIONSHIPS (
    orders_to_customers AS orders (o_custkey) REFERENCES customers,
    line_item_to_orders AS line_items (l_orderkey) REFERENCES orders
  )
  FACTS (
    line_items.discounted_price AS l_extendedprice * (1 - l_discount)
      COMMENT = 'Extended price after discount'
  )
  DIMENSIONS (
    customers.customer_name AS customers.c_name
      COMMENT = 'Name of the customer',
    orders.order_year AS YEAR(o_orderdate)
      COMMENT = 'Year when the order was placed'
  )
  METRICS (
    customers.customer_count AS COUNT(c_custkey),
    orders.order_average_value AS AVG(orders.o_totalprice)
      COMMENT = 'Average order value across all orders'
  )
  COMMENT = 'Semantic view for revenue analysis'

Clause order matters: TABLES, then RELATIONSHIPS, FACTS, DIMENSIONS, and METRICS. You need at least one dimension or metric.

With Semantic View Autopilot and Semantic Studio

If you’d rather not hand-write DDL, Semantic View Autopilot (GA February 2026) drafts a semantic view from your tables and query history. It can also ingest Tableau workbooks and, since August 2026, Power BI files. Semantic Studio, the visual editor, went GA on September 30, 2026. Treat the output as a first draft. Generators can’t infer business rules from column names.

As Code: dbt, Terraform, and DCM

For CI/CD, Snowflake Labs’ dbt_semantic_view package adds a dbt materialization. You write semantic view DDL inside a dbt model with {{ config(materialized='semantic_view') }} and use ref() and source(). It doesn’t translate MetricFlow metrics; it passes DDL through to Snowflake. Terraform and Snowflake’s DCM Projects (DEFINE SEMANTIC VIEW, GA September 2026) are the other as-code options.

Adding Context for AI: Sample Values, Instructions, Verified Queries

Three optional additions shape how Cortex answers questions:

DIMENSIONS (
  t1.region AS region
    COMMENT = 'Sales region'
    SAMPLE_VALUES ('East', 'West', 'North', 'South')
    IS_ENUM
)
...
AI_SQL_GENERATION 'Ensure that all numeric columns are rounded to 2 decimal points.'
AI_QUESTION_CATEGORIZATION 'Reject all questions asking about users. Ask users to contact their admin.'

DIMENSIONS (
  t1.region AS region
    COMMENT = 'Sales region'
    SAMPLE_VALUES ('East', 'West', 'North', 'South')
    IS_ENUM
)
...
AI_SQL_GENERATION 'Ensure that all numeric columns are rounded to 2 decimal points.'
AI_QUESTION_CATEGORIZATION 'Reject all questions asking about users. Ask users to contact their admin.'

DIMENSIONS (
  t1.region AS region
    COMMENT = 'Sales region'
    SAMPLE_VALUES ('East', 'West', 'North', 'South')
    IS_ENUM
)
...
AI_SQL_GENERATION 'Ensure that all numeric columns are rounded to 2 decimal points.'
AI_QUESTION_CATEGORIZATION 'Reject all questions asking about users. Ask users to contact their admin.'

DIMENSIONS (
  t1.region AS region
    COMMENT = 'Sales region'
    SAMPLE_VALUES ('East', 'West', 'North', 'South')
    IS_ENUM
)
...
AI_SQL_GENERATION 'Ensure that all numeric columns are rounded to 2 decimal points.'
AI_QUESTION_CATEGORIZATION 'Reject all questions asking about users. Ask users to contact their admin.'

IS_ENUM tells Cortex the sample values are the complete list. AI_VERIFIED_QUERIES stores approved question-and-SQL pairs that Cortex reuses for similar questions. Snowflake’s modeling guidance has a counterintuitive tip: descriptions are “the single most important element for accuracy,” while synonyms “generally add little accuracy” with frontier models. Use synonyms only for genuinely unique or industry-specific terms. If your column descriptions are thin, start with a data dictionary.

Watch out: sample values are metadata and aren’t covered by masking policies. Don’t put personal or regulated data in them.

How to Query a Snowflake Semantic View

The SEMANTIC_VIEW() Clause

SELECT * FROM SEMANTIC_VIEW(
    tpch_rev_analysis
    DIMENSIONS customers.customer_name
    METRICS orders.order_average_value
  )
  ORDER BY

SELECT * FROM SEMANTIC_VIEW(
    tpch_rev_analysis
    DIMENSIONS customers.customer_name
    METRICS orders.order_average_value
  )
  ORDER BY

SELECT * FROM SEMANTIC_VIEW(
    tpch_rev_analysis
    DIMENSIONS customers.customer_name
    METRICS orders.order_average_value
  )
  ORDER BY

SELECT * FROM SEMANTIC_VIEW(
    tpch_rev_analysis
    DIMENSIONS customers.customer_name
    METRICS orders.order_average_value
  )
  ORDER BY

Standard SQL with AGG()

Since March 2, 2026, you can query a semantic view like a table, wrapping metrics in AGG():

SELECT order_year, AGG(order_average_value)
  FROM tpch_rev_analysis
  GROUP BY

SELECT order_year, AGG(order_average_value)
  FROM tpch_rev_analysis
  GROUP BY

SELECT order_year, AGG(order_average_value)
  FROM tpch_rev_analysis
  GROUP BY

SELECT order_year, AGG(order_average_value)
  FROM tpch_rev_analysis
  GROUP BY

What You Can’t Do

The standard SQL form doesn’t support joins, window function calls, QUALIFY, PIVOT, or correlated subqueries. In the clause form, you can’t mix FACTS and METRICS, and a dimension must be related to the metric’s table at the same or lower granularity. To see which dimensions are valid for a metric, run SHOW SEMANTIC DIMENSIONS IN <view> FOR METRIC <metric>.

How Cortex Agents and CoWork Use Semantic Views

This is the part most guides skip, and it changes how you design for AI.

Cortex Analyst is Snowflake’s natural-language-to-SQL service. Since August 2026, Snowflake recommends using it through Cortex Agents, which add multi-step orchestration, Cortex Search over unstructured data, and conversation threads. Snowflake CoWork (formerly Snowflake Intelligence) is the end-user agent built on top. Your semantic views carry over unchanged.

Here’s the key detail. Per Snowflake’s docs, Cortex Agents read the semantic view definition and “generate the SQL against the physical tables directly.” The semantic view is context for the model, not an execution layer. Three practical consequences follow:

1. Agents need base-table access. Humans querying via SQL need SELECT on the semantic view only. Cortex Agents need SELECT on the semantic view and its underlying tables.

2. Materializations don’t help AI. Pre-aggregations accelerate semantic SQL queries only, not the physical SQL Cortex generates.

3. Accuracy still needs testing. The model writes the SQL, so a semantic view improves the odds of a correct answer but doesn’t guarantee it. Verified queries and evaluation matter.

Two scaling limits also matter. Agents pick one semantic view per question and don’t join across separate semantic views. And while there’s no hard size limit, views over roughly 100,000 tokens get pruned, which adds latency and lowers quality. Snowflake recommends starting with 5–10 tables.

On cost, Cortex Analyst bills credits per successful message, plus warehouse compute to run the generated SQL. In multi-turn conversations, the full history is reprocessed each turn, so cost rises with every round.

Advanced Features

• Semi-additive metrics: NON ADDITIVE BY (year_dim, month_dim, day_dim) handles balances that shouldn’t be summed across time.

• Window function metrics: Rolling averages using PARTITION BY EXCLUDING.

• Materializations (preview): Pre-aggregated results with a MAX_STALENESS setting. Snowflake’s TPC-DS benchmark showed 59–91× faster queries, with data scanned dropping from 359 GB to 120 MB. Window and semi-additive metrics can’t be materialized.

• Range and ASOF joins: For time-bounded relationships; range joins are in preview.

Privileges and Governance

Masking and row access policies can’t be set on semantic view attributes directly, but policies on base tables propagate to the view.

Limitations of Snowflake Semantic Views

1. Snowflake data only. Horizon Context (preview) imports metadata and lineage from 18 external systems, but semantic views don’t query data outside Snowflake.

2. No joins across semantic views in agent workflows, so each domain needs its own complete view.

3. Editing replaces the definition. ALTER only changes comments, names, and materializations; anything else needs CREATE OR REPLACE or the preview CREATE OR ALTER.

4. Modeling constraints. No self-referencing or circular relationships, and many-to-many needs a bridge table.

5. Query restrictions. No joins or window calls in the standard SQL form.

6. Metadata isn’t masked. Sample values appear in plain text in GET_DDL.

Practitioners feel #2 most. One r/dataengineering thread asks for “tool agnostic single source of truth metrics” without redefining Headcount in finance, HR, and every other semantic view.

Snowflake Semantic Views vs Databricks Metric Views vs dbt

The dbt Semantic Layer is warehouse-agnostic. Snowflake semantic views are native and governed but Snowflake-only. Databricks metric views make the same trade-off for Unity Catalog. Snowflake frames the two as complementary: dbt handles transformation, and semantic views handle meaning. For more options, see our comparison of semantic layer tools.

Best Practices

• Scope by domain. Several focused views beat one giant one, but remember agents can’t join across them.

• Write descriptions before synonyms. Descriptions drive accuracy most.

• Define every relationship. Agents won’t join tables without one.

• Add verified queries last. Snowflake advises against using them “to compensate for an incomplete model.”

• Manage views as code with dbt, Terraform, or DCM, and review changes like any other code.

When a Warehouse-Native Semantic Layer Isn’t Enough

If all your data lives in Snowflake and your users are happy in CoWork, semantic views are a strong foundation. The limits show up when they aren’t: product data in Postgres, finance in BigQuery, an agent that needs to answer in Slack or inside your app, and metric definitions that must stay identical everywhere. Snowflake’s own Horizon Context launch is an acknowledgment that business context lives in many systems, which is the idea behind a context layer. Universal options like the Cube semantic layer exist for exactly these multi-platform cases.

Don’t Have a Semantic Layer Yet? Start Here

Upsolve Data Models gives analytics agents governed context without requiring a semantic layer first. It works on Snowflake and 30+ other SQL sources:

• Register tables with descriptions, types, and keys.

• Encode canonical definitions in a versioned system prompt.

• Mark columns as selectable so allowed values are pre-cached nightly. It’s the cross-source equivalent of SAMPLE_VALUES with IS_ENUM.

Already have dbt models? Bring them in. Then deploy the same agent to Slack, Teams, Claude, ChatGPT, or your product.

Frequently Asked Questions

What is the difference between a semantic model and a semantic view in Snowflake?

A semantic model is a YAML file on a stage, originally the only way to configure Cortex Analyst. A semantic view stores the same definitions as a native schema-level object with RBAC, sharing, and SQL querying. Snowflake recommends semantic views for all new work and provides functions to convert between the two.

How do you query a semantic view in Snowflake?

Use the SEMANTIC_VIEW() clause with DIMENSIONS and METRICS lists, or, since March 2026, standard SQL where metrics are wrapped in AGG() and you GROUP BY dimensions. Joins and window function calls aren’t supported in the standard SQL form.

What are the limitations of Snowflake semantic views?

They only cover data in Snowflake. Agents can’t join across separate views. Most edits require replacing the view. Many-to-many relationships need a bridge table. Sample values aren’t masked. Materializations are in preview and don’t accelerate AI-generated queries.

Do Snowflake semantic views cost extra?

Snowflake documents no separate charge for semantic view objects, which are metadata. You pay for warehouse compute when queries run, Cortex credits per message when using Cortex Analyst or Agents, and refresh compute plus storage for materializations.

Does Cortex Analyst require a semantic view?

Cortex Analyst requires either a semantic view or a legacy YAML semantic model. Semantic views are the recommended option, and Cortex Agents, which Snowflake now recommends over standalone Cortex Analyst, use them unchanged.

What are the key differences between the dbt Semantic Layer and Snowflake semantic views?

The dbt Semantic Layer defines metrics in a dbt project and compiles SQL for several warehouses. Snowflake semantic views are native Snowflake objects, consumed by Cortex and partner BI tools. dbt offers portability across platforms; semantic views offer native governance and Cortex integration.

Sources

1. Snowflake Docs: Overview of semantic views. https://docs.snowflake.com/en/user-guide/views-semantic/overview

2. Snowflake Docs: Semantic models vs. semantic views. https://docs.snowflake.com/en/user-guide/views-semantic/semantic-models-vs-views

3. Snowflake Docs: YAML vs DDL. https://docs.snowflake.com/en/user-guide/views-semantic/yaml-vs-ddl

4. Snowflake Docs: CREATE SEMANTIC VIEW. https://docs.snowflake.com/en/sql-reference/sql/create-semantic-view

5. Snowflake Docs: Standard SQL for semantic views, release note (Mar 2, 2026). https://docs.snowflake.com/release-notes/2026/other/2026-03-02-semantic-views-standard-sql

6. Snowflake Docs: Transition from Cortex Analyst to Cortex Agents, release note (Aug 28, 2026). https://docs.snowflake.com/release-notes/2026/other/2026-08-28-cortex-analyst-transition-cortex-agents

7. Snowflake Docs: Semantic view development best practices. https://docs.snowflake.com/en/user-guide/views-semantic/best-practices-dev

8. Snowflake Docs: Semantic view modeling best practices. https://docs.snowflake.com/en/user-guide/views-semantic/best-practices-modeling

9. Snowflake Docs: Cortex Analyst. https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst

10. Snowflake: Semantic View Autopilot (Feb 2026). https://www.snowflake.com/en/blog/semantic-view-autopilot/

11. Snowflake Engineering: dbt_semantic_view package. https://www.snowflake.com/en/engineering-blog/dbt-semantic-view-package/

12. Snowflake Engineering: Accelerating Semantic Views with Materializations (Aug 2026). https://www.snowflake.com/en/blog/engineering/accelerating-semantic-views-materializations/

13. Snowflake: Horizon Context. https://www.snowflake.com/en/product/features/horizon-context/

14. Reddit r/dataengineering: Composable semantic views in Snowflake. https://www.reddit.com/r/dataengineering/comments/1t2ie2u/what_is_a_strong_composable_architecture_for_a/

15. Upsolve AI: Data Models. https://upsolve.ai/features/data-models