Snowflake Semantic Views, Cube, and AtScale represent three different bets on where your semantic layer should live: inside the warehouse, or independent of it. Snowflake’s option, generally available for standard SQL querying since March 2, 2026,[1] costs nothing extra to run, but it stops at the warehouse’s edge. Cube and AtScale both run across every warehouse you have, at the cost of a separate system to operate and govern.
None of these three tools makes the choice for you. A team running a single Snowflake instance today can get a governed metric layer for the price of a DDL statement. A team already spanning Snowflake, Databricks, and Postgres needs one metric definition that means the same thing everywhere, and neither Cube nor AtScale forces a warehouse choice to get it. The multi-warehouse question, not a feature checklist, is the fork that actually decides this.
| Dimension | Snowflake Semantic Views | Cube | AtScale |
|---|---|---|---|
| What it is | Native semantic layer object inside Snowflake | Open-source, API-first headless semantic layer | Universal semantic layer via query virtualization |
| Deployment model | Zero extra infrastructure, a DDL object in your warehouse | Self-hosted or Cube Cloud, separate from the warehouse | Deployed alongside your warehouse(s), no data movement |
| Data scope | Snowflake only | Multi-warehouse, multi-source | Multi-warehouse, multi-source |
| Governance model | Inherits Snowflake’s native RBAC | Access control you configure yourself | Access control you configure yourself |
| Lock-in profile | Tied to staying single-warehouse on Snowflake | Portable across warehouses, you own the metric layer | Portable across warehouses, you own the metric layer |
| Cost model | Included in Snowflake compute, no separate license | Separate license or Cube Cloud subscription | Separate license, enterprise-negotiated |
| Best for | Teams committed to Snowflake as the only warehouse | One metric layer across many sources, API-first | BI-tool reach (Excel, Power BI) across many sources |
Snowflake Semantic Views vs Cube vs AtScale: which architecture fits you?
Permalink to “Snowflake Semantic Views vs Cube vs AtScale: which architecture fits you?”This section answers which pattern fits your team before any feature gets compared. The fork is how many warehouses you run today and plan to run in two years, not which vendor ships more capabilities.
Most comparison content skips straight to a feature matrix. That’s backwards for this decision. A feature matrix tells you which tool wins a category; it doesn’t tell you whether you need to compete in that category at all. The question that actually decides this splits into three situations.
If more than 70% of your analytical workload already runs in Snowflake, and no second warehouse sits on a 24-month roadmap, Snowflake Semantic Views is usually enough. You’d be paying for portability that nothing in your stack currently uses. The alternative, a headless semantic layer that runs independent of any single warehouse, only earns its keep once a second platform is actually in the picture.
If you’re on Snowflake today but suspect a second platform, a Databricks lakehouse (see what Unity Catalog’s own metrics layer changes for that specific pairing), a second cloud, within 24 months, you’re hedging rather than committed. A real hybrid path becomes relevant here before you commit either way, and it’s worth understanding before you rule it out (more on that below).
If you’re already running Snowflake for structured data, a Databricks lakehouse for machine learning, and Postgres for application data, a combination multiple vendors describe as increasingly common even without an analyst firm publishing a percentage for how widespread it is, a single metric layer spanning all of it is the one thing a warehouse-native tool structurally cannot provide. Cube or AtScale becomes the only way one “customer” definition covers every platform you run, the same problem semantic layer for AI agents explores in more depth than a three-way architecture comparison needs to.
Whichever bucket you land in, the metric layer you pick still only answers what a term like “revenue” means. It doesn’t answer who’s allowed to see that answer, whether it’s current, or who signed off on the definition, a distinction that matters more once you’ve made the architecture call than before it, and the same boundary ontology vs semantic layer draws in more general terms.
What is Snowflake Semantic Views?
Permalink to “What is Snowflake Semantic Views?”Snowflake Semantic Views is a native object inside the Snowflake warehouse that defines business metrics and relationships for Cortex Analyst and any SQL client, without moving or duplicating data.
Standard SQL querying against Snowflake Semantic Views reached general availability on March 2, 2026, according to Snowflake’s own documentation.[1] It deploys as a single DDL statement inside the warehouse. There’s no separate infrastructure to provision and no additional licensing cost beyond the Snowflake compute already in use.
That simplicity comes with real limits. Snowflake caps a single semantic model definition at 1 MB of YAML, and practitioners running it in production report that Cortex Analyst’s accuracy degrades once a model grows past roughly 50 to 100 columns.[2] There’s also no cross-account replication, so a semantic model built in one Snowflake account doesn’t travel to another without rebuilding it. Carl Perry, Snowflake’s Head of Analytics, frames the underlying shift plainly: “The fundamental shift is that semantics can no longer live inside BI tools sitting above the data. They must reside where the data lives, so agents and analysts receive identical answers regardless of how they query it.”[3] That’s the platform-native camp’s strongest argument, one the context layer for Snowflake picks up from the implementation side rather than the architecture-choice side this page takes.
Core components of Snowflake Semantic Views
Permalink to “Core components of Snowflake Semantic Views”- Semantic model YAML: defines tables, relationships, metrics, and synonyms in a single file that Cortex Analyst reads directly
- Native RBAC inheritance: access control is whatever Snowflake’s own roles already enforce, no second policy system to maintain
- Cortex Analyst integration: the primary consumption path, resolving natural-language queries against the semantic model
- Zero data movement: the layer sits directly on warehouse tables, so nothing gets copied out or falls out of sync
What is Cube?
Permalink to “What is Cube?”Cube is an open-source, API-first semantic layer that sits between your data warehouses and every BI or AI tool that queries them, independent of any single platform.
Cube Core is dual-licensed, Apache 2.0 for the backend and MIT for the client libraries, and carries more than 17,000 stars on GitHub.[4] Cube reported roughly 20% of the Fortune 1000 using it alongside its $25 million Series B, led by Databricks Ventures in June 2024, bringing total funding to roughly $48 million.[5] Cube was named a Representative Vendor in Gartner’s February 2026 Market Guide for Agentic Analytics, its first appearance in a Gartner report; AtScale has no equivalent Gartner placement, citing only a 2025 niche-analyst semantic layer radar instead.[6]
Artyom Keydunov, Cube’s co-founder and CEO, describes the founding problem this way: “Pavel Tiunov and I started Cube to solve a real problem: data models are spread across too many BI tools and cloud data warehouse silos, and data engineers need an open and universal semantic layer, a single source of truth.”[7] That’s Cube’s own case for staying independent of any one warehouse, and it’s the same case AtScale makes below from a different angle.
For the deeper look at Cube’s own architecture and where its governance gaps sit, see Cube’s semantic layer: architecture, adoption, and gaps. For how a catalog actually connects to Cube’s metric layer mechanically, rather than why it should, see Cube data catalog integration.
Core components of Cube
Permalink to “Core components of Cube”- API-first semantic model: metrics defined once, queried via SQL, GraphQL, or REST from any downstream tool
- Pre-aggregations and caching: a performance layer sitting between the warehouse and live query traffic
- Multi-warehouse connectors: one metric definition can span Snowflake, Databricks, Postgres, and others simultaneously
- Its own MCP server: exposes Cube’s metric definitions directly to agents, but only Cube’s own slice, not what’s certified elsewhere or where the underlying data came from
The 7 Shifts Reshaping the Data Stack for an AI-First World
A 2026 report on the architectural shifts, semantic layers among them, forcing enterprise data teams to rethink what sits where.
Download the 2026 ReportWhat is AtScale?
Permalink to “What is AtScale?”AtScale is a universal semantic layer that virtualizes OLAP-style metrics across multiple warehouses without moving data, built to extend governed metrics into existing BI tools like Excel and Power BI.
Its query virtualization engine computes metrics on demand against live warehouse data, supporting SQL, MDX, DAX, Python, and REST access to the same underlying definitions. Founded in 2013 and based in San Mateo, California and Boston, Massachusetts, AtScale counts Home Depot and Fidelity among its customers.[8] In December 2025, AtScale closed what it describes as the largest equity financing in its history, led by Snowflake Ventures; the company hasn’t disclosed the exact size of the round, though SiliconANGLE’s analysis puts it in the $75 million to $100 million range, implying a valuation between $500 million and $750 million.[9]
David P. Mariani, AtScale’s co-founder, argues the case for building the semantic layer independent of both the tools consuming it and the platform storing the data: “The semantic layer, truly to be the single source of truth, it needed to live independent” of both layers.[10] The clearest sign of where that independence is heading: on June 2, 2026, at Snowflake Summit, AtScale announced an XMLA Endpoint that extends Snowflake Semantic Views’ own governed metrics into Excel and Power BI, deploying as a Snowflake Native App with a single DDL command, currently in private preview.[11] That’s the hybrid path the decision framework below builds on. AtScale’s OLAP heritage puts it in the same universal-semantic-layer category surveyed in 9 best semantic layer tools for BI and AI agents in 2026.
Core components of AtScale
Permalink to “Core components of AtScale”- Query virtualization engine (ACE): computes metrics on demand against live warehouse data, with no ETL step
- Multi-protocol access: SQL, MDX, DAX, Python, and REST from the same metric definitions
- BI-tool reach: built to extend governed metrics into Excel, Power BI, and Tableau, not just modern query clients
- MCP server on the Databricks MCP Marketplace: exposes AtScale’s metric layer to agents, specifically on Databricks
David Mariani, quoted above, makes the same case for AtScale’s independence directly on Atlan’s own “WTF is the Context Layer?” series, where he and Atlan’s team work through whether a semantic layer and a context layer are the same idea in different clothes or genuinely different jobs.
Snowflake Semantic Views vs Cube vs AtScale: head-to-head comparison
Permalink to “Snowflake Semantic Views vs Cube vs AtScale: head-to-head comparison”Once you know your warehouse-count bucket, this table validates the choice across nine dimensions that actually differ between the three, not just which BI tools each one plugs into.
| Dimension | Snowflake Semantic Views | Cube | AtScale |
|---|---|---|---|
| Primary architecture | Warehouse-native DDL object | Independent, API-first service | Independent, virtualization engine |
| Data scope | Single warehouse (Snowflake only) | Any number of warehouses or sources | Any number of warehouses or sources |
| Deployment overhead | None, no new infrastructure | Self-hosted or Cube Cloud, a separate ops burden | Deployed alongside warehouses, no data movement, but its own ops burden |
| Governance model | Inherits Snowflake RBAC only | Configured independently, no warehouse-native inheritance | Configured independently, no warehouse-native inheritance |
| BI-tool compatibility | Cortex Analyst and SQL clients | Broad, API/GraphQL/SQL-first tools | Broad, plus native Excel, Power BI, and Tableau reach |
| Pricing model | Included in Snowflake compute | Separate license or Cube Cloud subscription | Separate license, enterprise-negotiated |
| AI-agent access | Cortex Analyst, own MCP surface, Snowflake-only slice | Own MCP server, Cube’s metric slice only | Own MCP server (Databricks Marketplace), AtScale’s metric slice only |
| Analyst recognition | Not independently rated (a platform feature) | Gartner Representative Vendor, Feb 2026 Market Guide | GigaOm Semantic Layer Radar, no Gartner placement |
| Failure mode | Breaks down the moment you add a second warehouse | Governance is bolted on, not inherited, you configure it from scratch | Same governance gap as Cube, virtualization adds a layer to keep in sync |
Example: a mid-market SaaS company on Snowflake evaluating a Databricks lakehouse. Its BI team runs Cortex Analyst against Snowflake Semantic Views today, and it works fine for revenue and pipeline metrics. Its data science team is standing up a Databricks lakehouse for churn modeling six months out. If the company stays Snowflake-only, native views keep winning on cost and simplicity, a pattern echoed across multiple accounts of teams that outgrow a single-warehouse semantic layer only once a second platform actually lands.[12] The open question once Databricks lands isn’t which tool to pick, that part follows from the bucket above, it’s whether both teams get certified to the same “customer” the day the second platform goes live, or whether they find out six months later that they don’t. This kind of honest, no-winner comparison is the same approach agent context layer tools compared takes across a wider set of tools than the three named here.
The stakes for getting this right are measurable. A 2024 data.world study found GPT-4 querying raw warehouse schemas succeeded only 16.7% of the time, compared with 54.2% when a semantic layer sat in front of the same data, and AtScale’s own TPC-DS benchmark reported 92.5% accuracy using a semantic layer with valid join paths and pre-defined metrics.[13] Whichever of the three tools sits underneath, the presence of a semantic layer, not which one, is most of that jump, the same reason OpenAI frontier models vs semantic layers argues enterprises need both a frontier model and a governed layer feeding it, not one instead of the other.
Check your context readiness
Run a quick assessment on how governed your metric definitions already are before you commit to a semantic layer architecture.
Take the Context Gap CheckWhen is platform-native enough, and when does it break?
Permalink to “When is platform-native enough, and when does it break?”For some teams, platform-native is a legitimate, permanent choice. For others, it’s a ticking clock. The difference comes down to whether your two-year warehouse roadmap has a second platform on it, not any technical limitation of Snowflake Semantic Views itself.
| Your situation | Signal | Recommended path |
|---|---|---|
| Single-warehouse, committed | 70%+ of workload in Snowflake, no second warehouse planned in 24 months | Snowflake Semantic Views, native, zero extra cost |
| Single-warehouse, hedging | On Snowflake today, a second platform is plausible within 24 months | Watch the AtScale x Snowflake XMLA Endpoint hybrid path before committing either way |
| Already multi-warehouse | Snowflake plus Databricks, Postgres, or other platforms already in production | Cube or AtScale, one metric layer across all of it |
Most comparison content states “platform-native means lock-in risk” as a one-line caveat and moves on. The actual mistake isn’t choosing native. It’s choosing native without checking the two-year warehouse roadmap first, a process failure rather than a technical limitation of the tool.
The hybrid path is real, not theoretical. AtScale’s XMLA Endpoint, in private preview since Snowflake Summit on June 2, 2026, extends Snowflake Semantic Views’ governed metrics into Excel and Power BI using Snowflake’s own access controls end to end.[11] For a Snowflake-and-Excel-only shop, that closes part of the gap without a second governance system to run. It’s worth naming that honestly: it solves the BI-consumption case, not the AI-agent governance case below.
Gartner’s own framing cuts a similar way. Cube’s recap of the February 2026 Market Guide for Agentic Analytics states that by 2028, 60% of agentic analytics projects relying solely on MCP will fail because they lack a consistent semantic layer.[6] That prediction argues you need a semantic layer, full stop. It doesn’t independently argue you need a governance layer on top of one, and this page won’t borrow it to make that second claim.
Here’s the distinction that does hold up: governed versus ungoverned agent access. All three tools now expose metrics to agents through their own MCP servers, Cube and AtScale directly, Snowflake through Cortex Analyst and its own MCP surface. None of the three shares lineage, certification, or policy across the other two. An agent asking Cube and Cortex Analyst the same question today gets two metric slices back, with no shared audit trail connecting them, no record of who certified either answer, and no single place to check whether either is still fresh. It’s the same governance-model distinction data catalog vs context layer draws for storage systems generally, and how that audit trail actually reaches an agent is the subject of MCP connected data catalog: how governance decides AI accuracy.
If you’ve already ruled out warehouse-native and landed in the “already multi-warehouse” bucket, the deeper vendor decision, pricing, deployment model, BI-tool compatibility, is covered in AtScale vs Cube for the enterprise semantic layer. This page stops at which pattern; that one picks the vendor once you’ve chosen portable. If your second warehouse is specifically Databricks, how AtScale sits on Unity Catalog covers that slice directly.
How Atlan approaches semantic layers across Snowflake, Cube, and AtScale
Permalink to “How Atlan approaches semantic layers across Snowflake, Cube, and AtScale”None of the three tools above governs what happens to a metric once it’s defined: who certified it, whether it’s fresh, or whether the agent asking for it is allowed to see it. That gap doesn’t close no matter which architecture pattern you pick.
A semantic layer answers what “revenue” means. None of the three tools compared here answers who owns that definition, what upstream data supports it, whether it’s stale, what policy applies, or whether the requesting agent is allowed to use it. Teams that pick an architecture pattern and stop there end up with three different “customers” the moment a second warehouse or a second semantic tool enters the picture, the exact failure mode the head-to-head table above names directly.
Atlan ingests semantic definitions from all three, Snowflake Semantic Views, Cube, and AtScale, and layers lineage, ownership, certification, freshness, and policy on top of whichever one (or combination) a team runs, without replacing any of them. For Snowflake specifically, Atlan can generate and sync Snowflake Semantic Views while bringing cross-system metadata into Snowflake and Cortex; Atlan’s MCP server and Snowflake’s own MCP server run in parallel in the same agent workflow, a pattern validated by Atlan’s recognition as Snowflake’s 2025 Data Governance Partner of the Year. That’s what makes any one tool’s metric slice legible to an agent alongside everything else it needs, the same relationship the enterprise context layer plays for every other system feeding an AI agent, and what the enterprise context layer actually is covers that role in more general terms. The same argument how to implement an enterprise context layer for AI works through in more detail than a comparison page needs to, and the certification question specifically, who signed off on a metric and when it was last reviewed, is what active ontology is built to keep current rather than static.
For a CDO comparing this across every data platform, not just these three semantic layers, metadata layer for AI: the complete 2026 guide for CDOs and what is a context graph both go deeper on the same underlying structure, and what is context engineering names the discipline this whole comparison sits inside.
Real stories from real customers: the semantic layer AI actually needs
Permalink to “Real stories from real customers: the semantic layer AI actually needs”"Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI labs, we're co-building the semantic layer that AI needs."
— Joe DosSantos, VP Enterprise Data & Analytics, Workday
See if your agents already know too much, or too little
Run through the checklist enterprise teams use to find governance gaps before scaling AI agents on top of any semantic layer.
Check Your ReadinessWorkday didn’t pick this fight between Snowflake, Cube, and AtScale to get here. It picked a semantic layer, then found the same governance gap this page argues is architecture-independent: a metric layer defines meaning, and something else has to define who’s allowed to act on it. It’s the same shared-vocabulary problem memory layer vs context layer hits from the agent-memory side, and the same reason a context catalog of certified definitions, not just a list of tables, is what actually closes it.
Whichever pattern you pick, the governance question doesn’t go away
Permalink to “Whichever pattern you pick, the governance question doesn’t go away”Check your warehouse roadmap before your feature list. That’s the real decision buried in this comparison, not which vendor wins. A single-warehouse team that overbuys a portable tool pays for flexibility it won’t use; a hedging team that underbuys native pays for a migration later.
The AtScale-Snowflake XMLA Endpoint is an early signal that “platform-native versus portable” won’t stay a clean binary much longer. Watch it, especially if Excel or Power BI reach matters more to your BI team than agent access does today.
No single tool in this comparison wins outright, and none should. The pattern you choose settles storage and reach. It doesn’t settle who certified a metric, whether it’s still accurate, or whether the agent asking for it is allowed to see it, and that question outlasts whichever architecture you pick. Building the discipline to ask it, rather than defaulting to whichever tool your BI team already knows, is most of what separates an AI agent harness that ships from one that stalls. It’s closer to context engineering, not prompt engineering, applied to the agent context layer as a whole rather than any single semantic layer inside it.
FAQs about Snowflake Semantic Views vs Cube vs AtScale
Permalink to “FAQs about Snowflake Semantic Views vs Cube vs AtScale”-
What is the difference between Snowflake Semantic Views and Snowflake Semantic Models?
Semantic Views is the general-purpose semantic layer object usable by any SQL client. Semantic Models is a narrower, YAML-based configuration built specifically to feed Cortex Analyst’s natural-language interface. They serve overlapping but distinct purposes inside the same platform. -
Can I use AtScale and Snowflake Semantic Views together?
Yes. AtScale’s XMLA Endpoint, in private preview since June 2026, extends Snowflake Semantic Views’ governed metrics into Excel and Power BI using Snowflake’s own access controls, without a separate governance system to maintain. -
Is Cube open source?
Yes. Cube Core is dual-licensed: Apache 2.0 for the backend and MIT for the client libraries. Cube Cloud is a separate, commercial hosted offering built on the same open-source core. -
Does a platform-native semantic layer create vendor lock-in?
It creates lock-in only if you add a second warehouse later without planning for it. Teams committed to Snowflake for the next two years take on little risk; teams hedging toward a second platform should weigh that roadmap before committing to native. -
What happens to your semantic layer if you add a second data warehouse later?
A warehouse-native semantic layer doesn’t travel with you. You either rebuild your metric definitions on the new platform or migrate to a portable tool like Cube or AtScale that already spans both. -
Which semantic layer works best with AI agents and MCP?
All three now ship their own MCP server, so the real question isn’t which has agent access, it’s which agent access is governed. None of the three shares lineage, certification, or policy across the others, which is the gap a governed context layer closes on top of whichever one you pick. -
Is a semantic layer worth it for a small or mid-sized team?
For a single warehouse and a small analytics team, a lightweight or native option is often enough. The case for a dedicated, portable semantic layer strengthens once more than one team, tool, or warehouse needs the same metric defined consistently. -
How does Atlan work alongside whichever semantic layer you choose?
Atlan ingests definitions from Snowflake Semantic Views, Cube, and AtScale without replacing any of them, then adds lineage, ownership, certification, and policy on top so an agent gets governed context regardless of which semantic layer supplied the metric.
Sources
Permalink to “Sources”- Snowflake Semantic Views Overview, Snowflake
- Snowflake Semantic Views in Production: Real-World Insights and Best Practices, phData
- Semantic layer governance powers trusted agentic AI, SiliconANGLE
- Cube Core repository, GitHub
- Cube raises $25 million, Cube
- Cube Recognized in the 2026 Gartner Market Guide for Agentic Analytics, Cube
- Interview With Co-Founder and CEO Artyom Keydunov, Pulse2
- Strategic Equity Financing Led by Snowflake, AtScale
- AtScale raises funding round led by Snowflake Ventures, SiliconANGLE
- How Semantic Layers Future-Proof Data Strategies with David P. Mariani of AtScale, Tamr
- AtScale Announces Integration for Snowflake Semantic Views to Extend Governed Metrics to Power BI and Excel, BusinessWire
- Why Snowflake and Databricks Can’t Be Your Enterprise Semantic Layer, Colrows
- Headless vs. Native Semantic Layer: The Architectural Key to Unlocking 90%+ Text-to-SQL Accuracy, VentureBeat
