Inside the AtScale and Snowflake Partnership: Why Snowflake Embedded AtScale in Semantic Views
By Mark Palmer
The Snowflake Semantic Views XMLA Endpoint, powered by AtScale, is an integrated product offering. It’s the only semantic solution to have this distinction. It’s not something bolted on the side of Snowflake; it’s the bet Snowflake made on AtScale.
The solution provides governed semantics, metrics, dimensions, and business logic live inside Snowflake itself and a compute engine (ACE) that ensures every AI agent, CoWork, AI coding agent, Power BI, and Excel get the same answer through via the AtScale-based XMLA endpoint (now in Private Preview). Snowflake’s investment in AtScale signals its commitment to semantic consistency and simplifying access to governed metrics for AI analytics workflows.
What the partnership is
Most “integrations” mean a vendor sits side-by-side with a tool. AtScale’s relationship with Snowflake works differently. We’re embedding the AtScale ACE engine directly inside Semantic Views in the Snowflake XMLA endpoint. Metric definitions, hierarchies, and calculations are stored and governed inside Snowflake itself, not shadowed in a separate metadata layer, ontology, or knowledge graph that can drift out of sync. Build an agent in CoCo on Monday, query it from Excel or Power BI on a Friday, and you get the same number both times, because both tools are using the same semantic model.
AtScale Enterprise vs. the native XMLA endpoint
The XMLA endpoint for Semantic Views provides Snowflake customers using Power BI and Excel with a direct, native path to Snowflake Semantic Views. No separate connector, no separate copy of the model.
AtScale Enterprise is the universal semantic layer built on that foundation. It extends governed access to BI tools that don’t speak XMLA, like Tableau, embraces any AI coding environment (Cursor, Codex, Claude), adds support for multi-warehouse and hybrid deployments (Databricks alongside Snowflake, for example), and layers in advanced modeling, governance, and scale features enterprise teams need as their semantic layer grows past a single warehouse or a single BI tool.
Why native beats bolt-on
Many tools claim Snowflake support; only AtScale is a point-and-click, embedded solution. Data catalogs like Denodo live outside Snowflake and document your metrics after the fact. Semantic layers embedded in Tableau or Power BI provide business logic for every report, but don’t interact with AI agents.
Only AtScale’s semantic model lives inside Snowflake, making governance the default. One definition of a metric, enforced everywhere it’s used.
One model, every BI tool
The XMLA endpoint for Semantic Views enables analysts to use BI tools they already know, and the semantic layer ensures metric consistency across new AI applications built in CoCo or Cowork. Snowflake Semantic Views for Power BI and Excel walks through what that looks like in practice. Read Stop Metric Sprawl to explore the business problems it solves.
AtScale, Databricks, and Snowflake: when each fits
Snowflake and Databricks are platforms where data lives and gets processed. AtScale is the semantic layer inside and on top of these platforms. If your organization runs Snowflake alone, Databricks alongside it, or both in a hybrid setup, your metric definitions remain consistent regardless of which platform runs the query. Teams running a single warehouse are consistently governed across AI and BI tools. Teams running more than one warehouse get that same consistency across platforms, too.
AtScale vs. point-player semantic layer tools
Tools like Cube, Kyvos, and Honeydew also describe themselves as semantic layers. How do they differ? Snowflake didn’t choose them. None of these solutions lives in Snowflake, and none of them has an upgrade path to becoming a universal semantic layer. Only AtScale lives in Snowflake. There’s simply no other choice. If you use Snowflake and are building a semantic layer, ask yourself one question: Who did Snowflake choose?
Query performance and cost, without extra infrastructure
The final key selection criteria is: “How does a semantic layer help optimize the cost of using AI?” This is yet another reason Snowflake chose AtScale’s AI Computation Engine (ACE) to embed inside the Semantic Views XMLA endpoint and in Snowpark. ACE doesn’t just capture the meaning of metrics; it computes answers for AI, Power BI, and Excel prompts.
ACE computes metrics and pushes SQL queries down into Snowflake. No need for a second copy of your data and a second compute layer to process it. Our look at Cortex Analyst accuracy digs into how a governed semantic model improves the precision and efficiency of AI-driven queries against Snowflake, a trend increasingly relevant as more teams point Cortex and other AI tools directly at their warehouse.
Recognized by analysts and customers, not just by Snowflake
AtScale has been named a Leader and Fast Mover in GigaOm’s 2025 Radar for semantic layers, following similar recognition in GigaOm’s 2024 Sonar report. Independent confirmation that a native semantic layer changes how much our customers trust their numbers. Companies like Blue Yonder, Carrefour, and Papa Johns have bet their business on the AtScale semantic layer. So industry leaders all agree: AtScale is the smart bet. You should make it too.
Want to see how Semantic Views works with your existing BI stack? Explore AtScale for Snowflake.
Frequently Asked Questions
Scaling analytics in the AI age means keeping metric definitions consistent as more teams adopt AI. It also means using consistent metrics to keep legacy BI tools in sync and accurate. A native semantic layer handles that by enforcing one governed model across every tool, instead of letting each new AI agent reinvent its own logic and provide a different number from what’s inside Excel. The Snowflake and AtScale solution ensures accurate metrics are supplied across every analytical view of the business context
This decision usually comes down to your existing data engineering stack and workload mix. A semantic layer becomes relevant once you need consistent metric definitions across whichever platform, or platforms, you land on, which is common for organizations running Snowflake and Databricks side by side. AtScale runs in both Snowflake and Databricks (and in any Iceberg-compliant compute layer).
Start with one question: Who did Snowflake choose? Who did they invest in? Who did they trust and embed in their own offering? Then ask yourself why: Is the semantic layer native to Snowflake or bolted on? Does it work across every AI and BI tool your team uses? Finally, ask: Is there benchmarking evidence that shows it’s accurate and reduces AI compute costs? A semantic layer that fails any of these recreates the problems it’s supposed to solve.
You need an architecture that avoids the AI guessing tax. By combining an understanding of the meaning of data with an AI Computation Engine (ACE) to compute it, you ensure the LLM doesn’t “guess” at what “comparable-store revenue by region” means. An AI computation engine built natively in Semantic Views does this by design, so you’re not paying for a second copy of the data or a second compute layer to process it.
The semantic layer governs business context by treating it as a governed CI/CD asset as it evolves, using a semantic modeling language (SML). AtScale governs metrics directly in Snowflake via Semantic Views, so the same definitions apply regardless of which AI or BI tool or team is requesting them.