Artyom Keydunov


One of the key questions I raised in my recent blog post on the [evolution of OLAP](https://cube.dev/blog/the-evolution-of-olap) was about the communication protocol between a standalone semantic layer, as the next generation of OLAP systems, and the data consumption layer.

Historically, OLAP servers relied on MDX. Many BI tools supported it, but as OLAP started to fade out with the rise of Big Data and later Cloud Data Warehouses, so did MDX. While some BI tools still support it today, most vendors actively discourage its use. Even Microsoft, the original creator of MDX, introduced a modern successor—DAX. DAX has since gained significant traction within the Microsoft ecosystem, yet it never achieved widespread adoption outside of it.

At the same time, we've witnessed a resurgence of SQL across the board. Not only did NoSQL databases fail to replace classic SQL-based OLTP databases like PostgreSQL and MySQL, but SQL has also solidified its position as the dominant protocol for data processing and transformation. Every major CDW is SQL-first, modern transformation tools are SQL-first, and even streaming architectures are increasingly moving toward SQL-first approaches.

Given this landscape, SQL is well-positioned as the ideal communication protocol between a universal semantic layer and BI tools. It's ubiquitous, its adoption is accelerating, and it's already the default language for data analysts. BI tools already support SQL, and the integration ecosystem is mature—virtually every programming language has libraries to communicate over SQL protocols.

## SQL interface challenge
While SQL seems like the natural choice for a universal semantic layer interface, it comes with a fundamental challenge: SQL was designed primarily for OLTP queries and lacks native multidimensional primitives—particularly the concept of a __measure__.

It's easy to introduce a new aggregation function like `MEASURE()` or `AGGREGATE()` to query measures, but the real challenge lies in how the query is evaluated. SQL follows a different evaluation flow from OLAP-focused languages, making it impossible to correctly execute certain analytical queries in SQL that contain measures.

The key difference between SQL and OLAP query languages like DAX is the evaluation flow:
- SQL follows a bottom-up evaluation flow, where child calculation nodes are evaluated first, and their results are passed upward in the query tree. Parent nodes do not influence child node evaluation.
- DAX follows a top-down evaluation flow, where parent nodes influence child node calculations. This allows for context-aware aggregation, a crucial feature in multidimensional analysis.

![](https://ucarecdn.com/a8ea8443-e36e-453a-a8d5-46ec9a83521e/)

To illustrate this issue, let’s look at an example. Suppose we have a __completed_percentage__ measure already defined in the semantic layer. Now, we want to query it from a BI tool using SQL:
```sql
SELECT
  DATE_TRUNC('day', created_at),
  MEASURE(completed_percentage)
FROM (
  SELECT
    city,
    state,
    status,
    created_at,
    completed_percentage
  FROM orders
  WHERE state = 'CA'
) inner_query
GROUP BY 1;
```

If SQL evaluates it bottom-up, we get the following inner query:
```sql
SELECT
  city,
  state,
  status,
  created_at,
  SUM(CASE WHEN status = 'completed' THEN 1 END) /
    NULLIF(SUM(CASE WHEN is_shipped = true THEN 1 END), 0) 
    AS completed_percentage
FROM orders
WHERE state = 'CA'
GROUP BY 1, 2, 3, 4;
```

Here’s the problem:
- Since SQL evaluates the inner query first, it aggregates the completed_percentage measure too early, before the outer query processes the data at a higher level.
- The outer query then tries to aggregate the already-aggregated value, leading to incorrect results.
- In an OLAP-style top-down evaluation, this measure would be correctly computed at the final grouping level, rather than prematurely at the row level.

This mismatch in evaluation strategies is one of the biggest challenges in using SQL as a communication protocol for a standalone semantic layer. 

### Solution

The solution to this problem is to rewrite the incoming SQL query so that it can be correctly evaluated bottoms-up. This means unwrapping all measure calls and ensuring aggregations are placed at the appropriate level in the query structure.

If we take our example query and rewrite it like this, we will get the correct results:

```sql
SELECT
  DATE_TRUNC('day', created_at),
  SUM(CASE WHEN status = 'completed' THEN 1 END) /
    NULLIF(SUM(CASE WHEN is_shipped = true THEN 1 END), 0) 
    AS completed_percentage
FROM orders
WHERE state = 'CA'
GROUP BY 1;
```

This transformation ensures that all calculations happen at the correct stage of query execution, avoiding the incorrect aggregation issues caused by SQL’s default bottom-up evaluation model.

Rewriting queries is not a new concept in the database world. It is a widely used technique in query optimization, where databases internally transform SQL queries to improve performance.

At Cube, we built our own term rewrite system that takes SQL queries with measures as input and produces valid, executable SQL that aligns with bottom-up evaluation. We also handle SQL dialect variations across different data sources—including Snowflake, Databricks, Redshift, and BigQuery—as each of these platforms has different syntax, functions, and optimization behaviors.

Our query rewriting system is part of Cube’s open-source semantic layer engine, built in Rust and based on E-Graph theory. This allows us to efficiently explore multiple possible query rewrites and select the most optimal transformation dynamically. We are also planning to publish our research behind this E-Graph-based term rewrite system soon—so stay tuned!


About Query Interfaces for OLAP Systems


After ChatGPT was released in late 2022, almost everyone in data and analytics rushed to leverage GenAI models for text-to-SQL solutions. After two years, it became clear that text-to-SQL alone was not simply enough.

Enterprises need intelligent AI teammates to amplify their data and analytics teams' productivity. This is part of a larger trend as enterprises adopt [agents](https://www.salesforce.com/agentforce/) and [digital teammates](https://www.mayfield.com/ai-teammates/) across different roles and functions in the organization. Future AI data engineers will work alongside human data teams to carry out tasks such as building data assets, investigating ongoing issues, and optimizing costs.

For an AI agent to be a helpful teammate, it is not enough to take a natural language query as input and output a SQL statement. AI agents for data and analytics need a comprehensive understanding of the existing underlying data assets, from the raw data through transformations and semantic modeling to reporting. More importantly, they need the ability to make changes to these assets as they reason and go through the chain-of-thought process.

For example, when the agent is tasked with adding a new report to the existing dashboard, it needs to evaluate the existing semantic model to see if the current model can support the requested report. If it lacks dimensions or measures for the required report, the agent needs to go into the transformation and raw data layers to see what is available and what needs to be built or modified. It would investigate, build, test, validate, and collect feedback from the human as it progresses through the task to finally deliver the requested report.

## Use cases
AI data engineers can perform a variety of tasks, but the deliverables typically come down to either the creation of a new data asset or the modification of an existing one. The agent can modify extract-load pipelines, transformations, semantic models, and, ultimately, dashboards and reports.

The value added to the business is increased productivity. AI will level up every data professional: senior data engineers will be able to do more within the same timeframe as before, and junior data engineers will be able to tackle more challenging tasks. It will also enable less technical team members to contribute to areas they couldn't before, e.g., dashboard designers contributing to data transformation pipelines.

Agents will be able to handle most of the use cases data teams are working on today – creating or modifying reports and dashboards, optimizing queries from time and cost perspectives, debugging data issues, refactoring codebases, etc.

## Architecture
We still need to build many basic blocks to enable this future. Some of them would require advancing the fundamental enabling technology - LLMs, while others would require infrastructure for AI agents to retrieve, understand, and modify data assets.

### Advanced reasoning 
In September last year, OpenAI [introduced o1](https://openai.com/index/introducing-openai-o1-preview/), a new series of models with a reasoning architecture that spends more time thinking about problems. This architecture and chain-of-thought approach are prerequisites for complicated AI agents that can complete sophisticated tasks, such as making changes to the organization's data assets. We are still in the very early stages of this next frontier in AI, but the development pace looks very promising.

AI data engineers will rely on reasoning and chain-of-thought processes as they receive input from humans, delve into semantic models, transformations, and the data itself to ultimately perform actions for the given task.

### Data Assets as Code
The data and analytics field has experienced a massive trend in recent years of applying software engineering practices to data management. This has led to the rise of code-first workflows as the primary way to manage data assets. Code-first workflows provide many benefits for humans, such as collaboration, version control, and CI/CD, but they are absolutely necessary for AI agents.

AI agents consume code as input and produce it as output. This will become the major interface layer between the agents and data tools for managing transformations, semantic modeling, and BI-as-code data assets.

AI agents will work on multiple tasks simultaneously. They will create branches within the version control system, spin up containers, make changes to the codebase, run CI, and present results to humans. Humans will review code changes and provide feedback through the code review process. This way, code-based workflows being used by data teams today can seamlessly integrate new AI teammates.

### Agents Workspace
As humans need laptops and access to data tools, AI agents would need containers to execute workflows and API access to data systems. AI data engineers will write code faster than humans do today. This would set a high bar for infrastructure.

On one end, it would need to scale up massively as agents can work on thousands of threads simultaneously. On the other end, it should scale down to zero once agents are done with their work. The speed of provisioning containers for AI agents would be crucial.

### Interoperability of the existing data tools
Human data teams use many different data tools in today's workflow: extract-load, transformation, warehousing, semantic modeling, cataloging, observability, visualization, etc. Agents would need a way to programmatically manipulate data asset states within these systems. I believe code will become the universal way to manage the state of data assets across the board, and data tools will integrate with existing version control and CI/CD systems to enable development-deployment cycles for both humans and agents on data teams.

At Cube, we are excited about the future of AI agents for data teams and the opportunity to contribute to making it happen. We're investing in building the fundamental blocks to enable AI agents to manage data assets across the data stack. Please [reach out](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=ai%20data%20analyst%20blog) if you would like to discuss the future of data and analytics!


AI Data Analyst

Pavel Tiunov


Today we are [launching D3](https://cube.dev/product/cube-d3) ("data in cube"), an agentic analytics platform powered by the Cube semantic layer.

Launching D3 feels like coming full circle. We built Cube more than 5 years ago to power a side project—a Slack AI chatbot for analytics. While AI capabilities were very limited back then, we discovered enormous value in extracting Cube from that project and making it a standalone universal semantic layer. We published it as an open-source project, and it took off. Today, thousands of organizations use both our open-source and cloud products to power business intelligence and embedded analytics workloads.

In many ways, Cube was ahead of its time. When ChatGPT came out, we felt that this was the moment we had built Cube for and had been waiting for all along.

## What is D3?

AI has made tremendous progress since then, and we need a semantic layer more than ever before. It provides unique context about data to AI agents while establishing a foundation for correct and trusted AI results. In the last two years, the Cube community has built numerous AI-first experiences by combining state-of-the-art LLMs with the open-source Cube Core semantic layer—creating internal analytics agents, external-facing chat interfaces, and operational workflows. Now with D3, we're introducing a first-party agentic analytics platform built entirely with the Cube semantic layer. It can be used to both surface insights internally and embed agentic analytics functionality into external apps.

<video src="https://ucarecdn.com/c8e8e80a-6452-48dd-a5f6-3ee61915dc82/" controls controlslist="nodownload"></video>

D3 is unique because it was built from first principles for AI-augmented workflow and is fully based on semantic understanding of data—from the shared semantic model to workbooks and reports layers. We believe in the synergy between AI agents and humans in an augmented workflow. AI-generated queries or reports can be instantly modified by humans and vice versa. AI can handle routine tasks like updating workbook filters, maintaining data models to match CDW tables, and reorganizing data apps layouts, while humans focus on deriving insights from the data. 

With D3, we are introducing several core experiences:

- **Analytics Chat.** A user-friendly chat interface that allows non-technical users to quickly access curated data from semantic models and workbooks, complete with summaries and insights.
- **Workbooks.** A reimagined analytics workbook interface that combines traditional features—point-and-click functionality, table calculations, SQL, and Python—with AI-driven capabilities.
- **Data Apps.** Similar to Replit, Lovable, and v0, but specifically for data applications. Create and deploy data apps using modern frameworks, powered by your semantic layer and workbooks. Share them internally or embed them in existing applications.
- **Semantic Modeling.** AI-powered semantic model development that can create Cube data models from scratch, automatically sync with upstream data mart changes, and implement advanced analytics including cohort analysis, funnels, and more.

## Semantic Layer and Semantic SQL

All these experiences are built around the Cube semantic layer and Semantic SQL.

For AI to be truly useful in analytics workflows, it needs a semantic layer to understand business context. But this alone isn't enough—AI also needs a structured, governed way to query and extend this layer. We can't just feed AI metric definitions and hope it generates correct queries. Effective governance requires AI to query the semantic layer rather than the warehouse directly. This ensures semantic layer definitions are used correctly. Put simply, AI needs a query language for the semantic layer.

What makes an ideal query language? It should be well-established, thoroughly documented, and widely discussed on platforms like Stack Overflow. This ensures out-of-the-box AI models already "know" it well. The language must also let users directly query semantic objects while flexibly creating ad-hoc dimensions and measures.

SQL stands out as the obvious choice.

D3 agents use Semantic SQL to query semantic definitions directly and create ad-hoc calculations on the fly. This strikes an ideal balance between governance and flexibility. Users can review and modify these Semantic SQL queries through a visual editor or by editing the SQL code directly.

![](https://ucarecdn.com/fe74654a-5c09-49cc-b804-776f029ec7bb/)

Ad-hoc calculations can be saved and reused across workbooks and, when needed, added to the shared semantic model.

This balanced approach to flexibility and governance creates the foundation for AI-enabled self-serve analytics. With AI assistance, data users can quickly access governed data in the semantic layer while extending their analysis through custom definitions and metrics as needed.

## For Humans and Agents

D3 is designed to be used by both humans and AI agents. As organizations increasingly delegate tasks to AI agents, these agents will need access to data insights. We envision a multi-agent ecosystem where sales, marketing, logistics, and other AI agents can seamlessly request insights from D3 agents.

D3 agents are already accessible through MCP (available now in Claude Desktop) and A2A protocols. We're committed to supporting these and new inter-agent communication protocols.

![](https://ucarecdn.com/3e0b7380-1e75-4677-a475-d89ed50f77d5/)

## Multi-Agent Architecture

To summarize, D3's approach divides analytics building into three distinct problems:

1. **Building the Semantic Layer**
2. **Building Semantic SQL on top of the Semantic Layer**
3. **Building Visualizations using Semantic SQL**

Each of these areas incorporates multiple AI safeguards—including compilation checks, linters, best-practice prompts, documentation, and memory retrieval. While other solutions try to tackle all three problems at once, our approach makes the process more reliable for AI by treating them as separate, independent components.

![](https://ucarecdn.com/36dad216-0b16-40bd-b134-ad4d8cdbff05/)

## Book a Demo

You can [Book a D3 Demo with us here.](https://cube.dev/request-demo?utm_source=cube&utm_medium=blog&utm_content=d3%20launch%20blog)


Announcing Cube D3


I'm thrilled to announce that the talented team from Narrative BI is joining Cube to accelerate our mission of building the future of agentic analytics. Michael Rumiantsau, founder of Narrative BI, will be joining as VP of Product to help lead this next phase of innovation.

For years, the Narrative BI team has been at the forefront of making analytics proactive, conversational, and intelligent: creating experiences where insights come to users without dashboards, prompts, or manual digging. They've built an impressive platform serving hundreds of customers and thousands of users who've experienced firsthand what truly intelligent analytics can look like.

**Why this partnership makes perfect sense**

At Cube, we've been pioneering the semantic layer as the foundation for modern data stacks. We've always believed that the semantic layer is essential for AI-powered analytics: it provides the context, governance, and consistency that AI agents need to deliver reliable insights.

The Narrative BI team brings deep expertise in agentic workflows and AI-driven data analysis that perfectly complements our semantic layer technology. Together, we're uniquely positioned to build the leading agentic analytics platform that combines Cube's powerful data modeling capabilities with proven AI agent architecture.

**Building on proven foundations**

This partnership strengthens our commitment to our agentic business intelligence platform announced earlier this year. With the Narrative BI team's expertise, we can accelerate development of:

- **Natural language analytics** that understand business context through our semantic layer
- **Agentic workflows** that proactively surface insights and recommendations
- **Multi-agent architectures** that can collaborate across different data domains
- **Embedded analytics** powered by AI for customer-facing applications

**What's next**

The future of analytics isn't just about making existing BI tools smarter—it's about fundamentally reimagining how humans and AI collaborate with data. We're building toward a world where:

- Business users can have natural conversations with their data
- AI agents can autonomously identify trends, anomalies, and opportunities
- Data teams can scale their impact without scaling headcount
- Every application can have intelligent analytics embedded natively

The Narrative BI team started with a vision to reimagine analytics in the age of AI. Now, together with Cube's semantic layer foundation and growing ecosystem, we're positioned to make that vision a reality at scale.

To the Narrative BI community: welcome to the Cube family. Your journey toward truly intelligent analytics is just beginning.


Building the future of agentic analytics: Narrative BI team joins Cube


Today we are launching [Cube Agentic Analytics](https://cube.dev/product/cube-d3) in general availability.

We first released a preview in the summer under the name D3, and the response was tremendous. Early customers gave us invaluable feedback, and we've been iterating on the product ever since.

Today I'm excited to announce that **it's live for everyone in Cube**—you can sign up and start using it right now.

With this update, we are removing "D3" from the name and unifying our semantic layers and agentic analytics product offerings under a single user interface and name - Cube.

Our vision is to create an agentic business intelligence platform where agents work alongside humans—from modeling to exploration and presentation. We're building agents that can handle the full range of BI tasks while giving humans fine-grained control over every action.

All of the features below are available as of today. Some might still have a few rough edges and will continue to improve rapidly—but they're fully functional and ready to use.

## Semantic Model Agent
Semantic Model Agent helps you build data models from the ground up or improve existing ones. It can bootstrap data models from scratch based on tables in your cloud data warehouse, convert existing projects (like LookML files) into Cube data models, and continue building alongside you—adding measures, dimensions, updating descriptions and joins, creating views, and generally improving the data model as you go. It can also help create and optimize SQL transformations.

<video autoplay="true" loop muted playsinline="true" preload="auto">
  <source src="https://lgo0ecceic.ucarecd.net/6f958f07-b568-4c99-b3ac-77cca9c18840/" type="video/mp4" />
</video>

## Workbooks and Dashboards
Workbooks and Dashboards provide the place for data exploration and presentation. In workbooks, users can explore the semantic model to find insights. While the workbook agent can build and update reports, we give users fine-grained control over all the details of the analysis - from fields and filters in queries to colors and labels on the chart. That design enables users to rely on AI for building the majority of the analysis and apply final touches and corrections when they see fit.

![](https://ucarecdn.com/925f9355-b548-49c6-8eee-a532fd0f8f5a/)

Dashboard is the presentation layer of the workbook. Once the analysis is done, it can be package into shareable artifact and deployed to be used across the organization. Workbooks and dashboards come with variety of visualizations - from tables, bars, lines, heatmaps to KPI cards and custom html/markdown charts. Workbook and dashboard agents are trained to create and update variety of visualizations supported by Cube.

![](https://ucarecdn.com/3d094ce6-3c26-4dea-9b5a-61ca1fccd5af/)

Dashboards can be powered by Cube pre-aggregations for improved performance and embedded into your applications. 

## Analytics Chat
Analytics Chat is a helpful entry point to the analysis. Users can ask different questions —whether it's a direct question to look up information about a specific account or more open-ended questions to spot trends, uncover insights, or simply check how things are going.

The AI agent can create multiple queries, reason about the data, analyze it, and summarize findings back to the user. The agent in Analytics Chat queries the semantic model but can also create ad hoc analysis on top of existing measures and dimensions. This gives unique flexibility while maintaining full governance. Valuable insights from the Analytics Chat can be saved to Workbook for further analysis.

## Doubling Down on Embedded Analytics

Cube is already powering embedded analytics applications across thousands of organizations, and with these new Agentic Analytics capabilities, we're doubling down on our embedded analytics offering.

We've designed all the agentic analytics features so they can be embedded into your applications. Users can continue to use our headless embedded offerings through the APIs, but now we also offer the possibility to embed all the experiences mentioned above—dashboards, workbooks, and analytics chats—with our frontend components, fully customizable to match the styles and theming of your application.

## Pricing

With this update, we're adding [user seat pricing only for users with direct access to Cube.](https://cube.dev/pricing) Our embedded analytics offering remains priced based on compute, as it always has been.

We continue to provide a free tier and are including limited agent requests to the free tier.

## Next Steps

If you're an existing Cube customer, simply log in to your account and activate Agentic Analytics capabilities.

For new customers, these capabilities are active from signup. Sign up today and try them out—our free tier gives you access to all features so you can explore our agentic capabilities.


Cube Agentic Analytics


_TLDR; Cube now has a first-party [agentic analytics](https://cube.dev/product/cube-d3) frontend that deeply integrates with our semantic layer and is designed from scratch to support AI-augemented workflows._

Since open-sourcing in 2018, Cube has been a headless universal semantic layer. We even had "Headless BI" as a slogan on our website [back in 2022](https://web.archive.org/web/20220601163135/https://cube.dev). When we started Cube, the main use case was embedded analytics. Our customers would build the data model in Cube and use it to power charts or dashboards inside their apps via our APIs.

Later, we added integrations with different BI tools via our SQL API - a Postgres-based SQL interface extended to support querying multidimensional data. SQL API enabled our customers to run different BI and visualization tools on top of Cube.

Cube users were constantly asking us whether we'd consider adding our own frontend. We were slow to do that because, up until recently, we were unsure of how our business intelligence frontend would be unique and stand out in the market. That has changed with the arrival of modern AI. We believe that AI will change the landscape of data tools similar to how other major technological shifts have done it in the past. We also believe that Business Intelligence as a category of software won't disappear, but rather transform into **Agentic** Business Intelligence.

![](https://ucarecdn.com/e316c254-5e13-4430-8a82-1e546d38e22c/)

## What is agentic business intelligence?

In the Business Intelligence workflow, we have three key functions: **Modeling**, **Exploration** and **Presentation**.

**Modeling** is a process of defining the semantic data model, that includes measures, dimensions, joins, etc. Historically that has been done in a drag-n-drop UI. Looker pionereed code-first data modeling with LookML and, since than, that approach has gained more traction. Many modern companies, including Cube, offer code-first semantic modeling.

In **exploration** we slice and dice data to find and curate insights. That is usually done in a Workbook-style interface and considered to be one of the core BI experiences. During exploration, user can produce multiple reports. Most of them would be thrown away, but some of them will made it to the next step to be shared across organization.

**Presentation** is about organizing insights into data artifacts that can be shared across organization, that usually takes the form of dashboards.

These three functions are quite diverse

Idea behind **agentic** business intelligence is to augement these three functions of BI workflow with AI. It is based on two key architecture principles:
- AI can do everything humans can do in BI either reactively or proactively
- Humans have fine-grain control over the result of every AI action

In **Modeling**, AI can bootstrap new data models or modify existing ones, with humans maintaining the authority to reject, partially accept, or correct these changes as needed. During **Exploration**, AI collaborates with humans in workbooks to construct and refine reports, accelerating the journey from data model to insights. In **Presentation**, AI assists in creating and designing customized visuals and dashboards that align with the organization's aesthetic requirements.

That workflow can be interactive, where AI is prompted by a human to work on data artifacts. The human sees the results and makes corrections either via UI or via continuous prompting. Alternatively, it can involve AI working in the background to produce useful changes to the data content and then sharing these with humans.

Ultimately, it leads to **increased productivity of data professionals** and **lowers the entry barrier to using business intelligence** for broader knowledge workers.

![](https://ucarecdn.com/a1947386-16e0-4f37-a6ef-a4cd252616ce/)

## What are the benefits?

Similar to what is happening in software engineering, AI can both increase the productivity of professionals and lower the entry barrier to the technical field.

The former would enable data teams to move faster. At Cube, we have been in the business of semantic modeling since 2018, and I can tell you based on my experiences - everyone loves semantic layers and wants to have one. No one likes to build and maintain them. Not only is it an intellectually complicated task, but it also requires a lot of mundane work to get it up and running across systems. We have a unique opportunity now with AI to significantly streamline this process. AI can take on a lot of mundane work, but also acts as an omniscient helper ready to pull any reference knowledge, best practice example, or specific how-to guide on how to solve a particular analytics problem in the particular data modeling framework.

The latter, lowering the entry barrier to using business intelligence for broader knowledge workers, is all about self-service analytics. Almost no data leader is satisfied with level of BI and analytics adoption in their organization. While we are constantly searching for ways to increase it, it only improves on the global scale during the transformative technological changes. I believe AI is one of them. It can enable knowledge workers to slice and dice data to find insights and build complicated visualizations just by asking AI to do so. No need to go through Tableau certification process and search Youtube for a video on how to make that funnel chart in your BI tool.

But what if AI hallucinates and creates wrong insights? That is where we need a semantic layer more than ever. That is the exact reason why we are building a BI layer for Cube today.

## Why Cube?

Semantic layer is not a new concept. It has been in and around BI world for decades. Some's BI tools semantic layers are better than others, but almost every one has it. It enables safe self-serve analytics , at least, through the foundational governance layer. Semantic layer exposes **explorable objects** (explores in Looker, views in Cube) that are safe to use in the BI tool UI. It means data consumers can safely slice and dice these objects to create insights without a risk to create wrong analysis. These safe zones are guarded by semantic layer and can provide foundation for **exploration** and **presentation** workflows to data consumers.

While having a semantic layer in BI comes with a lot of benefits, there are some practical implementation challenges:
- Semantic layer would constantly require updates and changes. Data reflects the business and business is not static. Data consumers are restricted to analyze only what they have in semantic layer, therefore they will constantly request more dimensions and measures in explorable objects and more new explorable objects.
- That might easily lead to explosion in amount of explorable objects to a point where it would be impossible to navigate them.

This creates a situation where it is difficult for data consumers to understand which object to use for exploration. Similarly, for data teams, it is challenging to understand what objects are being used and how.

We believe AI can help navigate this inevitable BI complexity from both sides. First of all, it can increase productivity of the data team in managing semantic layer, from rapidly adding new definitions to deprecating and sunsetting old ones. For data consumers, AI can search within the semantic layer to find the relevant models and build insights from them.

## Next Steps

Today, we are just scratching the surface of what is possible. While many in the industry are focused on Text-to-SQL, I see the biggest unlock in applying AI to solve BI complexity and workflow problems.

If you like to learn more, join one of our upcoming [Inside Cube product demo series](https://cube.registration.goldcast.io/webinar/9359cc6e-5954-4ec5-ba20-de9b295ad0ce) or [reach out to request demo](https://cube.dev/request-demo) of what we are building.


Cube Native AI/BI Frontend


Our mission at Cube is to use consistency, context, and trust to enable the next generation of data experiences. We are innovating daily for our clients and the community of data engineers and app development teams who use Cube to unify, govern, optimize, and integrate across the data stack and an increasing number of data consumers, such as AI, BI, spreadsheets, and embedded analytics. We've worked quickly over the past year to bring new features, APIs, use cases, and even more integrations to help you enhance the management and consumption of data both inside and outside your company.

For our efforts, Cube garnered a #1 ranking in Dresner Advisory Services' inaugural [2025 Semantic Layer Market Study](https://learn.cube.dev/dresner-report). Cube Cloud is recognized for its data integration and access control strengths, modeling and transformation, and performance and optimization. We are honored to advance as a leader in this critical and emerging part of the data stack and grateful for your support as a customer. Thank you for being part of our success.

## Why Universal Semantic Layers Are the "Next Big Thing"

In its market study, Dresner highlights the growing need for a [universal semantic layer](https://cube.dev/use-cases/semantic-layer), noting that it "provides an application-independent view of data objects that are critical to the operation of the business. These views are readily accessible from various applications and tools, making them available when and where needed for both operational and analytical use cases. The data presented via a semantic layer is semantically aligned—this means that differences in syntax and terminology across the various applications and structures from which the data is sourced have been rationalized into a consistent, understandable, and agreed-on format and meaning for optimal value at the point of consumption."

Businesses are looking for ways to combine the advantages of OLAP (Online Analytical Processing) with contemporary, cloud-native technology as more and more people rely on data for decision-making. Cube Cloud fills that gap by combining the advantages of cloud data processing engines' flexibility, speed, and scale with OLAP's structured methodology. Thanks to this combination, teams can easily manage both historical and real-time data. 

Organizations are also discovering that the accuracy of the underlying data is more important to AI success than algorithm complexity. AI projects risk generating erroneous, inconsistent, or even deceptive results if they lack a solid basis of trustworthy, controlled, and accessible data that a universal semantic layer offers. While some companies may find themselves caught in the same cycle of fragmented insights and unmet potential, others who begin their AI initiatives by establishing a universal semantic layer will be well-positioned to turn AI into a competitive advantage.

The fact that Cube Cloud is regarded as a pioneer in this field demonstrates how important this technology has grown. Cube Cloud offers a scalable, quick, and simple solution for companies searching to consolidate their data, improve decision-making, deploy successful AI initiatives, and eliminate the friction that frequently results from using disparate platforms.

## Read the Full Report

Cube will continue to innovate around the universal semantic layer so that you can unify and deliver trusted data to any data consumer. Cube's recognition isn't just about today's data challenges; it's about building the future of modern data architecture with a universal semantic layer that's as adaptable as it is powerful. Thank you for being on this journey with us.

For data and app development teams looking to bring consistency across data sources and data consumers and accelerate insights, Cube Cloud's leadership in Dresner's market study clearly signals its impact and future potential. Read the [full report](https://learn.cube.dev/dresner-report?utm_source=cube&utm_medium=blog&utm_content=dresner%20blog) to understand why Cube Cloud is leading the charge in the universal semantic layer and how it can benefit your team.


Cube Ranks #1 in Dresner Advisory Services' 2025 Semantic Layer Market Study


I am thrilled to announce that we have completed $25 million in funding. As part of this round, Nnamdi Okike, co-founder and Managing Partner at 645 Ventures joined us as a new board observer for Cube's Board of Directors. I am honored that Nnamdi and <a href="https://645ventures.com/" target="_blank" rel="noopener">645 Ventures</a> have doubled down on their investment and belief in what we can achieve at Cube. 

<a href="https://www.databricks.com/" target="_blank" rel="noopener">Databricks</a>, our strategic partner, joined this funding round. The Databricks team shares our vision that the semantic layer is a necessary component of the AI-enabled future of the data stack. With this new investment, we are deepening our relationship with Databricks and reaffirming our commitment to our roadmap to support an AI-enabled data intelligence future.  

> Andrew Ferguson, VP, Databricks Ventures, said it best “The semantic layer is critical to data intelligence and provides necessary context for AI agents to analyze data with higher accuracy.” 

## Solving data problems with the universal semantic layer

In 2019, Pavel and I started Cube to create a single place to manage data models, security, and caching. As we talked to more people and worked with customers, the problem that needed to be solved became clearer. Data models are spread across too many BI tools, and data engineers need an [open and universal semantic layer](https://cube.dev/use-cases/semantic-layer) to deliver trusted data. The data community needs to create a single source of truth that can feed metrics and defined data to any data app, BI tool or AI agent.

## How we got here
We launched the first version of open source Cube on HackerNews in 2019. Cube Core grew rapidly in the first several months, crossing 10,000 stars on GitHub and 1,000s of data engineers and developers joining the community almost overnight. Today, Cube’s open source community has grown to over 10,000 developers in the Cube Slack community, and it has 17,000 stars on GitHub. In 2021, the team built and launched the commercial version, [Cube Cloud](https://cubecloud.dev/auth), and signed up customers online or through a small sales team. Today, Cube Cloud is experiencing 3x growth year over year in both customers and bookings.

## What today's semantic layer looks like
Today, Cube Cloud is a universal semantic layer that is an independent yet interoperable part of the data stack between your data sources and data apps. And being universal is critical: Cube is vendor- and technology-agnostic. Cube Cloud connects to every cloud data warehouse on one side and to every data consumption tool on the other side – whether it is BI tools, Excel, embedded analytics, or AI agents –  using the same semantics and underlying data. This leads to consistent and trusted insights, ultimately driving informed business decisions. 

We are committed to being technology agnostic and helping our customers avoid a vendor lock-in. Implementing a universal semantic layer means you can connect to any cloud data source and any visualization tool, and are never locked into one technology. In the rapidly evolving modern data stack, flexibility must be a top priority because you need the ability to add, remove, or change solutions according to your evolving requirements. When business definitions are institutionalized in a universal semantic layer, migrations to new platforms are as simple as pointing to the new endpoint.

We keep building Cube Cloud with these critical core tenants:

- **Cube is code-first** and believes in empowering the data engineer by applying software engineering best practices and processes to data management, following CI/CD software practices, creating isolated environments, and delivering easy version control.
- **Cube is interoperable** so you can model once, deliver anywhere with a robust set of deployment options, data connectivity, and native APIs to any data endpoint.
- **Cube is fast** and optimizes data workloads with a combination of in-memory cache and pre-aggregations to enable interactive analytics with the flexibility of live connections to the cloud data warehouse.

## What's next
With new funding, we are doubling down on our roadmap in our core areas: data modeling, interoperability, and performance. We are also investing in supporting an AI-enabled data intelligence future:
- **Data modeling**. We’re expanding our data modeling capabilities to support more complicated calculated metrics and introducing low-code tools to empower more data professionals to build semantic models in Cube.
- **Interoperability**. We already support dozens of BI and data consumption tools. Earlier this year, we introduced support for the <a href="https://www.prnewswire.com/news-releases/cube-adds-support-for-the-microsoft-data-and-analytics-ecosystem-to-deliver-a-truly-universal-semantic-layer-to-enterprises-302080313.html" target="_blank" rel="noopener">Microsoft suite</a> of products. Integrations and interoperability remain our big priority, and more integrations are coming. This includes BIs, spreadsheet applications, and other data consumption tools. 
- **Performance**. We believe users shouldn’t need to choose between “extracts” and “live queries.” With our intelligent caching, we can provide the best of both worlds: interactive analytics with live drill-down capabilities to the cloud data warehouse.
- **AI-enabled data intelligence**. The semantic layer provides critical context for AI agents to analyze data with higher accuracy. We’ve recently released [AI API to enable AI agents](https://cube.dev/blog/introducing-the-ai-api-and-chart-prototyping-in-cube-cloud) to access data in the cloud data warehouses. For that, we've built a robust retrieval augmented generation (RAG) architecture on top of Cube’s semantic layer to provide the most relevant context about the data to LLMs. Looking into the future, there are a lot of opportunities in applying Gen AI not only to data consumption but to the development and maintaince of the semantic layer itself. 

Be on the lookout for what’s to come as we add more functionality with every release. I can’t wait to see what you build on top of Cube!

Come talk to us and we will [help you get started](https://cube.dev/contact).


Cube raises $25 million


From the beginning, we envisioned Cube as a self-serve, open-source universal semantic layer for all data practitioners. Cube’s self-serve model lets users access semantic layer capabilities without barriers, whether they are building with Cube Core or running workloads on Cube Cloud. 

In Cube Cloud, we offer a Free tier that doesn’t require any commitment or credit cards. I believe this is important because it provides an opportunity to every data engineer and developer to test and use Cube Cloud. Additionally, we have a Starter tier with access to low-scale production infrastructure on a monthly basis, allowing startups and smaller organizations to use Cube Cloud without an upfront commitment. 

Today, I’m excited to announce updates to Cube Cloud’s offerings, providing a step forward in our commitment to make Cube more self-serve, accessible, and adaptable to the needs of today’s data professionals. With these new updates, our commitment to this model continues, giving users even more control and options.

Now, we are extending our self-serve offering to the next tier—Premium. This is the next step toward our bigger vision of making Cube more self-serve. This update is designed to provide increased flexibility for our users, allowing data and app development teams to explore the power of Cube Cloud at levels that align with their unique needs and usage patterns.

## Choose from Flexible Payment Plans 
First, we’re introducing flexible payment plans for entry-level tiers, structured to provide more options, so you can choose the plan that works best for your goals and budget.

- __On-Demand:__ This “pay-as-you-go” model is a great fit for users who prefer maximum flexibility without any long-term commitment for the Starter and Premium tiers. With On-Demand, you only pay for what you consume, with no minimum monthly fees, making it easy to scale up or down as needed. 
- __Commit:__ For customers with consistent or larger usage needs, the Commit plan offers annual commitments that include eligibility for volume discounts, unlimited support, and access to professional services for the Premium, Enterprise, and Enterprise Premier tiers. This plan is designed to support growing data teams by providing cost efficiency along with enhanced support.

## What’s New in the Starter and Premium Tiers?
We’ve made adjustments to the Starter and Premium tiers to ensure they meet the needs of any organization and budget:

- __Starter Tier:__ The Starter tier is now fully consumption-based, meaning there’s no monthly minimum. You can scale your usage at your pace, with full transparency over your costs.
- __Premium Tier:__ For those ready for full production-level use, we’re introducing a Premium On-Demand option without any annual contract. This allows you to access the Premium tier at your own pace and scale without committing long-term, while enjoying valuable support options, including community Slack, chat, email, and four monthly support tickets. And as your usage grows, the Premium Commit plan offers an efficient path to unlimited support and eligibility for volume discounts.

![](https://ucarecdn.com/9624a06d-ddbe-4886-aab2-506ce549e00b/-/quality/smart/-/format/auto/)

We understand that flexibility is key, especially as data demands evolve. For existing Starter customers, we’re providing a grace period until November 1, 2025, to transition to the new pricing model gradually. This ensures everyone has the time to adjust and make the most out of Cube Cloud’s expanded self-serve capabilities.

These updates reflect our ongoing mission to empower data professionals with a platform that grows with them. Whether you’re testing in the Starter tier, scaling with Premium On-Demand, or committing to advanced features, Cube Cloud’s new offerings are here to provide seamless support and flexibility.

To explore more details on Cube Cloud’s updated pricing or to find the right plan for your team, visit our updated [Pricing page](https://cube.dev/pricing?utm_source=cube&utm_medium=blog&utm_content=pricing%20blog) or refer to our [product documentation](https://cube.dev/docs/product/deployment/cloud/pricing?utm_source=cube&utm_medium=blog&utm_content=pricing%20blog). If you have any questions, [contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=pricing%20blog) for personalized guidance. We’re excited to see what you’ll build with Cube!


Get More Flexibility with Updated Offerings for Cube Cloud


Recently, I’ve been reflecting on the parallels between the OLAP servers of the past and the modern vision of a universal semantic layer. To explore the similarities and differences between these two concepts, let’s take a journey through the history of OLAP servers, examining their inception and evolution.

## OLAP: There and Back Again
Back in the 80s and 90s, relational databases, also called Online Transaction Processing (OLTP) systems, were used for data management. They were designed to handle transactional workloads, but not analytical and multidimensional queries. This was mostly due to the row-oriented nature of storage and single-node architecture. That architecture was optimized for handling everyday transactional workloads—efficiently processing a high volume of short, simple transactions like inserts, updates, and deletes. However, it struggled with complex analytical queries that required scanning large datasets, performing aggregations, and executing intricate calculations.

__Online Analytical Processing (OLAP)__ emerged in the early 1990s to address these analytical processing needs. OLAP systems introduced multidimensional data structures known as "cubes," allowing data to be viewed and analyzed across multiple dimensions such as time, geography, and product categories. This multidimensional approach enabled businesses to perform complex queries swiftly, facilitating advanced data exploration techniques like slicing, dicing, drilling down, and pivoting. By pre-aggregating data and optimizing storage for read-heavy operations, OLAP systems significantly improved query performance and empowered organizations with deeper insights into their data.

![](https://ucarecdn.com/3dbabbe7-30ed-417d-88f5-16c35c2fea92/)

OLAP became a cornerstone of Business Intelligence (BI), with tools like Hyperion, Cognos, and Microsoft SQL Server Analysis Services (SSAS) leading the way. These systems enabled better decision-making and elevated the data analytics field significantly. 

To summarize, the inception of OLAP servers was due to the limitations of the OLTP systems and the need to provide two main functions: __analytics or multidimensional modeling and performance optimizations.__

But OLAP had its challenges. The in-memory architecture of OLAP servers was a double-edged sword. It enabled multi-dimensional structures that led to significant performance improvements but made it hard and very expensive to scale. Because of the RAM-based architecture, OLAP servers had to rely on vertical scaling, which has physical and economic limits. These limits became a bigger problem as the amount of data for analytical processing grew significantly. 

MPP databases and Hadoop emerged as alternatives by leveraging distributed computing and flexible data processing models. They scaled horizontally by adding more commodity servers, allowing them to handle more data efficiently. SQL on Hadoop and MPP databases paved the way for the emergence of cloud data warehouses (CDW). Following the success of SQL on Hadoop, CDWs embraced the SQL interface, adapted MPP architecture, optimized performance, and significantly simplified infrastructure management. 

A new generation of BI tools like Looker emerged to execute analytics on top of CDWs. Since CDWs are not suitable for multidimensional analytical modeling due to their tabular data structures, analytics modeling, which was previously done in the OLAP server, shifted to the BI layer, e.g. LookML in Looker, DAX in PowerBI.

While CDWs scaled more efficiently than RAM-based OLAP servers, they were not on par performance-wise, making additional performance optimizations a necessity. These optimizations hinge on __analytics modeling__, which provides context around the metrics, dimensions, and hierarchies involved, as well as how data is being queried, sliced, and diced. 

Without this context providing guidance on what to optimize, it is impossible to optimize at the CDW layer. 

Since this contextual information resides in the BI tool, BI vendors have started offering solutions that integrate analytics modeling with performance enhancements by incorporating in-memory OLAP servers inside their products and offering extract modes. Unlike direct or live connections, extracts work similarly to OLAP servers and move data from CDWs inside the BI tool in-memory engine. 

With __analytical modeling__, such as DAX in PowerBI, __and extracts__ now embedded in BI tools, the pendulum swings back toward the widespread adoption of OLAP servers—this time integrated directly within the BI platforms themselves.

That architecture works fine as long as the BI tool with the embedded OLAP server is the only consumer of the analytics models. However, once a new BI tool is added to the stack, the analytics modeling and in-memory aggregations will be duplicated to support that new tool.

For example, if an organization initially adopted Tableau on top of Snowflake, they might have built numerous calculations within Tableau’s calculated fields and used Hyper to extract data from Snowflake into Tableau. Later, the team decided to bring on Power BI to power dashboards for a new line of business. Now, analytics modeling needs to be done in DAX, alongside the existing calculated fields in Tableau. Moreover, the data itself is being duplicated multiple times: it resides in Snowflake, as the original source, and is also copied into both Tableau’s and Power BI’s in-memory engines. Data duplication inevitably leads to duplicated access control and security permissions across every environment where the data is stored.

In summary, embedding an OLAP server into the BI tool leads to the __duplication of analytics modeling, the data itself, and security permissions across all data and visualization tools__ used in the organization.

![](https://ucarecdn.com/54047caf-e14c-4738-824c-b75592bbb6f1/)

## Alternative Architecture
To avoid this duplication, we can extract OLAP server functionality, namely analytics modeling, and aggregations, from the BI layer and make it universal across all the data and visualization tools in the organization.

If we do this and make the analytics modeling and aggregations layer standalone, we will arrive at the next evolution phase of OLAP servers or the universal semantic layer idea.

![](https://ucarecdn.com/51dd6aa7-b40f-4057-819f-f84df83c28c4/)

While this architecture clearly offers the benefits from the analytics modeling and aggregations de-duplication perspective, the question around in-memory limitations remains open. Is there an alternative to in-memory aggregations for performance optimizations?

Additionally, decoupled architecture requires a communication protocol between BI and visualization tools and the standalone semantic layer. Historically, OLAP servers relied on MDX as the communication protocol. Is that still an option today, or do we need a better communication protocol?

I’ll dig deeper into these and other questions in future blog posts as I continue to explore the evolution of OLAP servers and the modern data stack.


The Evolution of OLAP

Learn how Cube D3 and agentic analytics accelerate insight-to-action cycles

Agentic Analytics

OLAP systems introduced multidimensional data structures known as "cubes," allowing data to be viewed and analyzed across multiple dimensions such as time, geography, and product categories.

Online Analytical Processing (OLAP)

Data pipelines, data modeling, and BI tools to collect, store, and analyze data at scale.

Agentic Analytics

Online Analytical Processing (OLAP)

Data Engineering

Application Development

All Things Cube