--- title: "AtScale vs Cube: Choosing an Enterprise Semantic Layer" url: "https://atlan.com/know/ai-agent/semantic-layer/atscale-vs-cube-semantic-layer/" description: "AtScale virtualizes the warehouse for BI tools; Cube serves metrics as code over APIs and MCP. Compare architecture, pricing, and AI-agent fit before choosing." author: "Austin Kronz" author_role: "Director, Data and AI Strategy" published: "2026-09-07" updated: "2026-09-07" --- --- AtScale and Cube solve the same starting problem, one metric definition served consistently to every tool that queries it, with almost opposite architectures and pricing models: [Cube's public Starter tier runs $40 per developer per month](https://cube.dev/pricing), while [AtScale prices on a consumption model](https://www.atscale.com/pricing/) with no public number at all. AtScale connects live to your cloud data warehouse and builds virtualized, aggregate-aware OLAP models that Power BI, Tableau, and Excel query with no data movement. Cube defines metrics as code, Cubes and Views version-controlled like application code, and serves that single definition over REST, GraphQL, Semantic SQL, and its own MCP server. This guide compares the two on architecture, BI-tool fit, deployment model, enterprise scale, and pricing, then closes on the one question neither vendor's 2026 AI-agent pivot actually answers. For the wider field these two sit inside, see the full [semantic layer tools roundup](https://atlan.com/know/best-semantic-layer-tools/), where both AtScale and Cube already appear alongside the rest of the category. > Haven't ruled out a warehouse-native semantic layer yet? See [Snowflake Semantic Views vs Cube vs AtScale](https://atlan.com/know/ai-agent/semantic-layer/snowflake-semantic-views-vs-cube-vs-atscale/) for the 3-way architecture decision first. This page assumes you've already ruled out platform-native and are choosing between the two portable options. - The architecture split: OLAP-cube virtualization vs. code-first, API-native modeling - The pricing-model contrast: public tiers vs. a consumption-based quote - Both now ship MCP servers, but that's a delivery-surface question, not a governance one --- | Dimension | AtScale | Cube | |---|---|---| | What it is | OLAP-cube-virtualization semantic layer connecting live to the warehouse | Code-first, API and MCP-native headless semantic layer | | Architecture pattern | Aggregate-aware virtual cubes, no data movement | Cubes and Views data model, "managed as code" | | BI-tool fit | Power BI, Tableau, Looker, Excel, Qlik, ThoughtSpot, Superset, Klipfolio, Hex | REST, GraphQL, Semantic SQL; BI tools connect via SQL-compatible interfaces | | Deployment model | Connects to Snowflake, Databricks, BigQuery, Redshift, Azure; no separate infra to run queries against | Self-hosted (open-source core) or Cube Cloud; Enterprise adds BYOC/BYOL | | Pricing model | Consumption-based on Deployed Semantic Objects; quote-only, Standard/Enterprise | Public tiers: Free, Starter $40/dev/mo, Premium $80/dev/mo, Enterprise custom | | AI-agent access | MCP server listed on the Databricks MCP Marketplace | D3 platform, Semantic SQL, native MCP server | | Named enterprise customers | Blue Yonder, Papa Johns, TELUS, Wayfair, Skyscanner | Brex, Drata, Webflow, Alcon, SecurityScorecard | | Best for | Enterprise BI and Excel/Power BI estates already on a warehouse | Embedded analytics, developer-built apps, AI-agent-facing metrics | Both columns above represent genuine strengths for different buyers. Neither tool is a weaker version of the other; they're built on different assumptions about who authors a metric and how it reaches its consumer. The customer names above come from each vendor's own published roster: [AtScale's case studies](https://www.atscale.com/customers/) and [Cube's case studies](https://cube.dev/case-studies), current as of this guide's research. --- ## AtScale vs Cube: what's the real difference, and what neither tells your AI agents? The core distinction between AtScale and Cube is architectural, not a matter of one being more mature. AtScale virtualizes a warehouse into an OLAP model that a BI tool queries directly, with no separate infrastructure and no data movement. Cube exposes metrics as version-controlled code, consumed by apps and agents through REST, GraphQL, Semantic SQL, and MCP, rather than through a native BI connection. Both approaches solve the same underlying problem: one metric, defined once, consistent everywhere it's queried, the same question a [semantic layer for AI agents](https://atlan.com/know/ai-agent/semantic-layer-for-ai-agents/) has to answer regardless of which vendor builds it. This isn't the same debate as [semantic search versus keyword search](https://atlan.com/know/semantic-search-vs-keyword-search/), which is about how a query gets interpreted, not how a metric gets defined. A third party studying this exact space independently draws a line worth naming here. Timbr, itself a competitor in the space, describes three camps competing to define "the semantic intelligence AI agents need": metric-governance tools like dbt, Snowflake, and Cube; context-layer platforms, the [semantic layer versus context layer](https://atlan.com/know/context-layer-vs-semantic-layer/) boundary; and ontology tools, a three-way split covered in more depth at [ontology versus semantic layer](https://atlan.com/know/ontology-vs-semantic-layer/). Each camp, in Timbr's own assessment, solves a real problem while remaining locked to a single platform. Timbr names Cube specifically in the metric-governance camp; the same critique applies to AtScale's OLAP-native metric definitions, even though Timbr doesn't name it directly. The market has moved past "does it talk to agents" as the differentiator it was in 2025. Both AtScale and Cube, the latter through its D3 platform and Semantic SQL, now ship a native MCP server, the same reason an [MCP-connected data catalog](https://atlan.com/know/mcp-connected-data-catalog/) matters more every quarter and why [MCP keeps beating plain function calling](https://atlan.com/know/mcp-vs-function-calling/) as the delivery surface both vendors picked. What no existing AtScale-vs-Cube comparison asks, not Gartner Peer Insights, not StackShare, not the independent blogs comparing the two, is what happens to a metric's lineage, ownership, and access policy once an agent or a new BI tool starts consuming it, the exact failure mode [semantic layers failed, context graphs are next](https://atlan.com/know/semantic-layers-failed-context-graphs/) argues is structural, not vendor-specific. Delivering a number to an agent and delivering a governed, citable number to an agent are different claims, and the rest of this page returns to that distinction after covering the fundamentals. --- ## What is AtScale? AtScale connects directly to your cloud data warehouse and builds live semantic models, resolving queries against optimized, pre-computed aggregates instead of scanning raw fact tables. That's the OLAP-cube-virtualization pattern: an accurate, historically grounded description of AtScale's architecture, rooted in its origins in the Excel, SSAS, and MDX space, even though AtScale's own current marketing foregrounds "live semantic models" and warehouse-native connectivity over that legacy language. AtScale closed [what the company calls its largest equity financing to date](https://www.businesswire.com/news/home/20251218641296/en/AtScale-Announces-Equity-Financing-Led-by-Snowflake) in December 2025, led by Snowflake Ventures, without disclosing the round's size, a signal of continued enterprise investment in the OLAP-virtualization model even as the category shifts toward code-first alternatives. The investment tracks a real architectural advantage for a specific buyer: a warehouse-native connection means no separate compute layer to provision or scale, and aggregate awareness routes each query to the smallest sufficient pre-computed rollup automatically, per [AtScale's own product documentation](https://www.atscale.com/product/). ### Core components of AtScale - **Aggregate awareness:** routes queries to the smallest sufficient pre-computed aggregate instead of scanning raw fact tables, per AtScale's own product documentation. - **Deployed Semantic Objects (DSOs):** the governed metric, dimension, and model definitions published for production use, and also AtScale's billing unit, explicitly not charged per seat, per query, or per agent interaction. - **BI-tool connectivity layer:** live, no-data-movement connections to Power BI, Tableau, Looker, Excel, Qlik, ThoughtSpot, Superset, Klipfolio, and Hex. - **MCP server:** AtScale's AI-agent delivery surface, [live on the Databricks MCP Marketplace since December 1, 2025](https://www.businesswire.com/news/home/20251201005442/en/AtScale-Delivers-Semantic-Intelligence-to-Databricks-MCP-Marketplace), the same marketplace covered from the Databricks side in [Unity Catalog metrics on Databricks](https://atlan.com/know/ai-agent/databricks/unity-catalog-metrics/). An OLAP-cube-virtualization semantic layer solves query-time consistency well. It does not, by itself, track who owns a Deployed Semantic Object once its author changes teams, or whether the same object still means the same thing to a new BI tool that starts querying it a year later, the same boundary problem covered from the catalog side in [data catalog vs context layer](https://atlan.com/know/data-catalog-vs-context-layer/). That's a different job, and the rest of this guide returns to it. --- ## What is Cube? Cube models data as **Cubes**, business entities defined as measures, dimensions, and joins, and **Views**, curated, query-ready datasets built on top of those cubes, [explicitly not framed as traditional OLAP cubes according to Cube's own documentation](https://docs.cube.dev/docs/introduction). Everything in a Cube deployment, the data models, the configuration, the access-control policies, is managed as code and version-controlled the same way application logic is. [Cube D3 launched on June 2, 2025](https://cube.dev/blog/announcing-cube-d3) as what Cube calls "the first agentic analytics platform built on a universal semantic layer," pairing three AI agents (Analytics Chat, Workbooks, and Semantic Model) with Semantic SQL, a Postgres-compatible query language built around a `MEASURE` function that Cube frames as a governance mechanism for AI-agent queries specifically. Cube [raised a $25 million Series B led by Databricks Ventures](https://cube.dev/blog/cubes-raises-25-million) in June 2024, bringing total funding to $48 million. ### Core components of Cube - **Semantic SQL:** a Postgres-compatible query layer built around a `MEASURE` function, positioned by Cube as a governance mechanism for AI-agent queries. - **REST, GraphQL, and a Meta API:** interfaces for agent and app discovery of the semantic model, alongside a native MCP server, the reasoning behind [why MCP matters for AI agents](https://atlan.com/know/mcp/why-mcp-matters-for-ai-agents/) over a bespoke API for every consumer. - **Cubes and Views:** the code-defined data model, business entities and curated, query-ready datasets, version-controlled like application code. - **Enterprise tier:** Bring Your Own Cloud, Bring Your Own LLM, SSO with SAML 2.0, workspace access control, and a 99.990% uptime SLA, real, narrower governance features a sophisticated buyer will already know about. Cube's open-source core (`cube-js/cube`) remains the adoption funnel into the managed Cube Cloud offering, and community discussion (unofficial, and not independently re-confirmed here) commonly frames Cube as the more accessible option for individual practitioners, a reputation built on that open-source core and a transparent, self-serve pricing model. What Cube's own documentation doesn't claim to cover is what happens to a metric's meaning once a second team, a new BI tool, or an agent outside the original deployment starts consuming it, the same territory covered in [agent context layer tools compared](https://atlan.com/know/ai-agent/agent-context-layer-tools-compared/) for the broader landscape Cube sits inside. That's the same open question AtScale's architecture leaves unaddressed, just from the opposite direction, and it's a different question again from [agent context layer vs RAG](https://atlan.com/know/ai-agent/agent-context-layer-vs-rag/), which is about retrieval architecture, not metric governance. Get the AI Context Stack brief See where a governed context layer fits relative to semantic layers like AtScale and Cube, and the agents now querying both. Get the AI Context Stack --- ## How do AtScale and Cube compare on architecture, BI-tool fit, deployment, and pricing? The two platforms diverge hardest across five concrete buying dimensions: how each models data, which BI tools it was built for, where it runs, what it costs, and what actually breaks when either one goes under-governed. | Dimension | AtScale | Cube | |---|---|---| | Architecture pattern | Virtual OLAP cubes over the warehouse, aggregate-aware query routing | Code-defined Cubes and Views, Semantic SQL query layer | | Data movement | None; live queries against the warehouse | None for query serving; an optional caching layer | | Modeling approach | Visual, MDX-heritage modeling | Code-based (YAML/Python), version-controlled | | BI-tool integrations | Power BI, Tableau, Looker, Excel, Qlik, ThoughtSpot, Superset, Klipfolio, Hex | REST, GraphQL, Semantic SQL; BI tools connect via SQL-compatible interfaces | | AI-agent delivery surface | MCP server on the Databricks MCP Marketplace | Semantic SQL `MEASURE` function, D3 agents, native MCP server | | Deployment and hosting | Connects to Snowflake, Databricks, BigQuery, Redshift, Azure; no separate compute to self-host | Self-hosted open source or Cube Cloud; Enterprise adds BYOC/BYOL, dedicated single-tenant | | Enterprise security and compliance | Inherits warehouse-native role-based access (Snowflake/Databricks RBAC) | SSO with SAML 2.0, workspace access control, 99.990% uptime SLA at Enterprise tier | | Pricing structure | Consumption-based on Deployed Semantic Objects; quote-only (Standard/Enterprise) | Public: Free, Starter $40/dev/mo, Premium $80/dev/mo, Enterprise custom | | Failure mode | Under-governed: warehouse RBAC alone doesn't confirm the metric means the same thing in every BI tool consuming it | Under-governed: code-as-config controls who can query, not whether the metric's meaning stays consistent across every downstream consumer | Picture a retailer running Power BI for merchandising and a customer-facing embedded dashboard for store operations. AtScale's live warehouse connection and native MDX support serve the Power BI estate with no data movement; Cube's API layer serves the same underlying metric to the embedded app over GraphQL. Both tools can define "same-store sales" once. Neither tells you, six months later, whether the merchandising team's definition and the store-ops team's definition are still the same metric, who last validated it, or whether an AI agent querying either surface is getting a number that traces back to the same governed source, the exact scenario a [context catalog](https://atlan.com/know/context-catalog/) is built to catch before it reaches a dashboard. That gap is what the rest of this page returns to, and it's a different failure mode than the one covered in [data catalog for AI](https://atlan.com/know/data-catalog-for-ai/), which is about discovering data, not reconciling competing metric definitions. According to [StackShare's technical comparison](https://stackshare.io/stackups/atscale-vs-cube-js) of the two platforms, the practical split comes down to AtScale's visual, MDX-based modeling versus Cube's code-based, JavaScript and YAML approach, a framing consistent with everything above: one tool optimized for an existing BI estate, the other for a team that wants its semantic model version-controlled like the rest of its codebase. --- ## Which is better for enterprise scale, AtScale or Cube? Most existing comparisons treat this as "AtScale wins, full stop," because of its OLAP and MDX heritage. That framing understates how much ground Cube has closed since 2024. AtScale's heritage genuinely suits a large, Excel and Power BI-heavy enterprise estate at scale. Native aggregate awareness and MDX support are real advantages for a company with years of investment already sunk into that BI stack, not a legacy limitation to work around. Cube's Enterprise tier has closed much of the gap most existing comparisons don't reflect, because they predate it. Bring Your Own Cloud, Bring Your Own LLM, SSO with SAML 2.0, dedicated single-tenant deployment, and a 99.990% uptime SLA are the kind of enterprise-hardening features that used to be AtScale's exclusive territory. Cube is a named Representative Vendor in [Gartner's Market Guide for Agentic Analytics](https://cube.dev/blog/cube-recognized-in-the-2026-gartner-r-market-guide-for-agentic-analytics), published February 9, 2026 (the primary report is access-gated, so this cites Cube's own announcement of the placement). That's Cube's first appearance in a named Gartner report and a credibility signal enterprise buyers weigh alongside the feature list above. The same announcement quotes Gartner's separate, category-wide finding that by 2028, 60% of agentic analytics projects relying solely on MCP will fail due to the lack of a consistent semantic layer, an argument for having a governed semantic layer at all, not a specific claim about Cube's enterprise readiness versus AtScale's. Gartner also runs a live [Peer Insights compare page for AtScale and Cube](https://www.gartner.com/reviews/market/analytics-business-intelligence-platforms/compare/atscale-vs-cube-dev), worth checking directly for current user ratings rather than repeating a specific score here. The honest framing isn't "does either tool have governance at the enterprise tier." Both do, narrowly. The real gap is whether either extends that governance across the estate: to the raw source tables underneath the semantic layer, to the BI tools and agents that weren't part of the original deployment, to what happens when the person who defined the metric leaves the company. Neither vendor's Enterprise tier reaches past its own semantic layer to answer that, which is the same reason [why AI agents need an enterprise context layer](https://atlan.com/know/why-ai-agents-need-an-enterprise-context-layer/) in the first place, and it's a distinct problem from the one [semantic layer vs data catalog](https://atlan.com/know/ai-agent/semantic-layer/semantic-layer-vs-data-catalog/) untangles about what each category is actually for. --- ## When to choose AtScale, when to choose Cube, and when you might run both The decision heuristic independent sources converge on is straightforward, and it maps closely to the architecture split covered above. Start with **AtScale** if your organization has heavy existing investment in Excel, Power BI, and Tableau across a large enterprise BI estate, needs native MDX connectivity, and wants aggregate-awareness performance at scale without adding infrastructure. Start with **Cube** if you're building embedded analytics or AI-agent-facing applications, your developer team wants metrics defined and version-controlled as code, and you want a public, predictable pricing tier before committing to a sales process. Run **both** if you have a genuinely hybrid estate: enterprise BI on AtScale for the Power BI and Excel user base, Cube for a separate embedded-app or AI-agent surface. This isn't the common case, and it's worth flagging as an edge case rather than a default recommendation for most buyers, the same edge case covered from a wider angle in [agent context layer tools](https://atlan.com/know/ai-agent/agent-context-layer-tools/) and in [context engineering platforms compared](https://atlan.com/know/context-engineering-platforms-comparison/) for teams evaluating more than these two. Arsalan Noorafkan, Developer Advocate at Bruin, states the decision plainly in [Bruin's semantic layer tools guide](https://getbruin.com/blog/semantic-layer-tools): "Choose AtScale if you need enterprise-wide semantic governance across many BI tools, teams, and AI systems. Choose Cube if you need a headless semantic layer for embedded analytics, APIs, applications, or AI agents." An independent semantic-layer analyst reaches a similar conclusion from the other direction in [Semantic Superiority, Part 3](https://davidsj.substack.com/p/semantic-superiority-part-3): for organizations with simpler requirements than a large enterprise, MetricFlow and Cube provide a nicer developer experience, while AtScale suits enterprise customers already equipped to handle larger and more complex data stacks. Whichever tool wins the decision, "governed across many BI tools and teams" and "consistent developer experience for embedded analytics" both describe a metric's delivery, not its lifecycle after delivery. That distinction is where this guide goes next. Take the Context Maturity Assessment Score how consistently your metric definitions hold up once they leave the semantic layer that defined them, AtScale, Cube, or both. Take the Assessment --- ## How Atlan governs the semantic layer either way Both AtScale and Cube now expose their own slice of metrics to AI agents through their own MCP servers, AtScale's own MCP server, Cube's Semantic SQL and native MCP integration. Each agent gets that slice on its own, with no shared lineage, ownership, or access policy connecting it to the rest of the data estate. That's a delivery-surface fix, not a governance fix, and it's the gap this page has pointed at since the opening section. Atlan sits underneath whichever semantic layer a team picks, AtScale or Cube, binding its metric definitions to lineage back to the source tables, glossary terms, ownership, and access policy through the [Enterprise Data Graph](https://atlan.com/know/enterprise-data-graph/), the same mechanism covered in more depth at [what is a context layer](https://atlan.com/know/what-is-context-layer/), then exposing that governed context to MCP-connected agents through the [Atlan MCP Server](https://atlan.com/know/what-is-atlan-mcp/), alongside the metric itself, not instead of it, one instance of the broader [agent context layer](https://atlan.com/know/agent-context-layer/) pattern. [Context Engineering Studio](https://atlan.com/know/what-is-context-engineering/) is the mechanism that bootstraps and tests that governed context for a team already running AtScale or Cube in production, distinct from how [active ontology](https://atlan.com/know/what-is-active-ontology/) reasons over the same graph once it's built. A team running Cube specifically can see the integration mechanics in more depth on [Cube data catalog integration](https://atlan.com/know/ai-agent/semantic-layer/cube-data-catalog-integration/), and a team weighing MCP against other agent-to-tool protocols should see [how to choose between MCP, A2A, and ANP](https://atlan.com/know/mcp/how-to-choose-mcp-a2a-anp/) first. The Snowflake Intelligence and Atlan benchmark is the proof point behind that claim. Grounding text-to-SQL in glossaries, semantic layers, and quality metadata, rather than schema alone, delivered [3x query accuracy at 95%+ reliability across a 522-query enterprise benchmark](https://atlan.com/know/snowflake-intelligence-atlan-partner-talk-to-data/). That's the same mechanism this page has argued for throughout: a semantic layer defines what a metric means; a governed context layer confirms whether the agent asking for it is getting the current, trusted version. Workday's own experience co-building its semantic layer on Atlan, covered below, is the closest live example of this pattern in production. --- ## Real stories from real customers: co-building the semantic layer AI 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 Watch Now → Workday's semantic layer runs on Atlan today, and the pattern it demonstrates, one governed definition exposed to AI agents through MCP, holds regardless of whether that definition originated in an AtScale-style virtualized OLAP model or a Cube-style code-defined one. It's the same "define once, govern everywhere" argument this page has made about AtScale and Cube specifically, from a team already living it. Watch Atlan govern a semantic layer live See how Atlan tracks ownership, lineage, and access policy for metrics defined in AtScale, Cube, or both, in a live walkthrough. Watch the Live Demo --- ## What actually decides the AtScale vs Cube decision isn't the tool, it's what governs it afterward The AtScale-versus-Cube decision is real and worth taking seriously. AtScale fits the enterprise BI estate already built on Excel, Power BI, and Tableau; Cube fits the developer team building embedded analytics or agent-facing applications on a public pricing tier. That's a decision about how you serve a metric, not whether the metric stays governed once it's served. Both vendors' 2026 AI-agent pivots, AtScale's MCP server, Cube's D3 and Semantic SQL, show they see the gap between serving a metric and governing it. Neither has built the fix, because it isn't a semantic-layer problem to begin with; it's a context-layer one. Whichever tool you pick, treat it as needing a governance layer underneath it, not a replacement for one. See [how to implement an enterprise context layer for AI](https://atlan.com/know/how-to-implement-enterprise-context-layer-for-ai/) for what that looks like once you've made the AtScale-or-Cube call. Book a Demo --- ## FAQs about AtScale vs Cube ### 1. What's the difference between AtScale and Cube for a semantic layer? AtScale virtualizes the warehouse into an OLAP-style semantic model for BI tools with no data movement; Cube defines metrics as code and serves them over REST, GraphQL, and MCP APIs to apps and agents. AtScale's aggregate-aware queries suit an Excel and Power BI-heavy estate; Cube suits developer-built and embedded analytics. ### 2. Is AtScale or Cube better for AI agents? Both now ship their own MCP server, so neither is unable to reach an agent. AtScale's MCP server and Cube's Semantic SQL each deliver a metric definition to an agent, but neither extends lineage, ownership, or access policy past that single metric, so "better for agents" depends on whether governance matters as much as delivery. ### 3. Can Cube.js replace a traditional OLAP cube like AtScale? For API-first or embedded use cases, often yes: Cube's code-defined Cubes and Views cover much of what a lightweight OLAP deployment does. For an MDX-native Excel and Power BI estate at AtScale's scale, not fully. The two solve a similar problem with different architectural assumptions, not a strict upgrade path. ### 4. What does AtScale cost compared to Cube? Cube publishes its tiers: Free, Starter at $40 per developer per month, Premium at $80 per developer per month, and a custom Enterprise plan. AtScale prices on Deployed Semantic Objects, its governed metric and model definitions, with no public numbers, so a direct cost comparison needs a quote from AtScale first. ### 5. Does Cube support MDX for Excel and Power BI? No. Cube's native interfaces are Semantic SQL, REST, and GraphQL, not MDX. Excel and Power BI connect to Cube through SQL-compatible tooling rather than the native MDX and DAX support AtScale built for that exact BI stack, so an MDX-heavy Excel estate feels more friction on Cube than on AtScale. ### 6. Can I switch from AtScale to Cube later, or vice versa? Not without redefining the metrics. AtScale's visual, MDX-heritage modeling and Cube's code-based YAML and Python modeling are different enough that there's no automated migration path between them. Switching means re-authoring metric logic in the destination tool's own language, not a configuration change. ### 7. What do most AtScale vs Cube comparisons leave out? Most stop at which tool defines and serves the metric. Few ask who governs that definition once it ships: its lineage back to the source tables, its owner once that person moves teams, and whether every BI tool or agent consuming it still sees the same, current version. --- ## Sources 1. [AtScale pricing model, AtScale](https://www.atscale.com/pricing/) 2. [Cube pricing tiers, Cube](https://cube.dev/pricing) 3. [AtScale product page, AtScale](https://www.atscale.com/product/) 4. [AtScale customer case studies, AtScale](https://www.atscale.com/customers/) 5. [Cube customer case studies, Cube](https://cube.dev/case-studies) 6. [Cube product and architecture documentation, Cube](https://docs.cube.dev/docs/introduction) 7. [Cube D3 launch announcement, Cube](https://cube.dev/blog/announcing-cube-d3) 8. [Cube raises $25 million Series B, Cube](https://cube.dev/blog/cubes-raises-25-million) 9. [AtScale Announces Equity Financing Led by Snowflake, BusinessWire](https://www.businesswire.com/news/home/20251218641296/en/AtScale-Announces-Equity-Financing-Led-by-Snowflake) 10. [AtScale Delivers Semantic Intelligence to Databricks MCP Marketplace, BusinessWire](https://www.businesswire.com/news/home/20251201005442/en/AtScale-Delivers-Semantic-Intelligence-to-Databricks-MCP-Marketplace) 11. [AtScale vs Cube, StackShare](https://stackshare.io/stackups/atscale-vs-cube-js) 12. [Gartner Peer Insights: AtScale vs Cube compare page, Gartner](https://www.gartner.com/reviews/market/analytics-business-intelligence-platforms/compare/atscale-vs-cube-dev) 13. [Best semantic layer tools, Bruin](https://getbruin.com/blog/semantic-layer-tools) 14. [Semantic Superiority, Part 3, independent analyst Substack](https://davidsj.substack.com/p/semantic-superiority-part-3) 15. [Snowflake Intelligence + Atlan: the 522-query benchmark, Atlan](https://atlan.com/know/snowflake-intelligence-atlan-partner-talk-to-data/) 16. [Cube Recognized in the 2026 Gartner Market Guide for Agentic Analytics, Cube](https://cube.dev/blog/cube-recognized-in-the-2026-gartner-r-market-guide-for-agentic-analytics)