
Today we're launching Cube's **Claude Connector** in the Connectors Directory. Install it in Claude, sign in to Cube, and Claude can work across the platform with the same permissions you already have. It can analyze governed data, build dashboards, and make approved changes to the semantic model.

For a growing number of people, Claude is becoming the single entry point to knowledge work. They send instructions to Claude instead of signing in to each application and clicking through its interface. Claude finds and uses the tools it needs to complete the task.

Power users run tens of active Claude sessions at once, working across dozens of applications.

At Cube, the fastest-growing use case this year is agents working directly with the semantic layer on behalf of people. Most of that work is part of a larger task happening across several tools, so the agent needs to reach Cube from wherever the task is running.

We shipped the [Cube CLI](https://cube.dev/blog/power-of-cli) in July to give agents a direct, scriptable way to work with Cube from the terminal. Today, the official Claude Connector is available in the Connectors Directory, so Claude users can connect their Cube account without configuring an endpoint by hand.

## The semantic layer for agents

Agents are already good at writing SQL to explore data. A warehouse schema, however, doesn't tell them how your company defines revenue, whether refunds are included, or which of several date columns finance uses for reporting. The SQL can run successfully and still answer a different question.

We're focused on building the best infrastructure for agents to explore data, and we believe the semantic layer is the right abstraction for that work. In Cube, the agent queries named measures and dimensions instead of rebuilding business logic from table and column names. The definition of revenue, the joins behind it, and the applicable access policies all come from the semantic model.

The semantic layer also gives the work provenance and auditability. Teams can see which governed metrics the agent accessed and whose permissions applied. Claude uses the permissions of the person who connected it and doesn't need a separate warehouse credential.

We designed Cube's semantic layer to remain flexible at query time. With [Semantic SQL](https://cube.dev/blog/how-semantic-sql-works), an agent can add ad-hoc calculations on top of a governed data model instead of being limited to predefined measures. Those intermediate calculations let the agent complete more complex research and analysis without leaving the semantic layer.

## Installing the Claude Connector

Open the Connectors Directory in Claude, search for Cube, and click **Install**. Authorize with your Cube credentials and, if you belong to more than one Cube account, choose the one you want to connect.

If the account has multiple deployments, Claude can list them and select the deployment to use for each tool call. If you don't name one, it uses the default deployment selected by your administrator.

<video autoplay="true" muted loop playsinline="true" controls controlslist="nodownload" width="100%" preload="auto">
  <source src="https://ucarecdn.com/0cdfea46-1b91-447f-9a5c-6228f3edf35e/f01925a4-light.mp4" type="video/mp4" />
</video>

## Cube agent skills

Today we're also publishing **[Cube agent skills](https://github.com/cube-js/cube-agent-skills)**, an open-source repository of skills based on the Cube CLI we released in July. They give Claude Code a playbook for common Cube tasks: researching data, changing the data model, running queries, and operating Cube.

The open-source repository contains nine skills:

- **Explore and query.** Use `cube-explore-model` and `cube-explore-content` to find measures, joins, model files, workbooks, and reports. Run governed queries with `cube-run-query`.
- **Build.** Edit data models with `cube-build-model`. Create or update workbooks, reports, dashboards, and notifications with `cube-build-content`.
- **Operate.** Configure Cube's in-product agent with `cube-configure-agent`, manage access with `cube-admin`, handle embedded analytics with `cube-embed`, and manage deployments with `cube-deploy`.

The repository uses Apache 2.0, the same license as Cube Core. Install the skills in Claude Code with:

```bash
/plugin marketplace add cube-js/cube-agent-skills
/plugin install cube@cube
```

Before running, each skill checks that the CLI is installed and authenticated. If either check fails, it stops and returns the relevant installation or login command.

{/* VIDEO (walkthrough): Using the skills in Claude Code—install via the two
     plugin commands, then a prompt like "add a churn measure to the model and
     deploy it" that triggers cube-explore-model, then cube-build-model, showing
     the dev branch, validation, and deploy. ~90 seconds.
     Pattern: B (controls, with audio, poster frame from second 1).
     Notes: terminal only, no browser; use the ecom demo deployment; keep the
     skill activation lines visible in the transcript; target ≤ 20 MB. */}

## Get started

The Claude Connector is available in the Connectors Directory now. The [Cube agent skills repository](https://github.com/cube-js/cube-agent-skills) contains the source, installation commands, and documentation for all nine skills.


Artyom Keydunov

Product

Introducing Cube's Claude Connector and Skills


About a year ago I wrote that [AI can write your semantic layer](https://cube.dev/blog/cube-native-ai-bi-frontend) — read the tables in your warehouse, propose measures and dimensions, and keep building alongside you as the model grows. That's real, and Semantic Model Agent does it in Cube today.

Since then, software engineering has been moving through a clear progression: from one engineer supervising one agent, to orchestrating many agents that verify their own work, to supervised autonomy where agents continuously loop through entire classes of work in the background. The same shift is coming to analytics — and to semantic layers specifically.

## What changed in software engineering

As models get better, the bottleneck moves from instruction to iteration. More of the code is generated, which leaves verification to the human — and the human becomes the constraint. You prompt, the agent says it's done, you check it yourself and report what's wrong, and you do that a dozen times before it actually works.

So validation moves into the loop too: the agent writes the unit tests, runs the end-to-end suite, and checks its own work in the browser before handing anything over. It keeps going against a fixed spec until the checks pass.

The second constraint is memory. Long-horizon work exceeds a context window many times over, and prompting can't solve that — the state has to live in the environment rather than in the model. Anthropic's [write-up on harnesses for long-running agents](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents) describes the pattern: each session leaves artifacts behind for the next one — commits with real messages, a progress file, a list of what's done and what's still failing — and the next session starts by reading those and running the tests, so it picks up where the last one stopped instead of guessing.

## Signals from both directions

A semantic layer sits between the data and the people asking questions of it, and a loop around it needs signals from both sides.

Upstream, the foundation moves. A pipeline adds a column, a transformation changes grain, a source schema gets renamed, a nightly load lands a fact table with a row count it hasn't had in ninety days. Each of those is a signal that part of the semantic layer may now describe data that no longer exists in that shape.

Downstream, consumption tells you what the model is missing. Query patterns show which measures get used and which have been dead for a year. The questions people and agents ask — including the ones the agent had to answer with an ad-hoc calculation because no governed measure existed — are a direct list of what belongs in the model and isn't there. The artifacts built on top say the same thing from another angle: which dashboards exist, which are still opened, and which broke the last time a definition changed.

Together, these signals give the system enough context to propose a change, validate it, and continuously improve the semantic layer without someone opening a ticket first.

## What we're building at Cube

Designing agentic analytics loops is the core piece of our product roadmap right now, and I want to share some of the practical product changes and new features we're planning to release toward it.

## Agentic development environment

Cube was built on the idea of applying software engineering best practices to data management. The semantic layer was designed code-first and under version control from day zero, and that's what enables review, testing, CI/CD, and the rest of the practices that came out of software engineering.

Now software engineering itself is being redefined by agents. One of the biggest trends there is giving agents sandboxed infrastructure of their own: a place to write code, test it, and propose merges into production. Cube has always had development environments for users, alongside staging and production.

We're extending that with **environments for agent sessions**. It enables multiple concurrent agents working on the same data model in parallel — each creating artifacts, testing them, and proposing merges to production. It's also where the state lives between runs: the branch, the artifacts, and the results of the checks stay in the environment, so a long-horizon job picks up what the previous run left instead of starting from an empty context.

## Verification infrastructure

One reason agentic loops have been adopted so successfully in software engineering is that the verification infrastructure was already there, along with the practices built around it — everything from linting to testing to CI/CD checks. An agent can run all of it and find out whether its change is safe before a person ever looks at it.

At Cube we're investing in verification infrastructure for agentic analytics as well. We recently released [Cube Evals](https://cube.dev/blog/introducing-cube-evals), which benchmark the agent's answers against ground truth your team has written down, and we continue to improve them.

From there it's about expanding that surface and making it multi-layered. Cheap unit tests on the data model itself — does this measure return the right value at this grain, does this join fan out. And tests for the artifacts downstream of the model, since a report or a dashboard rests on definitions that can change underneath it and today nobody finds out until someone opens it. That would make verification infrastructure in analytics layered the same way it is in software engineering: unit tests on the model, checks on the artifacts built from it, and evals on the answers.

## Closing the loop

We already have [Agent Skills](https://cube.dev/blog/introducing-cube-agent-skills), [scheduled jobs](https://cube.dev/blog/cube-scheduled-tasks), and external [MCP Connectors](https://cube.dev/blog/introducing-mcp-connectors) (Model Context Protocol). Together with agentic development environments and verification infrastructure, these are the building blocks for designing data engineering loops.

A scheduled job can be triggered either by a schedule or by an external trigger — an upstream data model change, a dashboard error. The trigger spins up a new agentic development environment where agents address the issue, run the content validator, make sure everything is safe, and propose a pull request to get merged.

We recently added the [dbt integration](https://cube.dev/blog/introducing-dbt-integration), so the flow doesn't have to involve only Cube. dbt can be the source of the signal, and the agent can make changes to the dbt model when that's where the problem is.

Cube Agent already has access to query history, so it can run on a schedule to constantly optimize query performance, and to turn the ad-hoc calculations people write in Semantic SQL into governed measures. Once the primitives are in place and the integrations are connected, the use cases are limitless.

## Agent-centric product design

Business intelligence is a decision support system, and historically it has supported decisions made by humans — strategic and tactical. More and more of those decisions are going to be made by agents, and we already see it happening. Not all of them, but the majority of tactical ones will be made predominantly by agents. The next generation of BI needs to be a decision support system for agents and humans.

The pattern of how humans use BI changes too. Even when a human is making the decision, they'll rely on agents to prepare the materials and do the analysis, and they'll consume it in read-only mode. That means the key product primitives BI historically had need to change.

The high-level application surfaces have always been the data model editor, the workbook, and the dashboard, following the key functions of BI: modeling, exploration, presentation. Those functions aren't going away, but they're going to be [worked by agents](https://cube.dev/blog/building-bi-for-agents). So humans need a way to review the artifacts that work produces — data model code diffs, reports, insights, dashboards — and to review them in the context of a specific agent session, whether that's an interactive one a human triggered or a background long-horizon job triggered by an upstream signal.

That's why we're changing the hierarchy of primitives in Cube's product design and making the human-to-agent conversation a first-class object on the application surface.

We'll be shipping these pieces over the next few releases. If you're designing something similar, or you have a class of data engineering work you'd hand to a background agent tomorrow, [reach out](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=agentic%20loops%20blog) — those conversations are shaping what we build next.


Agentic Analytics

Agentic Analytics Loops


Today we are launching **Python analysis** in Cube.

A tab in a workbook has always been a query against the semantic layer—measures, dimensions, filters, joins, the definitions your team wrote and reviewed. That covers most of what gets asked for, and SQL reaches further than it often gets credit for: cohort grids, retention curves, running totals, period-over-period, top-N within segment.

Where SQL runs out is anywhere you need to fit a model rather than aggregate rows. A forecast with a confidence interval, a regression coefficient, a p-value from a significance test, customers clustered into segments nobody labeled in advance—none of that falls out of a `GROUP BY` at any length. Someone on your team is computing it anyway.

Where that work usually goes is a notebook. Somebody exports a CSV, fits a model on their laptop, and pastes the resulting chart into a deck. Two weeks later nobody can re-run it, and nobody can tell whether the revenue column in that CSV was the same revenue the dashboard next to it shows.

Python analysis keeps that work in Cube. You attach a script to a tab; the script's input is that tab's semantic SQL result, and the chart renders what the script returns instead of the raw rows. The forecast is computed on the same governed numbers as everything else in the workbook, and it's a saved object other people can open, re-run, and put on a dashboard.

<video autoplay="true" muted loop playsinline="true" controls controlslist="nodownload" width="100%" preload="auto">
  <source src="https://static.cube.dev/blog/2026/07/cube-python-analysis/python-analysis-demo-v2.mp4" type="video/mp4" />
</video>

## Ask for it in chat

The way most of these will get created is by asking. In Analytics Chat, "forecast next quarter's revenue" or "find anomalies in signups" runs Python and renders the result inline in the thread. Ask to save it to a workbook and Cube persists both the code and the run onto a tab.

The agent reaches for Python only when the answer genuinely needs a statistics or machine-learning library. Aggregations, top-N, ratios, running totals, period-over-period comparisons, and plain time series stay in SQL, because a Python run costs a re-query plus a sandbox start. If you ask for something you expected to be Python and get a normal SQL report back, that's usually the agent being right.

You can also start from the code. In a workbook, the tab menu has **Add Python**, which seeds a starter script and opens the code panel. In Explore, there's an **Add Python** button in the header—available on saved explorations, since Run executes server-persisted code and the script needs a report to live on. **Remove Python** detaches it and the tab goes back to plain SQL.

## Python runs on the query's output

The report's semantic SQL query runs first, and its result is what the script reads—it arrives as `data.csv` in the working directory. You add whatever processing you want on top of it, then write the rows you want charted to `output.json` as a flat JSON array of row objects. There's no Cube SDK to import and no decorator to learn.

```python
import pandas as pd
from prophet import Prophet

df = pd.read_csv("data.csv")
m = Prophet().fit(df.rename(columns={"month": "ds", "orders": "y"}))
forecast = m.predict(m.make_future_dataframe(periods=6, freq="MS"))

forecast[["ds", "yhat", "yhat_lower", "yhat_upper"]].to_json(
    "output.json", orient="records", date_format="iso"
)
```

What you write has to look like a table—a list of rows that all carry the same fields—because those rows are exactly what the chart plots. Anything nested needs flattening first. The sandbox comes with the major Python analysis libraries preinstalled, and we're adding more over time. The [docs](https://docs.cube.dev/docs/explore-analyze/workbooks/python-analysis) list what's available today.

![The Python code panel open above the tab's chart in a workbook, with the agent's summary of the Prophet forecast in the chat panel alongside](https://static.cube.dev/blog/2026/07/cube-python-analysis/code-panel-forecast.png)

The query and the script stay in one workbook tab—or one exploration—instead of living in two different tools. The semantic SQL that feeds the script sits right above it, so you can see what goes into the analysis—and change it—without leaving the report.

## Get started

Python analysis is available now. If you're already on Cube, open Analytics Chat and ask for a forecast on a metric your team already tracks—the [docs](https://docs.cube.dev/docs/explore-analyze/workbooks/python-analysis) cover how the script reads and writes, plus the workbook and Explore entry points. If you're new to Cube, [request a demo](https://cube.dev/request-demo?utm_source=cube&utm_medium=blog&utm_content=python%20analysis%20blog) and we'll show you the semantic model, the agent, and the analysis that sits on top of both.


Python Analysis in Cube


Today we're releasing the new **Cube CLI**: a single native binary, `cube`, that puts Cube's public REST API in the terminal. This post covers why we built a CLI in 2026, what it does, and a demo where one Claude Code prompt goes from a Postgres database to a deployed data model and a working React dashboard.

## Inception

In the beginning there was the command line. Neal Stephenson used that as the title of his [1999 essay](https://en.wikipedia.org/wiki/In_the_Beginning..._Was_the_Command_Line), but it's also just literally true. Before pixels there were characters: teletypes connected to time-sharing systems in the 1960s, then video terminals, then the Unix shell in the early 1970s with its one big idea that programs should read text, write text, and compose through pipes. Every interface paradigm since (windows, touch, voice) was supposed to replace it. None did. Half a century later, every serious piece of infrastructure still ships a CLI, and the ones that don't get one written by their users.

When AI agents started doing real work, the terminal is the interface they learned first, and that's not an accident. An LLM is a text model. A terminal session is text: the command is text, the output is text, the error message is text. There's no vision model in the loop, no pixel coordinates, no guessing which of three similarly-named buttons to click. The training corpus is saturated with shell transcripts, man pages, CI logs, and README installation sections, so models arrive already fluent. It's the same reason [agents are good at SQL](https://cube.dev/blog/how-semantic-sql-works): they've read millions of examples of it.

The CLI also happens to be a nearly ideal tool-use protocol. Commands are self-describing (`--help` is documentation the agent can read at run time), output can be requested as JSON, exit codes make success and failure unambiguous, and everything composes. When a command fails, the error comes back as text in the same channel, and the agent can read it and correct course on the next attempt. That tight feedback loop is exactly what agentic coding tools are built around, and it's why they live in the terminal rather than driving a browser.

So the interface that predates the GUI by two decades is also the native interface of the newest kind of user, and we don't expect that to change. Agent harnesses are terminal programs, CI runners execute shell scripts, and any capability we want agents to use reliably has to be exposed as text first. That's the assumption the new Cube CLI is built on.

## Enter the new Cube CLI

The new CLI is written in Rust and ships as one static binary per platform (TLS via rustls, so no OpenSSL dependency, and the Linux builds are fully static musl binaries). It lives in the open-source Cube repository under [`rust/cube-cli`](https://github.com/cube-js/cube/tree/master/rust/cube-cli), and you can watch it come together in the [recent commits](https://github.com/cube-js/cube/commits/master/rust/cube-cli): the initial CLI covering the public API landed in [#11289](https://github.com/cube-js/cube/pull/11289), followed by GitHub import, upload deploys, and self-update in [#11291](https://github.com/cube-js/cube/pull/11291).

Installation is one line on Linux and macOS:

```bash
curl -fsSL https://raw.githubusercontent.com/cube-js/cube/master/install-cli.sh | sh
```

And one line on Windows (PowerShell):

```powershell
irm https://raw.githubusercontent.com/cube-js/cube/master/install-cli.ps1 | iex
```

Authentication uses the OAuth 2.0 device flow ([RFC 8628](https://datatracker.ietf.org/doc/html/rfc8628)): `cube login` prints a URL and a short code, opens your browser, and waits for approval. Tokens auto-refresh, multiple tenants are supported as named contexts, and for CI you skip the browser entirely and pass an API key via `CUBE_API_KEY`.

The important design decision is that the CLI is a thin, complete client of Cube's public REST API. It doesn't scrape internal endpoints and it doesn't have private capabilities. Every endpoint of the public API is covered:

| Group | What it controls |
| --- | --- |
| `deployments`, `regions`, `logs` | Create, list, and manage deployments, generate API tokens, check build status, tail pod logs |
| `deploy` | Upload a local project directory: hash files, diff against the server, upload only what changed, trigger one build |
| `data-model` | Files, branches, dev mode, commits |
| `github` | Link a GitHub repo to a deployment and trigger builds from it |
| `variables`, `environments` | Environment variables and environment tokens |
| `workbooks`, `reports`, `folders`, `workspace`, `notifications` | The analytics surface: workbooks, reports, folder structure, notifications |
| `users`, `groups`, `attributes`, `policies`, `tenant`, `scim`, `oidc` | Access control, user attributes, resource policies, SCIM provisioning, SSO configuration |
| `embed`, `integrations`, `agents`, `app`, `meta` | Embed sessions and tenants, OAuth integrations, agents, app config, the metadata API |

The conventions are chosen for both kinds of users. Humans get tables, colors, and shell completions. Agents get `--json` on every list command, request bodies from a file or stdin with `-d @file.json`, deterministic exit codes, and `--help` text on every subcommand that doubles as the agent's documentation. `cube deploy` reimplements the legacy `cubejs deploy` flow on top of the public API: it hashes local files, diffs against the server, uploads only the changed ones inside a transaction, and triggers a single build. `cube deployments build-status` then reports the build state, including compile errors as text an agent can act on.

## The React e-commerce demo

To show what this unlocks, we gave Claude Code a Postgres database with a standard e-commerce schema (orders, line items, products, users) and this single prompt:

```markdown
Install Cube CLI curl -fsSL
https://raw.githubusercontent.com/cube-js/cube/master/install-cli.sh | sh,
login to d3-ai-demo.cubecloud.dev, create new deployment, connect it to
postgres demo-db.cube.dev, ecom db, cube / 12345. Create data model and
react dashboard app based on Cube APIs. Use Cube react client library.
```

<video autoplay="true" muted loop playsinline="true" controls controlslist="nodownload" width="100%" preload="auto">
  <source src="https://static.cube.dev/blog/2026/07/power-of-cli/cube-cli-linkedin.mp4" type="video/mp4" />
</video>

The agent worked through it the way an engineer would. It ran the install script, ran `cube login`, and paused while I approved the device code in the browser. The pause is deliberate: the agent never sees a password, and the credential it ends up with is a refreshable token stored in a local config file rather than something pasted into a prompt.

From there it was autonomous. It created a deployment, set the database connection through environment variables, read the Postgres schema, and wrote YAML cube definitions with joins between orders, line items, products, and users, and defined the measures the dashboard needed (revenue as a sum over line item totals, order counts, new user counts by month). It uploaded them with `cube deploy` and polled `build-status` until the build passed. When a build fails, `build-status` returns the compile error as text in the same output, so the agent reads it, fixes the model, and deploys again without a human copying error messages between windows. Then it generated an API token and scaffolded a React app with `@cubejs-client/react`, wiring its charts to the deployed data model.

The whole run took a few minutes, and my total contribution was one prompt and one browser click. None of the individual steps is novel. What's new is that every step is now reachable through one consistent, documented, text-based interface, so an agent can chain them without a human relaying state between a terminal and a browser tab.

## What's next

The direction from here is straightforward: everything you can control in the Cube UI is getting a public API first, and then a CLI command on top of it. The CLI and the API move together because the CLI is built on nothing but the public contract, which keeps us honest about what the API can actually do.

After an incubation period, we're going to release the full set of public APIs as a stable, documented surface for automation, so the same operations are available to CI pipelines, Terraform-style tooling, and whatever agents you run, with the CLI as the reference client.

To try it, run the install script above, then `cube login` and `cube --help`. The full command reference is in the [CLI documentation](https://docs.cube.dev/reference/cli), the source is in the [Cube repository](https://github.com/cube-js/cube/tree/master/rust/cube-cli), and we'd like to hear what you automate with it in the [community Slack](https://slack.cube.dev/?utm_source=cube&utm_medium=blog&utm_content=power%20of%20cli%20blog).


Pavel Tiunov

Engineering

Power of CLI


Today we are introducing the **dbt integration** in Cube.

The integration connects your existing dbt project to Cube and turns every dbt model into a governed cube in your [semantic layer](https://docs.cube.dev/docs/data-modeling/overview)—dimensions, measures, descriptions, and joins, generated from the modeling work your team has already done. You can run a pull manually, or put it on a schedule: trigger one from your CI pipeline or on every push to your dbt repo, and Cube regenerates the matching cubes and routes them to a reviewer before anything goes live.

We think about the data model as layers. Your dbt project is the bottom layer—tables, columns, and the tests that encode how they relate. The Cube data model sits on top of it, and that's where you define what dbt doesn't: more advanced metrics, the dimensions and joins people explore against, the semantics an AI agent needs to answer a question correctly. That upper layer builds on the foundation you already have in dbt instead of restating it.

The way the integration works is that it reads your dbt models and turns them into the foundational cubes in the Cube data model, and from there you can create and extend those cubes with all the advanced metrics on top. The sync regenerates those foundational cubes when needed.

## One direction to start

What we're shipping today is the first big piece: metrics sync one way, dbt → Cube. Cube clones your repo and reads it; it never writes back. dbt stays the source of truth for how your tables are transformed, and Cube governs the models on top of it—powering dashboards and analytics chat for your own team, embedded analytics for your customers, and the AI agents and APIs that query them. Nothing in your dbt repo changes, and the credentials you hand Cube only ever need read access.

The layered model is meant to run both ways. The fastest place to prototype a new metric or dimension is often the upper Cube layer—you define it there, iterate against real questions, and use it right away. Once it's proven, it may belong down in the dbt layer as part of the shared foundation, and we want to support that move too: promoting a definition from Cube back into dbt. Today's pull runs one way, dbt → Cube; that two-way flow is where we're taking it.

For now, the unit of translation is the dbt model. The integration doesn't import metric definitions, trigger a `dbt run`, or manage your transformations—it assumes your tables are built and generates the layer that makes them queryable.

## What a pull generates

When a pull runs, Cube clones your dbt repository into a short-lived, isolated sandbox, installs your project's dependencies, and runs `dbt parse` to produce the manifest—dbt's structured description of every model, column, test, and constraint. A pull never connects to your data warehouse—a line we drew deliberately: it reads your project's structure, not your data, and assumes the tables were already built by your own `dbt run`. That keeps a pull fast, and it means the integration can't touch production data.

![How the dbt integration works: dbt models flow from your repo through Cube, which parses the project and generates cubes on a reviewable branch](https://ucarecdn.com/9f5e6bbb-8aeb-471f-9901-bbf33a080ca4/)

From the manifest, each dbt model becomes one cube:

- **Columns become [dimensions](https://docs.cube.dev/docs/data-modeling/dimensions)**, with types mapped from the column data types.
- **Descriptions carry over.** The documentation you wrote on models and columns in dbt shows up on the generated cubes and fields.
- **Every cube gets a `count` [measure](https://docs.cube.dev/docs/data-modeling/measures)**, and numeric columns with additive names (`amount`, `total`, `price`) get `sum` measures.
- **Primary keys are detected** from `id` and `*_id` columns and marked on the matching dimensions.
- **dbt `relationships` tests and foreign-key constraints become [joins](https://docs.cube.dev/docs/data-modeling/joins)** between cubes—`many_to_one`, `one_to_many`, or `one_to_one`.

Because the joins come from relationships you've already encoded as tests, the generated model arrives pre-wired—you can query across cubes from the first pull without adding a single join by hand.

Generated cubes get configurable name and title prefixes (`dbt_` and `(dbt) ` by default) so they're easy to tell apart from hand-written ones, and you can scope a pull to your `marts` folder or a dbt selector like `tag:cube` instead of the whole project.

![A dbt model side by side with the cube generated from it, showing carried-over descriptions and a generated join](https://ucarecdn.com/85b8b807-10d2-472e-a66e-cd81f1642eae/)

## Automated sync

You can run a pull by hand: open the data model in dev mode, choose **Integrations → dbt → Pull**, review the generated cubes in the **Changes** view, merge. That's the right way to run your first pull. But a semantic layer that's synced only when someone remembers to sync it drifts just like a hand-written one, so the integration automates the same pipeline:

- **Trigger from your CI.** Cube exposes a REST endpoint you can call at the tail end of your dbt deployment job, right after `dbt run`. As soon as your warehouse tables are rebuilt, your pipeline tells Cube to regenerate the matching cubes. The endpoint URL for your deployment is shown in the dbt settings card, ready to drop into a CI step.
- **Trigger on every push.** Register a webhook on your dbt repository and Cube syncs whenever the tracked branch changes. Pushes are verified by signature, de-duplicated, and scoped to the branch you're syncing.
- **Review notifications.** When an automated sync produces changes, Cube emails the reviewers you nominate with a link straight to the review.
- **One saved configuration.** Output path, prefixes, model selection, join generation, and the rest now live on the integration, so every pull—manual or automated—uses the same settings. You also pick which branch of the dbt repo to sync.

Automated syncs never write to your live model. Each one lands on a fresh review branch, and a person approves the changes before they reach production. So when dbt changes overnight, the regenerated cubes are waiting on a review branch for someone to approve the next morning.

<video autoplay="true" muted loop playsinline="true" controls controlslist="nodownload" width="100%" preload="auto">
  <source src="https://ucarecdn.com/68f19617-cd79-4778-a381-4d1f0454ae77/4a20508d-dark.mp4" type="video/mp4" />
</video>

## Credentials and access

You connect Cube to your repo over HTTPS with a personal access token, or with an SSH deploy key—Cube generates the key pair and shows you the public half to register on your Git host; the private key is stored server-side and never leaves Cube. That makes the integration provider-agnostic: GitHub, GitLab, Bitbucket, Azure DevOps, and self-hosted Git servers all work, including orgs that mandate SSH deploy keys. Either way, the secret is stored encrypted and resolved server-side at pull time—your Git credentials never touch the browser. The sandbox that runs a pull is torn down after each run, along with the cloned files and any key material.

![The dbt project settings card on the Data Sources page, with the HTTPS / SSH authentication toggle and the generated public deploy key](https://ucarecdn.com/c4ac36a1-ec1f-417d-919b-0986176f39c6/)

## Getting started

The dbt integration works with Snowflake, Amazon Redshift, PostgreSQL, and Google BigQuery today.

If you're already on Cube: open **Settings → Data Sources**, fill in the **dbt project** card—repository, auth, project path, branch, and the schema your production dbt run builds into—and run a first pull from **Integrations → dbt → Pull**. Review the generated cubes, merge, then wire up the CI endpoint or the webhook and add reviewer emails so the semantic layer keeps up with dbt from there.

If you're not on Cube yet, [request a demo](https://cube.dev/request-demo?utm_source=cube&utm_medium=blog&utm_content=dbt%20integration%20blog) and we'll walk you through the dbt integration against your own project.


Mikhail Nitsenko

Introducing dbt Integration


When teams go looking for an open-source alternative to Looker, they usually start by comparing charting tools — which one draws the same dashboards, which one connects to the warehouse, which one is free to self-host. That was the right question a few years ago, and it's the wrong one now. The hard part of business intelligence was never the visualization. It was keeping everyone's numbers consistent, and getting answers to people without a two-week ticket queue. AI has moved the goalposts again: the question isn't only "can I self-host my dashboards," it's "can an agent answer a business question against governed data and get it right."

I want to walk through how I think about leaving Looker for open source today, because it looks different than it did when the standard advice was to bolt an open-source dashboard tool onto a metrics layer and call it a day.

## What the old open-source recipe gave away

For years, the way to escape Looker's per-seat pricing and LookML lock-in was a two-part stack: put an open-source semantic layer underneath to define your metrics, and point a separate open-source front-end like Superset at it to draw the charts. It worked, and it was a genuine step up from a proprietary black box — your metric definitions lived in code, in your repo, instead of inside Looker.

The problem is what that architecture gives away. The moment the analytics experience — the place people actually ask questions — lives in a different tool, the semantic layer becomes a component underneath someone else's product. You own the definitions but not the surface. Every improvement to how people interact with data has to happen in a front-end you don't control, and the governed model you worked hard to build is reduced to a data source it queries.

That was a tolerable trade when the front-end was "a dashboard." It's a bad trade now that the front-end is becoming an AI agent. An agent that constructs its own queries against ungoverned tables will confidently return numbers that don't match anyone's definition of the metric. The semantic layer isn't the thing you feed to the dashboard anymore. It's the thing that decides whether the agent can be trusted at all. Swapping Looker for Superset doesn't solve that — it just changes which front-end sits on top.

## Open source, at the foundation

**Cube Core** is the open-source semantic layer at the center of this. It's Apache 2.0, it's the original Cube project, and it does exactly what a semantic layer should: one governed definition of every metric, modeled in code, versioned in git, enforced no matter who — or what — is asking. Unlike LookML, those definitions aren't trapped inside a proprietary BI tool; you self-host Cube Core, you own it, and it sits on top of your warehouse rather than replacing it. Snowflake, BigQuery, Redshift, and Databricks stay where they are; Cube models the business logic on top and makes the same governed metrics available everywhere.

That open-source foundation is the part that doesn't change. What changed is what we built on top of it.

## From a component to a platform

**Cube** is the agentic analytics platform built on that semantic layer. Instead of handing your governed model to Looker — or to an open-source dashboard tool standing in for Looker — the analytics experience lives on top of the model directly:

- **Analytics Chat.** People ask questions in plain language and get answers grounded in the semantic model — the agent uses your team's definition of "active customer" instead of inventing one from column names.
- **Workbooks and dashboards.** The exploratory and reporting surfaces that used to require a second tool, sitting on the same governed definitions so a number means the same thing in a chat reply and a scheduled report.
- **A model that agents can reach.** The same governed layer is exposed to external agents over MCP, so an assistant in the tools your team already uses answers from the model rather than guessing against raw tables.

The through-line is that the semantic layer stopped being the product and became the reason the product's AI can be trusted. Your data team's governed definitions stay intact, and the agent constructs ad-hoc calculations on top of them at query time. That resolves the tradeoff every BI stack has always forced — lock everything down and nobody uses the tool, or open it up and end up with fifteen definitions of "churn." You get governed and flexible at the same time, which is the whole reason to put a real semantic layer underneath instead of treating it as a metrics API for Looker.

## The same foundation serves internal BI and embedded

One more thing both Looker and the open-source-dashboard recipe make hard: shipping analytics to your own customers. If your BI experience lives in a separate front-end, embedding it in your product means either iframing someone else's UI or rebuilding everything from the API — and Looker's embedded pricing turns that into a line item that scales with every customer you add.

Because the platform is built on the semantic layer rather than beside it, the same governed model powers both internal business intelligence and analytics embedded inside your product. Multi-tenancy, row-level security scoped to each customer, and query performance under load are part of the foundation, not a second integration project. One model, modeled once, serves the dashboards your data team uses on Monday and the analytics your customers see inside your app — governed the same way in both places.

## Where this leaves the open-source Looker question

The reason to leave Looker for open source was never just the license. It was ownership: of your metric definitions, of your data, of the tool your business runs on, without a per-seat meter or a black box you can't inspect. That reasoning holds. What's changed is that owning the semantic layer is now the high-leverage place to stand, because it's what determines whether the AI layer on top of it produces trustworthy answers. An open-source dashboard tool pointed at a metrics API gives you the license without the leverage.

So if you're evaluating the open-source route off Looker, I'd start from the model, not the charts. Cube Core is open source and stays that way; Cube is the platform that turns it into an AI-native analytics experience your team and your customers can actually rely on. You can self-host the core, model your metrics in code, and see how governed answers hold up against an agent's questions before you commit to anything.

Try it against your own data — [start with Cube](https://cube.dev/product?utm_source=cube&utm_medium=blog&utm_content=open%20source%20looker%20alternative%20blog), or read how the [semantic layer](https://cube.dev/use-cases/semantic-layer?utm_source=cube&utm_medium=blog&utm_content=open%20source%20looker%20alternative%20blog) fits the rest of your stack.


Looker

BI & Data Exploration

Data Engineering

The Open-Source Looker Alternative for the AI Era

Alexandr Romanenko

Query Latency in the Age of AI Agents


Everyone in data is talking about the context layer right now. a16z put a name on it in March with ["Your Data Agents Need Context"](https://a16z.com/your-data-agents-need-context/), and since then just about every data vendor has published a "context layer vs. semantic layer" take. The takes don't agree with each other, but the energy is real.

Cube Core is the largest standalone open-source semantic layer, so I keep getting some version of the same question: is the semantic layer old news now that there's a context layer?

My answer is no — and the "versus" framing is the wrong way to think about it. The context layer is real, and it's the superset: everything an agent needs to answer a business question correctly. The semantic layer sits inside it as the one part that actually executes.

## The context layer came from a real failure

Through 2024 and 2025, almost every company wired an LLM to its data warehouse and expected "chat with your data" to just work. Most of it didn't. What's interesting is why: it wasn't the models. Models write syntactically perfect SQL. The agent failed because it didn't know whether "revenue" meant gross or net, which of the three customer tables was the source of truth, or whether the person asking was even allowed to see the rows it was about to return.

That's a context problem, not a model problem. The industry has now mostly accepted this and named the missing piece the context layer. The name is right. But naming the problem is where a lot of the current takes stop being right.

## Most of what we call context is descriptive

Look at what usually gets listed under "context": catalogs, glossaries, ontologies, lineage graphs, freshness signals. All of it is useful, and all of it does the same kind of work — it tells the agent *about* the data. A catalog says this table exists and who owns it. A glossary says roughly what "active customer" means. An ontology says how a customer relates to an account and an order. Lineage says this number came from that pipeline.

None of it executes: nothing here produces an answer or enforces a rule. Hand an agent purely descriptive context and it still has to author its own SQL from a description, getting the joins and the grain right on every single query. What it produces is a confident guess with citations attached — and there's still no runtime enforcing a permission boundary between the agent and the data. Nothing stops it from returning a row the user was never allowed to see.

{/* DIAGRAM: Split panel, "descriptive vs. executable context."
     Left: descriptive context (catalog, glossary, lineage) → "tells the agent about the data" → agent still writes its own SQL, still guesses.
     Right: executable context (semantic layer) → "computes the governed answer + enforces access" → correct, permitted result.
     Context: sections above and below contrast description with execution.
     Notes: clean architecture-diagram style, no stock art. */}

## A semantic layer is executable context

A semantic layer is a different kind of thing. It isn't documentation of what revenue means — it's the governed, executable definition of it: measures, dimensions, joins, and access policies, defined once in code and computed consistently everywhere. When an agent works through a semantic layer, it doesn't read a description of revenue and reconstruct the SQL. It selects the certified `revenue` measure, and the layer compiles the exact query — with the user's row-level and role-based access rules already applied. Governance happens before the SQL exists, not as a filter someone hopes gets applied afterward.

In Cube, the interface for this is [Semantic SQL](https://cube.dev/blog/how-semantic-sql-works): regular SQL with one extension. Instead of improvising `SUM(CASE WHEN status = 'completed' THEN 1 END) / NULLIF(COUNT(*), 0)` and hoping the grouping level is right, the agent writes `MEASURE(completed_percentage)`, and the layer's rewrite engine expands the measure at the correct aggregation level, in the target warehouse's dialect, with the access rules compiled in. Models pick this up with minimal prompting because they already speak SQL fluently — we've seen agents that struggle to define a metric correctly from scratch use a certified measure reliably.

This is why I describe a semantic layer as **executable context**. Descriptive context helps an agent choose; executable context makes the chosen answer correct and permitted. It's the difference between an agent that knows what a term means and an agent whose answer you can put in front of a customer.

## Three kinds of context

An agent answering a business question draws on three kinds of context:

- **Executable context.** The semantic layer: metrics, dimensions, joins, and access policies. Computes the governed answer and enforces permissions when the query is compiled.
- **Descriptive context.** Everything that informs the agent without executing anything: catalogs, glossaries, ontologies, entity definitions, lineage — and the "why" that lives in docs, tickets, and tribal knowledge. Some of it is structured metadata, some is a paragraph in a wiki; either way it's read at query time (in Cube, over MCP (Model Context Protocol) Connectors) and helps the agent choose and explain.
- **Memory.** What was decided before and why — the exception that became precedent, the definition change that explains a break in a trend. Written as decisions happen, retrieved when they're relevant again.

An agent needs all three, and they compound — the context layer is the whole stack, not any one piece. But they aren't interchangeable: descriptive context and memory make an agent informed; executable context makes it correct and governed. You build the informed layers around an executable core, not the other way around.

## Where each piece belongs

If you've read any context-layer explainer, you've seen the checklist: semantic layer, entity resolution, policy enforcement, lineage, memory. You need all of it. The interesting question is where each piece belongs — and sorting them with the three kinds of context shows the semantic layer isn't one item on a checklist. It's the runtime the rest organize around.

**Policy enforcement → the executable core.** This one belongs inside the semantic layer, and it has to be deterministic. A rule the agent is merely told about in a prompt is a rule it can reason its way around. Enforcement has to be a property of how every query is built — row-level and role-based rules applied when the query compiles, before any SQL touches the warehouse.

**Entity resolution, ontologies, and business meaning → descriptive context, over MCP.** One consistent answer to "what is a customer" across the CRM, billing, and support systems is a real problem — and much of that business meaning doesn't live in the warehouse at all. It lives in ontologies, Notion pages, Google Docs, wikis, and tickets. Whether it's a formal ontology or a paragraph in a wiki, the right move is to pull it in over MCP at query time, not to pretend you can hand-model all of it into the layer up front.

**Lineage → split across the boundary.** There are two kinds, and conflating them is a mistake. Semantic lineage — how a metric is composed from other metrics and definitions — should absolutely be exposed to the consuming agent; it's part of understanding the answer. Physical table lineage — the full graph of underlying tables and transformations — is implementation detail. The agent *building* the semantic model needs it; the agent *consuming* data doesn't, and feeding it the full table graph adds noise and risk. This is David Parnas's [information hiding](https://en.wikipedia.org/wiki/Information_hiding) applied to data: expose the interface, hide the implementation. The semantic layer is that boundary.

{/* DIAGRAM: Information hiding for lineage. Two panels.
     Top/left: consuming agent sees the interface — metrics + semantic lineage (metric-built-from-metric).
     Bottom/right: behind the semantic-layer boundary, the physical table graph is hidden.
     Context: the lineage paragraph above; invokes Parnas — expose the interface, hide the implementation.
     Notes: most technical visual of the post; label the semantic-layer boundary explicitly. */}

**Memory → the agent harness.** A ledger of what was decided before and why belongs in the harness — the runtime scaffolding around the model. And the harness should be built around the semantic layer, because the semantic layer is the executable piece everything else coordinates through, not an accessory bolted onto the model afterward.

## One executable core, context assembled around it

Put together, the context layer has a shape — an agentic loop. At the center is the semantic layer: the executable, governed engine that turns a question into a correct, permitted answer. The agent harness is built around that engine. And the rest of the context — business meaning, tribal knowledge, docs, tickets — is assembled at runtime, mostly over MCP, exactly when the agent needs it. That's the architecture behind Cube's [AI Context Layer](https://cube.dev/product/ai-context-layer).

![The agentic analytics harness loop: the semantic layer, entities and ontology, and memory are each exposed to the agent as tools — the semantic layer is the one that executes](https://static.cube.dev/blog/2026/07/the-context-layer-needs-a-semantic-layer/agentic-analytics-harness-loop-v2.jpg)

In practice, each of these pieces is exposed to the agent as a set of tools. The semantic layer, the entity and ontology definitions, the memory of past runs — the agent reaches each of them over MCP as callable tools, not as a fixed pipeline. On every run it decides which tools to call and in what order: read the core business concepts from the entities doc, search the semantic layer's data model for the right measures and dimensions, pull any relevant memory from earlier runs, and then run a query against the semantic layer.

That last step is different in kind from the ones before it. Reading concepts, searching the model, retrieving memory — that's all context gathering. The query is execution: it's where a governed answer actually gets produced. Everything upstream helps the agent decide what to ask; only the semantic layer turns that decision into a correct, permitted result.

From there the agent can end the run or keep looping — investigating further, gathering more context, or taking action through tools that do more than read: build a dashboard, send an email, update a system of record. The semantic layer sits at the center of that loop as the one tool that executes.

Build all of it — catalogs, lineage, business rules, tribal knowledge. Just make sure the core is a real runtime. A semantic layer done right is code: version-controlled, tested, and served live over MCP to every agent that needs it. The "stale YAML nobody maintains" picture that shows up in some of the context-layer discourse describes a semantic layer someone built and abandoned — an implementation failure, not a property of the thing itself.

Two more convictions follow from the same root. First, a context layer that ships as a feature of a single BI tool wraps trust around a seat you're already locked into. Agentic analytics is a platform decision: the governed model should reach every agent you run — in a chat interface, in your own product, in Claude or ChatGPT over MCP — which is why we built Cube AI-native around the governed model rather than adding a chat box to a dashboard. Second, an agent answering business questions is a production system, and production systems have tests. Cube Evals exists so you can prove that a context or model change actually improved answer accuracy before it ships, instead of eyeballing outputs and hoping.

## The semantic layer, after AI

The semantic layer didn't get less important because of AI. AI is the reason it stopped being optional: agents surface every ambiguity a human analyst used to quietly resolve, at a volume no human review can absorb. When Brex built Spaces — the AI-powered financial reporting workspace embedded in their product — they evaluated Cube against other semantic layers and chose it because, as their team put it, "the semantic layer is what makes the AI useful." The agent understands what "spend" means at Brex because that meaning is encoded, computed, and governed in the layer — not guessed from column names.

If you're designing a context layer right now, start with the executable core and assemble the rest around it.


The Context Layer Needs a Semantic Layer


Today we are launching **Scheduled Tasks** in Cube.

When we shipped [Cube Agent Skills](https://cube.dev/blog/introducing-cube-agent-skills) last month, I ended that post with what we were building toward: the agent could run any workflow your team captured, but someone still had to ask—click the button, type the slash, start the chat. Scheduled Tasks remove that step. You save a natural-language prompt once, pick a cadence, and Cube runs it without being asked.

<video autoplay="true" muted loop playsinline="true" controls controlslist="nodownload" width="100%" preload="auto">
  <source src="https://static.cube.dev/blog/2026/07/cube-scheduled-tasks/create-with-agent.mp4" type="video/mp4" />
</video>

## A task is a prompt with a schedule

A scheduled task is a name, instructions, and a schedule. The instructions are the same kind of prompt you'd type into Analytics Chat:

> Summarize yesterday's signups, flag anything anomalous, and email me the results.

Attach a schedule—hourly, daily, weekly on a given day, monthly, or a raw cron expression if you want full control—set the timezone, and enable it. There's a "Run now" button, so you can test the instructions immediately instead of waiting for tomorrow's 9am run to find out the prompt needed one more sentence.

![New scheduled task dialog in Cube with name, instructions, a daily schedule with timezone, and an enabled toggle](https://static.cube.dev/blog/2026/07/cube-scheduled-tasks/new-task-dialog.png)

A run isn't limited to a single query, either. On each execution the agent can query the semantic model, search the web, create or update reports, workbooks, and dashboards, and email the results to members of your workspace.

## Every run is a chat thread

Each task run produces a chat thread marked with a clock icon in the Recent Chats sidebar. That makes it easy to ask follow-up questions about a scheduled run—when Monday's summary says signups dipped in one region, you don't forward the email and re-ask the question from scratch. You open that run's thread and ask why, and the agent picks up with the queries and reasoning from the run already in context.

## Tell the agent to schedule it

You can set a task up manually through a dialog, but the way I create them is by asking. "Create with agent" opens Analytics Chat, where the agent interviews you about what you want, drafts the instructions, and saves the task. And from any chat, you can ask the agent to schedule, update, list, or delete tasks in plain language—finish an analysis you like and tell it "run this every Monday at 8am and email me."

## It runs as you

Every task runs headless under the security context of the user who created it. A run sees exactly the data its creator can access—the same row-level security, the same access policies—and email recipients are limited to workspace members. There's no separate service account with broad permissions quietly generating reports.

And because the agent queries the semantic model, the numbers in Tuesday's run are computed the same way as Monday's, using your team's definition of "active user" rather than one improvised from column names each time.

One limitation in this first release: scheduled runs can't edit the data model. Changing the semantic layer stays in interactive chat for now.

## Skills on a schedule

This is the pairing I teased in the Agent Skills post. A task's instructions go to the same agent that runs your skills, so a task that invokes your team's weekly revenue report skill every Monday at 8am means the report is generated and waiting when people sign in—produced by the vetted, versioned workflow you wrote once, not a prompt someone re-types from memory.

## Get started

Scheduled Tasks are available now in Cube. If you're already a customer, open Analytics Chat and ask the agent to schedule something your team checks by hand every morning—or read the [docs](https://docs.cube.dev/docs/explore-analyze/scheduled-tasks) for the full setup. If you're new to Cube, [request a demo](https://cube.dev/request-demo?utm_source=cube&utm_medium=blog&utm_content=scheduled%20tasks%20blog) and we'll walk you through Agentic Analytics end to end, scheduled tasks included.


Scheduled Tasks

Igor Lukanin

Changelog

All Things Cube

Cube Core v1.7 — Tesseract GA, data modeling, performance


For as long as software has existed, the user has been a person. You log in, you open an interface, you follow some workflow to get a piece of work done. The hardware changed — mainframes, then personal computers, then cloud apps in a browser — but the shape stayed the same. A human sat down and did the work, with the software there to speed parts of it up.

That assumption is now breaking. The emerging user of software is an agent. Claude, Codex, and others are logging into the same tools and doing the same legwork a person used to do. The end result is often identical — a ticket gets filed, a report gets built, a decision gets made — but the path to it is walked by an agent, and it happens far faster than it used to.

Business intelligence is software, and the same shift is coming for it. So the question we've been sitting with at Cube is a simple one: what does a BI platform look like when its primary user is an agent?

## How BI actually works

To answer that, it helps to be precise about what BI is. Underneath the dashboards, BI is three connected workflows, and at any real scale each one has historically belonged to a different person — often a different team with a different skillset.

**Data modeling** is the technical foundation. A data engineer defines metrics, sets up relationships between tables, and prepares the views, cubes, and measures that everything else is built on. This is where the calculations and business logic live, encapsulated so they can be reused downstream.

**Exploration** is where a data analyst takes those modeled objects and looks for something worth knowing. They slice a specific cohort, apply filters, pivot, and view the data from different angles until an insight falls out — a number that takes the form of a report or a saved workbook sheet. Sometimes the model doesn't have what they need, so they either add a measure themselves or ask the modeling team to add it before they can continue.

**Presentation** is where those insights get assembled for an audience. An analyst combines reports into something shareable — usually a dashboard, with filters and time-grain switches so a broader group can explore within the story the dashboard is built to tell.

The artifacts that come out of these workflows — individual reports, or dashboards and data apps assembled from them — are what an organization actually runs on. A board reviews them to make a strategic call. An operator reads them to decide whether to reorder inventory, move stock between warehouses, or shift marketing spend. The three workflows exist to produce artifacts that someone — or something — can act on.

## The new user is an agent

Now look at what agents are already doing in other software. An agent can read a recorded customer call in a CRM, break it into the specific problems the customer raised, and open the matching tickets in Linear or Jira. Another can read positioning docs in Notion, run a competitive analysis, and pull the keywords for an ad campaign. In a single session it picks up several tools, does the work, and lands on the result.

The result of that work hasn't changed much — at least not yet. There are still tickets in Linear and Jira, records in the CRM, code changes as pull requests. What's changed is who does the work, and how: an agent did it, autonomously, in a fraction of the time, and the sequence of tools it picks up can look a lot like the one a person would. That pattern doesn't stop at CRMs and docs. It applies anywhere the work is "log into a tool, change some state, produce an artifact" — which is exactly what BI is.

## What that looks like in BI

Map the agent onto the three BI workflows and the trace is straightforward. Given a goal, an agent can:

- Update the ETL pipeline to bring in a new field.
- Update the transformation that shapes it.
- Update the semantic data model to expose it as a dimension or measure.
- Explore the model, slice it, and analyze it for insights.
- Assemble a dashboard and hand it to the humans for review.

That's the same path that has historically taken a whole team with different skillsets — data engineers, analysts — now compressed into a single session. And it can go a step further: with the insights from a report it just built, an agent can take the operational action directly — not just surface the recommendation but act on it.

This is where the artifacts earn their keep a second time. The report and the dashboard the agent produced along the way aren't just outputs; they're the audit trail. When you need to understand why an agent made a particular call, you have the full lineage — the model change, the exploration, the numbers it read — sitting there to inspect.

![An agent moving through the BI workflow — semantic model, exploration, and dashboards — leaving behind an audit trail of the objects it used, the queries it ran, and the artifacts it generated, then taking an action.](https://static.cube.dev/blog/2026/06/building-bi-for-agents/agent-bi-workflow.jpg)

## We don't need to build new roads

The encouraging part is that none of this requires reinventing BI. The infrastructure that made these workflows work for humans is the same infrastructure agents need:

- **Data model SDLC.** Branching, review, and CI/CD for changes to the semantic model, so an agent's edits go through the same controls a person's do.
- **Security and governance.** Permissions and row-level access that hold whether the query comes from a human or an agent.
- **Lineage and context.** A clear trace from raw data through transformations to the metric, plus the context an agent needs to know what a field actually means.
- **Content permissioning.** Controls over who — and which agent — can see and change a given report or dashboard.
- **Interconnected, drill-downable artifacts.** Reports and dashboards that link back to the model they came from, so a result is never a dead end.

That list is the semantic layer doing its job. It's also the thing that keeps agent-driven analytics honest. An agent left to infer definitions from column names will happily produce fifteen versions of "active customer." An agent working on top of a governed semantic layer uses the definition the data team already agreed on, which is what makes its answers trustworthy enough to act on — the same whether the analytics is for an internal team or shipped inside a product to customers. It's why we've always said the semantic layer is what makes the AI useful.

That doesn't mean there's nothing to improve. A new kind of actor, working at machine speed and volume, pushes on all of it — the interfaces, the performance, the guardrails — and there's real work to do there. But the fundamentals are in place. We don't have to build new roads for agents so much as open the existing ones to them, so an agent can make the same changes across modeling, exploration, and presentation that a person can, through the controls that are already there.

## How we're building it at Cube

In practice that comes down to programmatic access to the platform across all three workflows, and it's what we're prioritizing on the product roadmap. It takes a few concrete forms.

**More MCP tools.** Cube already runs a remote MCP server, so an agent like Claude or Codex can connect and query the semantic layer where it already works. We're widening that surface — adding tools for agents to create and manage the objects and content inside Cube, not just read from them.

**More API endpoints and an updated CLI.** The same operations, packaged so they can be scripted and called directly. An agent shouldn't have to drive a UI built for a mouse when it can call the action itself.

These are active priorities rather than a finished story, and we'll be honest about that as we ship. But the architecture underneath — the semantic layer, the governance, the lineage, the artifacts — is already real, and it's what makes the rest tractable.

## Where this goes

The shift from human users to agent users is the kind of platform change that rewrites software, and BI won't be an exception. We don't think the category disappears; we think it becomes something agents operate. Our goal at Cube is to let Codex, Claude, and the agents that come after them do the work a person does inside a BI tool today — model, explore, present — on top of a semantic layer that keeps the answers grounded.

If you're thinking about the same shift, [reach out](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=bi%20for%20agents%20blog) — we'd like to compare notes on what BI for agents should be.


Data

Building BI for Agents


Today we are launching **Cube Evals**.

Something changed this past year about what a data team is on the hook for. Questions that used to land in your queue—in Slack, in a ticket, as a "quick favor"—now go to an agent instead. People ask Cube's Analytics Chat, they ask through a copilot embedded in your product, they ask Claude or ChatGPT pointed at your Remote MCP server. The agent answers in seconds and the person moves on. That's the win. It's also the problem: the answer went out grounded in your data model, and you never saw it.

The only way to check whether those answers are right has been to read them—open the chat, eyeball the SQL, spot-check a number against something you trust. That catches almost nothing. You can't read every answer, you certainly can't read every answer a second time after you change a join or swap out a model, and "looked fine when I checked it last month" is not how you want to run the company's reporting.

## An agent in production is a production system

If an AI agent is answering business questions in production, it *is* a production system. And production systems have tests—a suite you run on every change that tells you, objectively, whether the thing still works. Not vibes, not a spot-check, not a good feeling about the demo. Your agent has never had that.

That's what Cube Evals is. You write **eval cases**—a natural-language question paired with its known-correct answer—and run your agent against them on any branch. You get back an objective accuracy score, like "86% (43/50)", and a per-case breakdown of which questions failed and why. Run it on `main` to see where you stand. Change a model or an agent config on a branch, re-run, and compare: did accuracy go up, or did you just introduce a regression you'd otherwise have shipped?

<video autoplay="true" muted loop playsinline="true" controls controlslist="nodownload" width="100%" preload="auto">
  <source src="https://static.cube.dev/blog/2026/06/introducing-cube-evals/evals-demo-v3.mp4" type="video/mp4" />
</video>

## How it works

An eval case lives in your data model repo as code. The easiest place to start is a single file, `agents/eval_questions.yml`: each case has a name, the question in plain English, and the ground truth—either inline SQL or a reference to a certified query you've already vetted. As the suite grows you can split it across `agents/eval_questions/*.yml`.

```yaml
# agents/eval_questions.yml
eval_questions:
  - name: revenue_by_quarter
    question: What was revenue by quarter over the last two years?
    certifiedQuery: revenue_by_quarter

  - name: completed_revenue_q4
    question: What was total completed revenue in Q4 2025?
    sql: |
      SELECT SUM(amount) AS revenue
      FROM orders
      WHERE status = 'completed'
        AND created_at >= '2025-10-01'
        AND created_at < '2026-01-01'
```

When you run a suite, Cube invokes **your own agent** on each question—the same agent, the same LLM provider, the same config that powers normal chat. Nothing new leaves your environment that wasn't already leaving it every time someone uses the agent. The agent produces a query. Cube executes both that query and your ground-truth query against your warehouse, through the same Cube API every other query goes through, and compares the two result sets.

When a case fails, you see the agent's SQL next to the ground-truth SQL, tagged with what went wrong—a row-count mismatch, a missing column, a value that's off—plus a plain-English read on it. That points you straight at the model definition or agent instruction that needs fixing.

## Grading is deterministic by default

No model grades the answer. Result sets are compared **deterministically**: sort-invariant, numeric-tolerant to four significant figures, and agnostic to column aliases. Cube checks the rows, not the prose.

We started with deterministic grading because I wanted a number you don't have to second-guess. The same eval run returns the same verdict every time, and when a case fails you can see exactly why: a row count that's off, a missing column, a value that doesn't match. So you can reproduce a result, show a failure to whoever owns the metric, and gate a merge on it in CI without anyone arguing about how the grader felt that day.

There's a real case for model-based grading too. It catches things a result comparison can't, like whether a written answer reads well or whether the agent picked a sensible chart, and we're looking at adding it as an option you can turn on. Deterministic grading stays the default, and you decide where a model check is worth the tradeoff.

## It lives where you already work

Evals run where you already do this kind of work: in the IDE, next to the model, scoped to a branch. They're part of **AI Studio**, the place in Cube where you tune and ship the agent—observe what it's doing, evaluate it against ground truth, improve the model, ship. Testing belongs in that loop, on a branch, in front of a code review—not in a separate console you remember to open once a quarter.

## Customers were already doing this by hand

We didn't guess at this one. Customers came to us already doing it the hard way—tracking eval questions and agent results by hand in spreadsheets, comparing runs manually after every change—and asked us, in so many words, for a Cube eval. When the people running an agent in production are building this for themselves out of a spreadsheet, the feature is already validated. We just made it native.

## Get started

Cube Evals are available now. The [docs](https://docs.cube.dev/admin/ai/evals) walk through authoring eval cases and running a suite. If you're already on Cube, open the **Evals** tab in AI Studio and add your first eval case. If you're new to Cube, [request a demo](https://cube.dev/request-demo?utm_source=cube&utm_medium=blog&utm_content=cube%20evals%20blog) and we'll show you the whole loop—model, agent, and the tests that keep it honest.

Introducing Cube Evals


Today we are introducing **MCP Connectors**, a way for the Cube agent to use tools from systems your team already works in—Notion, Linear, Sentry, your CRM—while it answers questions against your semantic layer.

When we shipped [Cube Agentic Analytics](https://cube.dev/blog/cube-agentic-analytics), every answer the agent gave was grounded in the measures, dimensions, joins, and access policies your team defined. That's the right foundation for "what are the numbers." But a lot of the questions people actually bring to a data tool reach past the numbers. *Why* did activation drop last week? What shipped right before it? What did the incident that bracketed it look like? The number tells you something moved; the reason usually lives in a ticket, a doc, or an error tracker, not in the warehouse.

MCP Connectors let the agent go get that context. Connectors are outbound integrations built on the **Model Context Protocol (MCP)**, an open standard for exposing tools to an AI agent. The agent reads the tools a connector makes available, decides from your request and each tool's description when one is relevant, and uses it in the same turn as a semantic-layer query.

<video autoplay="true" muted loop playsinline="true" controls controlslist="nodownload" width="100%" preload="auto">
  <source src="https://static.cube.dev/blog/2026/06/introducing-mcp-connectors/demo.mp4" type="video/mp4" />
</video>

## How a connector is set up

Connectors are organized in three layers, all managed by an administrator for the whole organization:

- **Connectors.** Each one is a connection to an external MCP server.
- **Tools.** The specific actions a connector exposes—search a workspace, create an issue, look up a record.
- **Availability.** You choose exactly which tools the agent is allowed to use. Nothing is enabled by default.

There are two ways to add one. A **directory connector** is a vetted integration: pick the service, complete OAuth or enter credentials, and turn on the specific tools you want. A **custom connector** points Cube at any remote MCP endpoint you run or trust: give it the HTTPS URL and an authentication method, and Cube discovers the tools so you can enable them selectively.

The directory launches with **Notion**, **Linear**, **Sentry**, and **Attio**, and we're adding more. For anything that isn't there yet, a custom connector connects any remote MCP endpoint today.

![The MCP Connectors directory in the Cube admin panel, showing the Notion, Linear, Sentry, and Attio connectors available to add](https://static.cube.dev/blog/2026/06/introducing-mcp-connectors/connectors-directory.png)

## It runs on the governed model, not around it

A connector widens what the agent can see, but it doesn't change what your numbers mean. When the agent reports revenue or active customers, those still come from the semantic layer, using your team's definitions and your access policies. The external tool supplies the surrounding context—the ticket, the doc, the error—and the agent reasons across both in one answer.

The same applies to permissions. When a tool needs authorization, the agent asks for it in chat before the tool runs, and it reaches a connected system through the credentials or OAuth grant you configured for that connector. The agent doesn't get a path around the access controls your team already manages.

## Across the whole agent workflow

The Cube agent does two kinds of work: it queries the semantic model, and it builds and changes it. Connectors help on both sides—pulling context in before the agent acts, and sending results out after.

- **Building the model with metadata you already have.** When the agent creates or extends the semantic model, it can read from the tools that already describe your data—a dbt project or a data catalog exposed over MCP—so a new cube or measure inherits the right descriptions, lineage, and naming instead of being guessed from column names.
- **Querying with the context only people wrote down.** The definitions that decide an answer often live in prose, not the warehouse—a Notion doc on how you define a "qualified lead," which markets count as EMEA, why last quarter came in the way it did. Pulling that in is the difference between a literal query and the one the person actually meant.
- **Turning the result into an artifact.** What the agent produces doesn't have to stay in chat. It can write a summary back to Notion, file a ticket, or post a recap, so the analysis lands where your team already works.

## What that looks like

A couple of requests that span the metrics and the work around them:

- *"Activation dropped last week—what changed?"* The agent reads the activation funnel from your model, then checks Linear for what shipped and Sentry for new errors in that window.
- *"Which enterprise accounts churned, and what did support hear from them?"* Governed churn metrics from the semantic layer, account records from your CRM, and the context from wherever those conversations happened.

This compounds with the rest of Agentic Analytics. Wrap one of these flows in an [agent skill](https://cube.dev/blog/introducing-cube-agent-skills) and it becomes a named routine anyone on the deployment can run the same way every time. And as we bring scheduled tasks online, pairing a skill with a schedule means the work runs without being asked—the Monday revenue recap pulls the week's numbers from your model, folds in the business context from Notion, and is written back there, waiting Monday morning.

## Get started

MCP Connectors are available now. An administrator adds a connector from the directory or points Cube at a custom MCP endpoint, authenticates, and enables the specific tools the agent should have. From there, anyone with chat access can ask questions that span both your metrics and the tools around them. The full setup is documented in [MCP Connectors](https://docs.cube.dev/admin/ai/mcp-connectors).

If you're new to Cube, [request a demo](https://cube.dev/request-demo?utm_source=cube&utm_medium=blog&utm_content=mcp%20connectors%20blog) and we'll walk you through the Agentic Analytics workflow, connectors included.


Introducing MCP Connectors


Today we are launching **Embedded Agentic Analytics** — a complete set of building blocks for embedding AI-first analytics into your product, all built on the Cube semantic layer.

Embedded analytics is not a new category. Hundreds of software companies already ship dashboards, charts, and reports inside their products to give their customers a way to work with data. What is new is what those customers now expect. After two years of using AI in everything else they touch, they expect to ask questions of their data in plain language and get useful answers, inside the same product they're already in. The teams that built embedded analytics two or three years ago are now looking at their stack and realizing it wasn't designed for any of this.

We've spent the past year building for that gap. Embedded Agentic Analytics is what we're shipping today.

## Why now

Embedded analytics used to mean dashboards. A vendor would offer chart components, a dashboarding UI, maybe a query builder, and you'd wire it into your product. That worked for a long time. The bar for what feels like a usable analytics experience has moved.

Customers don't want to learn another dashboard tool. They want to ask _"why is marketing 23% over budget this quarter?"_ and get an answer that's grounded in their actual data. They want their AI agents — the ones that already help them write code, draft emails, schedule meetings — to be able to answer questions about their numbers too. And they want all of that without leaving the product they're already paying for.

Most existing embedded analytics stacks treat AI as a feature to bolt on: a chat widget on top of a dashboard, a natural-language input on top of a query builder. Those work fine in a demo. In production they tend to produce confident, plausible-sounding answers that don't match how the business actually defines its metrics, because the underlying data layer was never designed to give an AI agent the context it needs to answer correctly.

If you ship embedded analytics today, your customers are already asking for this. The harder question is what infrastructure to build it on.

## The semantic layer is the foundation

Agentic analytics needs a context layer. Without one, an AI agent connected to a warehouse can write SQL that runs and returns numbers, but those numbers might not match how your business actually defines the metric. The agent has no idea that "spend" excludes refunds, that "active customer" requires a transaction in the last 90 days, that some departments roll up and others don't. It confidently produces results that are subtly wrong. Point an AI agent at a raw warehouse and most of what you get is wrong analytics, produced faster.

Give that same agent a semantic layer and it stops guessing. It answers the way a domain-specific analyst would — using your definition of spend, your rule for an active customer, the rollups your finance team actually uses — because those definitions are encoded where the agent can read them before it writes a single query.

The semantic layer is where that context lives. Measures, dimensions, joins, and access policies sit in one place, version-controlled, and any consumer of the data — a dashboard, a notebook, an embedded chart, an AI agent — uses the same definitions.

Semantic layers have been around for a while, and historically they've forced a tradeoff between governance and flexibility. Lock the model down so nothing breaks, and people stop using it. Open it up so people can extend it, and you end up with fifteen versions of "churn." Cube's approach is to keep the core model governed and let agents construct ad-hoc calculations on top of it at query time, in SQL. The agent stays inside the governed model while still having the flexibility to answer questions that weren't pre-built into it.

## We've been doing embedded analytics from day one

Cube started as a headless BI platform. The thesis was that the analytics layer — the part that defines metrics, runs queries, handles caching, and enforces access — should live separately from any specific UI. Build that layer well, and any number of UIs can sit on top of it: your own dashboards, your customer's dashboards, a chart in a Slack message, an AI agent in a chat box.

Thousands of companies have used Cube's APIs to build custom embedded analytics into their products. Some of the most sophisticated multi-tenant analytics experiences I've seen run on Cube. That work isn't going anywhere; the same Core Data APIs remain a first-class option in what we're announcing today.

What's changed is the surface area. APIs alone are no longer enough to ship a modern embedded analytics experience, because the experience now includes natural-language chat, AI-driven exploration, and agent-to-agent communication. So we're shipping a fuller set of building blocks alongside the APIs, all sharing the same semantic layer underneath.

## What we built

Embedded Agentic Analytics ships four embedding options. Pick the one that fits your team and your product, and move between them as you go — there's no lock-in across them, because they all run on the same semantic layer.

<iframe
  src="https://www.youtube.com/embed/fDJvTXsP3XU"
  title="Cube Embedded Agentic Analytics"
  width="800"
  height="450"
  allow="accelerometer; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
  allowFullScreen
></iframe>

- **Analytics Chat API.** A streaming API for building a fully custom analytics chat experience. You bring the UI; we handle the agent, the queries against the semantic layer, and the streaming of results. The same API supports agent-to-agent communication: other AI agents — your customer's coding assistant, sales assistant, or any LLM client speaking the **Model Context Protocol (MCP)**, the open standard for connecting agents to tools and data — can call your analytics agent and get a structured answer back. Best for teams that want full UX control or are building agent-to-agent workflows.
- **Chat and Dashboard iframes.** Drop-in embeds for analytics chat and dashboards. If you want to ship something to customers in days rather than months, this is the path. Theming, single sign-on, and access controls work out of the box.
- **Creator Mode.** Embed the full workbook and dashboard creation experience inside your product. Your customers don't only consume dashboards you built — they build and share their own, with the agent helping them along the way. This option is for teams that want their customers to do exploration, dashboard creation, and sharing entirely inside the product, without sending them to a separate BI tool.
- **Core Data APIs.** Direct access to the data layer — JSON, GraphQL, SQL. The same APIs Cube has shipped for years. For teams that want to build everything from scratch and just need a reliable, multi-tenant query layer with a semantic model behind it.

Because every option sits on the same semantic layer, you can start with iframes for a fast launch, move to the Analytics Chat API once you want a more custom UX, and bring in Creator Mode when you're ready to give customers their own building experience. You don't rebuild the data model when you change embedding options.

Multi-tenancy and caching apply across all four options. If you serve a thousand customers, the same model can be parameterized per tenant; pre-aggregations keep query latencies predictable as you scale. Both have been running production embedded workloads on Cube for years and apply equally to every new option above.

## Brex

Brex is a good example of what this looks like in production. They built **Spaces**, an AI-powered financial reporting workspace embedded inside the Brex product. Their finance customers ask questions like _"why is marketing 23% over budget this quarter?"_ and get answers in seconds, grounded in their own spend data.

<video autoplay="true" muted playsinline="true" controls controlslist="nodownload" width="100%" preload="auto">
  <source src="https://static.cube.dev/blog/2026/06/announcing-embedded-agentic-analytics/brex-spaces.mp4" type="video/mp4" />
</video>

Before writing any product code, the Brex team evaluated several semantic layer and embedded analytics options with one question front and center: which one is built for AI? They picked Cube because the semantic layer is what makes the agent useful. It encodes the financial domain — the rollups, the spend definitions, the policies that determine who can see what — so the agent reasons over a model that already knows the business, rather than guessing at column names in a warehouse.

The other half of the decision was operational. Spaces serves many Brex customers, which means multi-tenant architecture and production-scale caching aren't nice-to-haves; they're table stakes. Both are part of Cube already, and the Brex team didn't have to build either.

What the Brex team took away from the project — and what we hear from a lot of teams now — is that in agentic analytics, the semantic layer is a product feature. The context you encode into it is what makes the AI experience feel native to your product, instead of like a generic chatbot pointed at a database.

## Get started

Embedded Agentic Analytics is available now to all Cube customers. If you're already on Cube, you can try the new embedding options today; the [docs](https://docs.cube.dev/) walk through each path. If you're new to Cube and thinking about what AI looks like inside your product's analytics, [request a demo](https://cube.dev/request-demo?utm_source=cube&utm_medium=blog&utm_content=embedded%20agentic%20blog) and we'll go through the options that fit your stack.

We have more coming on this — deeper agent customization, more theming and brand controls, and additional A2A integrations. If you're shipping embedded analytics this year and any of those would change how you'd use this, tell us, and we'll factor it in.


Announcing Embedded Agentic Analytics


Today we are introducing **Cube Agent Skills**.

When we shipped [Cube Agentic Analytics](https://cube.dev/blog/cube-agentic-analytics), the bet was that the semantic layer could be the system of record for AI—every answer grounded in the measures, dimensions, joins, and access policies your team already defined. That works well for a one-off question. But the most valuable analysis in any company isn't a one-off. It's the report someone produces every Monday, the audit a data team runs the same way every quarter, the multi-step routine that lives in one person's head and gets re-typed as a long prompt every single time.

Skills are how you stop re-deriving that work. A skill captures a multi-step analytical workflow once, gives it a name, and lets anyone on the deployment run it—and get the same vetted result the author intended.

## A skill is markdown in your data model

The thing I like most about how this shipped is that there's nothing new to learn about *where* skills live. A skill is a markdown file in your Cube project, under `agents/skills/`, right next to the rules and certified queries you already manage as code. The frontmatter carries the metadata; the body is the instructions the agent follows.

```markdown
---
title: "Weekly revenue report"
description: "Use when the user asks for a weekly revenue summary or WoW trends."
---

Produce a weekly revenue report:

1. Pull revenue by week for the last 8 weeks
2. Compute week-over-week deltas
3. Call out the largest movers and a one-line summary
```

- **`title`** is the user-facing label—the button text in chat.
- **`description`** is what the agent matches a free-text request against when it decides to run a skill on its own.

The skill's name comes from the filename, so `weekly-revenue-report.md` becomes the `weekly-revenue-report` skill. You author it in the IDE, commit it, and ship it through the same dev-branch-to-master flow as everything else in your project. A skill on a dev branch is testable before it ever reaches production, and it inherits the governance you already have: code review, access policies, version history.

This is the part that's specific to Cube. A skill isn't an object you create in a separate admin UI and hope someone documented. It's data-model-as-code—reviewed, versioned, and deployed with the rest of the semantic layer.

## A few more skills

The weekly report is the obvious first skill, but because a skill is just instructions, almost any routine your team re-runs by hand can become one. You can run a skill from anywhere you work with the agent—Analytics Chat, a Workbook, the IDE—and what it produces is whatever its instructions describe: an analysis, a saved dashboard, even a change to the model itself.

A churn analysis pins down the definition of "churned" so every run returns the same cohort:

```markdown
---
title: "Customer churn analysis"
description: "Use when the user asks about customer churn, customer retention, customers who stopped buying, or inactive customer analysis."
---

Analyze customer churn:

1. Treat a customer as churned after 90 days with no order following a prior purchase
2. Break churn out by signup cohort and plan tier
3. Compare to the prior quarter and call out the biggest movers
```

The output doesn't have to be a chat answer—a skill can assemble and save a whole dashboard:

```markdown
---
title: "Revenue overview dashboard"
description: "Use when the user asks to build the standard revenue overview—MRR, new vs. expansion, and revenue by region—as a dashboard."
---

Build the revenue overview dashboard:

1. Add an MRR tile with a month-over-month sparkline
2. Add new vs. expansion vs. churned MRR as a stacked bar by month
3. Add revenue by region as a map and revenue by plan as a table
4. Lay the tiles out and save it as "Revenue overview"
```

And a skill can change the data model itself—this one captures how your team adds to it, so a new metric lands defined, tested, and reviewed the same way every time:

```markdown
---
title: "Add a metric to the model"
description: "Use when the user needs a new metric or measure defined in the data model and added to the right cube and views."
---

Add a new metric to the model:

1. Create a dev branch to work on
2. Find the right cube and check the measure isn't already defined—if it is, flag the duplicate instead of adding another
3. Add the measure with a clear name, title, and description
4. Include it in the relevant views
5. Run a short test query that confirms it returns the expected number
```

## Three ways to run one

A skill is only useful if people actually reach it, so we surfaced them in the three places a request tends to start:

- **Buttons.** The chat empty state shows one button per skill, labeled with its `title`. Click it and the workflow runs.
- **A slash menu.** Type `/` in the chat input to filter skills by title and description and pick one with the keyboard. When skills are available, the input hints "Type / for skills."
- **The agent picks it.** When a user's plain-language request matches a skill's `description`, the agent runs that skill on its own—no button, no slash. Skills work this way for both the agents you configure and the Auto agent that routes across them.

![The slash menu in Analytics Chat listing available agent skills, each with a title and description](https://static.cube.dev/blog/2026/06/introducing-cube-agent-skills/slash-menu.png)

## What's in v1, and what's next

This first release keeps the skill itself deliberately small: a `title`, a `description`, and an instruction body—no special syntax, no action API to learn. Every example above uses that same plain format. The only difference is what the agent does with it where it runs. That's enough to turn most repeated workflows into a shareable artifact.

What we left out is just as deliberate: per-skill data scoping, external actions that reach outside Cube (posting to Slack, hitting a webhook), parameterized inputs, and per-skill model selection. These are all directions we're looking at, but I'd rather ship the core well than ship parity with a feature list. If one of those would change how your team would use skills, tell us, and we'll weigh it for what comes next.

The bigger thing we're building toward is scheduled tasks. Today someone still has to reach for a skill—click the button, type the slash, ask the question. Pair a skill with a scheduled task and it runs on a set cadence without being asked, so the report someone produces every Monday is generated and waiting on Monday morning.

## Get started

Cube Agent Skills are available now. If you're already on Cube, add a markdown file under `agents/skills/` on a dev branch, commit it, and the button shows up in chat once it's deployed—start with a workflow your team already runs by hand. If you're new to Cube, [request a demo](https://cube.dev/request-demo?utm_source=cube&utm_medium=blog&utm_content=agent%20skills%20blog) and we'll walk you through the full Agentic Analytics workflow, skills included.


Introducing Cube Agent Skills

How Semantic SQL Works


We've made a lot of changes to our product in the last twelve months, and I think it's a good moment to step back and write about them. This post is partly a reflection on how we got here, and partly a way to share how I think about the future of both our open source project and our commercial product.

The semantic layer wasn't a new idea when we started Cube. It had always been part of business intelligence. Every BI tool of the previous generation, from SAP BusinessObjects to Cognos to Microsoft Analysis Services, had some form of semantic layer built into it. The job of that layer was the same in all of them: enable self-serve analysis and provide governance.

Data teams would model the data, define measures, dimensions, and joins, and organize everything into user-facing objects business consumers could understand — **universes** in BusinessObjects, **explores** in Looker, with variants of the same idea in every other tool. Those objects got published as the analytics artifacts the rest of the organization used to go point-and-click their way to insights.

When we started Cube in 2019, the first thing we wanted to do was move the semantic layer itself into code. The industry was already heading that direction. LookML was a code-first semantic layer within Looker, and dbt was making the case for transformations as code. Treating analytics infrastructure like software — version control, code review, CI — was on its way to becoming the default. Defining the semantic layer the same way fit naturally inside that shift.

The stack itself was also fragmenting. The bundled BI suite — one tool that owned warehouse access, modeling, and visualization in a single package — was giving way to a stack of specialized tools, and visualization in particular was exploding: charting libraries, dashboarding products, vertical analytics apps, embedded analytics inside SaaS products. A semantic layer tied to one BI tool wasn't going to hold up in that world, because every other tool downstream would end up needing its own copy of the model.

So we built Cube as a **standalone** semantic layer: the model defined in code, in one place, with any tool downstream consuming it through APIs. Because the semantic layer is fundamentally a BI building block, Cube ended up serving the two classic BI use cases from day one — embedded analytics and internal BI. We even called Cube "headless BI" on the homepage for a while to make the BI lineage explicit.

The open source project grew quickly, and in 2021 we built a commercial entity around it. The commercial product was the same headless BI, packaged with more features and an easier path to deploying and operating it at scale.

## The agentic moment

Fast-forward to the post-COVID years, and AI started reshaping every category of software. It became clear that the future of business intelligence is going to be **agentic**. The BI workflow is starting to look like a multiplayer game where humans and AI agents collaborate on different analytics tasks: building and testing data models, exploring data, finding insights, and packaging those insights into dashboards and apps.

In that agentic future, the semantic layer becomes more important, not less. The same governance and self-serve principles that the semantic layer brought to humans apply equally to agents. Agents need context to answer questions correctly — what "active customer" means in your business, how spend rolls up, which permissions apply to which rows — and that context lives in the semantic layer. Without it, an agent connected to a warehouse will write SQL that runs and returns numbers that don't match how your business actually defines its metrics.

That made us see a unique opportunity for Cube: build out the remaining parts of business intelligence and become the full platform. That's the journey we embarked on a year and a half ago, and by the end of last year we shipped the [first version of our agentic analytics platform](https://cube.dev/blog/cube-agentic-analytics).

So what started as one part of BI became the whole thing. That also gives us a clean frame for how we now think about the future of the open source project and the commercial product.

In short: **Cube Core remains open source**. It's the semantic layer piece of the full agentic analytics platform we call Cube, and it's what we run ourselves internally for the core semantic layer workload — data modeling, access control, caching, and the APIs that support all of it. **Cube** (the commercial cloud product) is the full-featured agentic analytics platform, built on top of Cube Core, and it's what you use when you want internal BI or customer-facing embedded analytics out of the box.

![Cube architecture: Cube (commercial) running on top of Cube Core (open source), with Cube Core also able to run standalone](https://static.cube.dev/blog/2026/05/cube-core-and-cube/architecture.jpg)

## Cube Core

Cube Core is largely unchanged in its purpose, and we keep adding features, improving performance, and tightening stability.

The biggest thing in flight is a Rust rewrite of the core engine, which we call **Tesseract**. Tesseract brings multi-stage data model support (period-over-period, percentage of total, running aggregates) and is also aimed at improving the performance of many Cube Core internals — SQL generation and data model compilation in particular. We've written separately about Tesseract and [how the new engine works](https://cube.dev/blog/introducing-next-generation-data-modeling-engine); we're nearing the completion of that rewrite.

The rest of the Cube Core roadmap is steady and focused on the foundations:

- **Data modeling.** New modeling primitives, better composition, faster compilation.
- **Access control.** More expressive row- and column-level policies, easier multi-tenancy.
- **Pre-aggregations.** Smarter matching, better refresh, broader engine coverage.

We're also investing heavily in the **SQL API**, which now supports HTTP transport, and we consider it the primary Cube Core API going forward. If you're starting a new project or evaluating Cube Core today, I'd recommend the SQL API over our older JSON-based REST API.

The reason is the expressiveness of SQL. Semantic layers have always had to balance governance and flexibility. Lock the model down too tight and every new dimension or measure becomes a ticket to the data team — that kills the self-serve part of the value. Open the model up and give consumers raw SQL to the warehouse and you lose the governance entirely. The right balance, as far as we can tell, is a semantic layer that supports ad-hoc extensions on top of the governed metrics. That's the design behind our Semantic SQL API: it's a Postgres-compatible interface where you can query measures and dimensions, and then build SQL-based calculations on top of those. You can compose new metrics inside a single query, and later, if they're useful, promote them into the data model. Consumers stay inside the governed layer while still being able to reach for the flexibility they need.

The JSON REST API doesn't have that. It's essentially a list of available measures and dimensions and a way to query them. We don't think it makes sense to re-implement a calculation language inside a JSON envelope, which is why we're pointing new development toward the SQL API. The older API isn't going anywhere; we're just not adding new capabilities to it.

Zooming out, the use cases for Cube Core are the same as they've always been: embedded analytics and BI.

Cube Core is a great fit when you need to build your own BI experience — a vertical, domain-specific BI tool where your value is in the domain and you want a proven semantic foundation underneath you instead of reimplementing one from scratch.

The other strong fit is deeply customized embedded analytics, especially when the integration has to live inside your product and your deployment topology is non-standard. A lot of our open source users have built impressive embedded experiences this way, and we'll continue to support that.

## Cube

Cube — the cloud product — is our fully featured agentic BI platform. We run Cube Core inside Cube and wrap all the higher-level features and the AI orchestration on top of it. Cube Core inside Cube is the same Cube Core that's open source. The data model is fully compatible both ways: you can take a model built in the cloud product and run it in your own Cube Core deployment, and vice versa.

If you want a quick tour of what's in Cube today, we recently ran a workshop walking through the agentic analytics workflow end to end:

<iframe
  src="https://www.youtube.com/embed/7ZQGGepDjUQ?list=PLtdXl_QTQjpY9q1FWOMKqD0jiQGhq_4u9"
  title="Cube agentic analytics workshop"
  width="800"
  height="450"
  allow="accelerometer; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
  allowFullScreen
></iframe>

Like Cube Core, Cube serves two primary use cases: internal analytics and customer-facing embedded analytics. The difference is that with Cube you get the full platform — the frontend, the integrations, the deployment automation, the AI orchestration — instead of just the semantic layer.

If you're looking for an internal BI platform that's modern, AI-native, and built on a strong open source foundation, that's what Cube is. We continue to invest heavily in the internal BI use case: AI-driven exploration, dashboarding, role-based access, integrations with the rest of the data stack. Given our history as a universal semantic layer, we also maintain strong integrations with other BI tools — Tableau, Power BI, and others. Most organizations don't standardize on a single BI tool, and we want Cube to be the layer that ties them together rather than forcing teams to pick.

We've also invested heavily in our Excel and Google Sheets integrations to support finance teams and anyone whose primary working environment is a spreadsheet. The semantic layer is what makes those integrations useful — the same definitions and access policies apply whether the user is in a dashboard, in a chat, or in a pivot table.

Finally, given how much of our customer base runs on embedded analytics, we're doubling down on that side of Cube as well. We're rolling out more ways to embed Cube into your product — from drop-in iframes to the underlying APIs, with options in between for teams that want something in the middle. Different products need different levels of control, and we want every level to be a first-class option.

If you're building a SaaS product and need embedded analytics, Cube Cloud is the path I'd recommend by default. You get the levels of customization you need, and we take on a lot of the operational complexity that comes with multi-tenant analytics at scale.

Cube Core is still a strong choice for embedded analytics if you're willing to invest engineering resources into building the analytics experience yourself, or if analytics _is_ the core value of your application — for example, if you're building a niche vertical BI tool. In those cases, owning the stack with Cube Core makes sense.

If your core expertise is elsewhere — like our customers at Brex, Webflow, and Deel — but you still need embedded analytics inside your product, Cube Cloud is the faster path. We take on the complexity, and you get to focus on your product.

## What's next

I'm excited about the future of both Cube Core and Cube. They're built around the same semantic layer, they share the same data model, and they each have a clear, valid use case. We'll keep investing in both.

If you have questions about which one fits your project, find me on [LinkedIn](https://www.linkedin.com/in/keydunov/) or come say hi in our [Slack community](https://slack.cube.dev/) — I'm always happy to talk with customers and the open source community.


The Future of Cube Core and Cube


Today we are introducing the **Cube Slack Agent**.

When we shipped [Analytics Chat](https://cube.dev/product/cube-d3) as part of [Cube Agentic Analytics](https://cube.dev/blog/cube-agentic-analytics) last year, the goal was to give every person in an organization a safe way to ask questions of the semantic layer in plain language. It worked well inside the Cube UI, but talking to customers it was clear that a lot of the analysis cycle actually happens in Slack — that's where the questions get asked, where screenshots get pasted, and where decisions get debated before anyone opens a dashboard.

So we brought the agent there. DM the Cube app, ask a question, get an answer in the thread.

![A Slack thread where the Cube app answers a question about top customers in California with a table of revenue by customer](https://static.cube.dev/blog/2026/04/introducing-cube-slack-agent/slack-thread-example.png)

## Same agent, same semantic layer

The Slack Agent is the same Analytics Chat agent that runs inside Cube, exposed through a different interface. It queries your semantic layer directly, so every answer uses the measures, dimensions, joins, and access controls your team already defined.

A general-purpose LLM pointed at your warehouse can produce a confident answer to almost any question, but it has no way to know whether the SQL it wrote matches how your business actually defines the metric. Grounding the agent in the semantic layer is what makes its answers reliable: it uses your team's definition of "active customer" or "ARR" rather than guessing one from column names.

## Threads map to Analytics Chat sessions

Each Slack thread is a real Analytics Chat session, just rendered in Slack. The first message starts the session; replies in the thread keep it going. You can drill in (_"split it by plan tier"_), narrow the window (_"just the last quarter"_), or change the view (_"show me the weekly trend instead"_), and the agent carries the previous turn's measure, filters, and breakdowns forward, so you don't have to re-set what you were already looking at.

The session is also visible in the Cube UI. If a Slack thread turns into something worth keeping, a data engineer can open the corresponding session in Cube to inspect the queries the agent ran, refine the analysis, or save the result to a workbook.

## Identity by email, permissions from Cube

The agent identifies the person asking by their Slack email and matches it to a Cube user. From that point on, every query the agent runs in the thread is executed with that user's permissions — the same row-level security and access policies you've already configured in Cube. There is no separate Slack-side access layer. If a user can't see a metric in Cube, asking the same question from Slack returns nothing either.

## Setup

A workspace admin connects Slack once from **Settings → Integrations → Slack** in Cube, picks the deployment to use, and selects the agent that should respond. After that, anyone in the Slack workspace whose email matches a Cube user can DM the app and start asking questions.

## Get started

The Slack Agent is available now on [Premium and above plans](https://cube.dev/pricing?utm_source=cube&utm_medium=blog&utm_content=slack%20agent%20blog). If you're already on Cube, an admin can enable it today from **Settings → Integrations → Slack** — see the [setup docs](https://docs.cube.dev/docs/integrations/slack) for step-by-step instructions. If you're new to Cube, [request a demo](https://cube.dev/request-demo?utm_source=cube&utm_medium=blog&utm_content=slack%20agent%20blog) and we'll walk you through the full Agentic Analytics workflow.

We're actively working on the next set of capabilities — in-channel mentions, multiple agents per workspace, and two-way sync between Cube and Slack. If any of those would change how your team uses this, tell us, and we'll factor that into what ships next.


Introducing the Cube Slack Agent


# Why semantic layers make LLM analytics reliable: a paired benchmark across three frontier models

If you've ever had an AI analytics tool confidently return the wrong number — the SQL ran, the rows came back, nothing looked broken, but the answer was wrong — you've seen the problem we set out to measure.

This is the most common failure mode in LLM-powered analytics, and it's not a model-quality problem. Switching from one frontier model to another doesn't fix it. The model is being asked to do a job it can't reliably do: translate a fuzzy human question into correct SQL against a database whose business definitions aren't written down anywhere it can see.

We argue that supplying those definitions — what we call a **semantic layer** — is the structural fix. Today we're releasing the research, the benchmark, and the dataset to back that up.

## What we tested

We ran a controlled, paired-comparison benchmark on 100 natural-language questions over the [Cleaned Contoso Retail Dataset](https://www.kaggle.com/datasets/bhanuthakurr/cleaned-contoso-dataset) loaded into ClickHouse. Three frontier LLMs — Claude Opus 4.7, Claude Sonnet 4.6, and GPT-5.4 — were each evaluated under two conditions:

- **Schema only.** The model receives the warehouse DDL and the question.
- **+ Semantic layer.** The model additionally receives a 4 KB hand-authored markdown document describing the dataset's measures, conventions, and disambiguation rules. No code, no runtime, no tool calls. Just the document, pasted into the prompt.

Same questions, same harness, same single-shot protocol, same reasoning effort, same judge across all six configurations. The only thing that changes between conditions is whether the markdown is present.

## What we found

**Adding the semantic layer improves accuracy by +17 to +23 percentage points across all three models.**

![Bar chart: semantic layer improves LLM analytics accuracy](https://lgo0ecceic.ucarecd.net/cf4cf9d1-1b0f-498d-bc06-b89280187615/)

| Model | Schema only | + Semantic layer | Δ |
|---|---|---|---|
| Claude Opus 4.7 | 50.5% [40.8, 60.1] | **67.7%** [58.0, 76.1] | **+17.2 pp** |
| Claude Sonnet 4.6 | 46.5% [37.0, 56.2] | **68.7%** [59.0, 77.0] | **+22.2 pp** |
| GPT-5.4 | 45.5% [36.0, 55.2] | **68.7%** [59.0, 77.0] | **+23.2 pp** |

All three paired improvements are statistically significant under two-sided exact McNemar (p ≤ 0.0015, n = 99).

The more interesting result is what happens *across* models. With the semantic layer present, the three models are statistically indistinguishable from one another (pairwise p ≥ 0.79). Without it, they are also indistinguishable (pairwise p ≥ 0.42). Every cross-cluster comparison is significant at p < 0.01.

In plain language: the presence or absence of the semantic-layer document accounts for essentially all of the significant variance in the benchmark. Model choice within tier does not.

## Why this matters

**The data model is the upper bound on AI quality.** The markdown we used was 4 KB — an afternoon of an analyst's time. But it has to capture what your metrics actually mean. If your team hasn't agreed on what revenue means, or CAC, or a qualified lead, no amount of model upgrading will produce correct answers.

**Treat this as an architecture decision, not a model choice.** With a semantic layer, you can pick whichever frontier model best fits your cost and latency budget without losing accuracy. Without one, switching to a stronger or more expensive model will not recover the gap. The gap is about the context, not the model.

This finding sits inside a consistent band of independent results, like BIRD's external-knowledge ablation (+20 pp), and the dbt Labs paired benchmark (+15 pp). Different domains, different teams; same direction.

## What we're releasing

- **The paper.** Full methodology, statistical analysis, and discussion: [https://arxiv.org/abs/2604.25149](https://arxiv.org/abs/2604.25149).
- **The benchmark.** 100 retail-analytics questions, reference SQL, and the semantic-layer markdown — at [https://github.com/cubedevinc/semantic-layer-benchmark](https://github.com/cubedevinc/semantic-layer-benchmark).
- **The dataset.** Public on [Kaggle](https://www.kaggle.com/datasets/bhanuthakurr/cleaned-contoso-dataset) — credit to Bhanu Thakur for the cleaned re-export of Microsoft's ContosoRetailDW.


Michael Rumiantsau

Why semantic layers make LLM analytics reliable: a paired benchmark across three frontier models


We're excited to share that Cube has been recognized as a Representative Vendor in the February 2026 Gartner Market Guide for Agentic Analytics.

## The semantic layer isn't optional
One of Gartner's key findings from the report: *"Semantic and policy alignment is foundational for effective agentic analytics. Ontologies, semantic layers and knowledge graphs provide the essential context that allows agents to generate relevant and reliable insights.”*

Gartner predicts, “by 2028, 60% of agentic analytics projects relying solely on MCP will fail due to the lack of a consistent semantic layer.”

This is the thesis Cube has been building toward. Every AI agent in our platform operates through a universal semantic layer: ensuring consistent business logic, hallucination-free SQL generation, and governed outputs across dashboards, conversational analytics, and embedded experiences. The semantic layer isn't an add-on. It's the reason the agents work.

## What's happening in the market

Established BI vendors are retrofitting AI onto legacy architectures. A new class of purpose-built platforms is emerging. And buyers are starting to ask harder questions about accuracy, governance, and what happens when agents scale.

Cube's seven-year foundation in semantic layer technology was built for exactly this moment.

## What's next

We're just getting started. We believe this recognition reinforces our conviction that agentic analytics are done right: governed, accurate, and grounded in consistent business logic. This is how data teams scale without chaos.

[Learn more about Cube's agentic analytics platform →](https://cube.dev/)

<small>*Gartner, Market Guide for Agentic Analytics, Deepak Seth, Georgia O'Callaghan, Fay Fei, Jeroen Cornelissen, 9 February 2026.*</small>

<small>*GARTNER is a trademark of Gartner, Inc. and/or its affiliates. Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.*</small>


News

Cube Recognized in the 2026 Gartner® Market Guide for Agentic Analytics


Recently, two vulnerabilities in Cube's WebSocket transport implementation have been discovered during an internal security audit. These vulnerabilities have been promptly patched. __Impacted deployments in Cube Cloud were secured.__

We're publishing this advisory to prompt Cube Core users to check the configuration of their Cube deployments and mitigate the potential security issue immediately.

Read below about the details, affected and fixed versions, and [required action](#required-action). 

## Impact

Vulnerabilities apply to Cube deployments:

* Running the versions __from 0.27.19 to 1.5.14__.
* Having the [WebSocket transport of the REST API](https://cube.dev/docs/product/apis-integrations/core-data-apis/rest-api#websocket-transport) __explicitly enabled__ by setting the `CUBEJS_WEB_SOCKETS` [environment variable](https://cube.dev/docs/product/configuration/reference/environment-variables#cubejs_web_sockets) to `true` (it is `false` by default).

Exploitation involves sending a specially crafted payload while authenticating with a valid API token. Exploiting the [first vulnerability](https://github.com/cube-js/cube/security/advisories/GHSA-v226-32c7-x2v7), CVSS-rated as High, allows privilege escalation. Exploiting the [second vulnerability](https://github.com/cube-js/cube/security/advisories/GHSA-9vph-2hvm-x66g), CVSS-rated as Moderate, allows executing a denial of service attack.

There is no evidence that these vulnerabilities were exploited in the wild.

## Affected and fixed versions

Deployments running the following versions of Cube are affected: from 0.27.19 to 1.5.14.

The vulnerabilities are resolved in the following versions of Cube:

- 1.6.0 and later (regular release)
- 1.5.15 and later (regular release)
- 1.4.2 (active [LTS release](https://cube.dev/docs/product/administration/distribution#long-term-support))
- 1.0.14 (end-of-life LTS release)

## Required action

**All Cube users are advised to immediately upgrade their deployments to versions 1.6.0, 1.5.15, 1.4.2, 1.0.14, or any later version.** 

Before upgrading, please check [product changelog entries](https://cube.dev/blog/category/changelog) for breaking changes. To upgrade a Cube Core deployment, use newer versions of [published Docker images](https://cube.dev/docs/product/administration/distribution#artifacts). To upgrade a Cube Cloud deployment, select a [newer version](https://cube.dev/docs/product/administration/deployment/deployments#update-channels) on the *Settings* page of your deployment and click *Apply*; this will trigger a redeploy.

Note that upgrading to a new major or minor version (e.g., from 1.2 to 1.5) will likely require some or all pre-aggregations to be rebuilt. Please plan the upgrade accordingly.

**Deployments in Cube Cloud have been secured.** Please contact Cube Cloud [customer success](https://cube.dev/docs/product/administration/deployment/support) if you have further questions.

Cube Core users are [notified](https://cube-js.slack.com/archives/CC0403RRR/p1770657415449029) via the Slack community at [slack.cube.dev](https://slack.cube.dev).

## Our commitment

Security is a priority for both Cube Core and our cloud platform. We're implementing a secure development lifecycle and strengthening our security controls. For more details, visit our [trust center](https://trust.cube.dev).


Dmitry Patsura

Security advisory: Vulnerabilities in WebSocket transport


We're kicking off 2026 with major improvements to dashboard filters, a new exploration mode, and AI-assisted data modeling that gets you from connection to first model in minutes instead of hours.

## AI-Assisted Onboarding

Getting started with Cube is now dramatically faster. The agent does the initial setup. You review, refine, and extend from there.

Connect your data warehouse and the Cube Agent analyzes your schema to automatically generate a starter semantic model with:

- Dimension and measure definitions
- Relationships between tables
- Cleaned-up naming conventions
- Common metric calculations

Once your model is set up, you can continue working with the Cube Semantic Model Agent to make changes conversationally ("add a new metric for average order price") rather than writing YAML directly.

Before finalizing the model, the agent verifies the updated definitions by querying the updated semantic model. You can then review a concise summary of these changes and test them within a workbook or the playground. You can always verify the logic being built by checking the semantic SQL.

[Watch the demo ->](https://www.youtube.com/watch?v=n-U1FvHqE2Q)

![AI modeling](https://static.cube.dev/blog/2026/whats-new-in-cube-january-2026-product-updates/cleanshot_2026-01-08_at_18.11.45_2x.png)

---

## Stateless Exploration

New "Explore" button in dashboards and the Analytics Chat opens any report in a modal window where you can:

- Ask follow-up questions in natural language
- Modify the visualization
- Customize the chart
- Save it as a new report if you find something useful

The exploration is stateless – experiment freely without cluttering your dashboards.

[Learn more about exploration →](https://cube.dev/docs/product/exploration/explore)

<video autoplay="true" loop muted playsinline="true" preload="auto">
  <source src="https://lgo0ecceic.ucarecd.net/edf19a6e-76ac-4b90-be9a-53fa68b0f704/" type="video/mp4" />
</video>

---

## Prompt Suggestions

Admins can now create a list of suggested prompts for each agent. These show up in Analytics Chat to help users discover what's possible with their data model. Useful for onboarding new team members or highlighting common analyses.

![chat suggestions](https://static.cube.dev/blog/2026/whats-new-in-cube-january-2026-product-updates/cleanshot_2026-01-12_at_12.46.42_2x.png)

## Other Improvements

- **Undo and redo in Workbooks and Explore:** now you can press cmd + z to undo or changes or press cmd + shift + z to redo your changes.
- **Custom filter dimension mapping**: Override automatic matching and choose specific dimensions for each widget
- **Granular widget control**: Enable or disable filter application on individual report widgets
- **Faceted filters:** limit filter suggestions based on the values selected in other active filters.
- **Row totals in pivot tables:** Pivot tables in both Result and Chart support row totals now.
- **Single value in dashboard filters:** You can now configure dashboard filter to accept only single value instead of multiple values.

---

## What's Next

These features are available now in Cube’s agentic analytics platform, and you can [sign up for free](https://cubecloud.dev/auth/signup).


What's New in Cube: January 2026 Product Updates


Cube Core version 1.6 is the [latest release](https://github.com/cube-js/cube/releases/tag/v1.6.0) to date.

The flagship feature of this release is the new, substantially upgraded and improved Cube Store, enabling the use of pre-aggregations for multi-stage calculations powered by Tesseract, Cube's next-generation data modeling engine.

**This release contains breaking changes.** [Cube Store upgrade](#breaking-cube-store-upgrade) as well as [strict validation of join paths in views](#breaking-strict-validation-of-join-paths-in-views) and [strict access policy matching](#breaking-strict-access-policy-matching) are breaking changes. Please read respective sections carefully.

Other notable changes include support for [precise decimals in Cube Store](#precise-decimals-in-cube-store) and [general availability of query pushdown](#important-general-availability-of-query-pushdown-in-the-sql-api) in the SQL API.

As always, we recommend testing the new version on a staging environment before deploying it to production.

## BREAKING: Cube Store upgrade

Cube Store is Cube's specialized, high-performance, columnar data store designed to accelerate query performance by leveraging [pre-aggregations](https://cube.dev/docs/product/caching#pre-aggregations). It makes use of well-established open-source technologies such as [Apache Parquet](https://parquet.apache.org) file format, [Apache Arrow](https://arrow.apache.org) memory format, and [Apache DataFusion](https://datafusion.apache.org) query engine.

With this release, we're completing a journey of upgrading Cube Store to DataFusion 46.0 from the previously used DataFusion 4.0 version with occasional cherry-picks. The reason for this upgrade is that DataFusion has evolved significantly, adding many new features and performance optimizations. For instance, this upgrade brings complete support for `DECIMAL` data type (fixed-point numbers with up to 38 digits) as well as query planning with [common-table expressions](https://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL#Common_table_expression) (CTEs).

We can't emphasize enough how important the last bit is, as CTEs are widely used by [Tesseract](https://cube.dev/blog/introducing-next-generation-data-modeling-engine), the next-generation data modeling engine, to implement [multi-stage calculations](https://cube.dev/docs/product/data-modeling/concepts/multi-stage-calculations). The upgraded Cube Store unlocks accelerating multi-stage measures with pre-aggregations, which was not possible before.

Now, when querying the data model from the [period-to-date calculations](https://cube.dev/docs/product/data-modeling/concepts/multi-stage-calculations#example-2) example, you can get and execute the following SQL query that uses pre-aggregations in Cube Store. Note multiple stages expressed as CTEs:

```sql
WITH time_series AS (
  SELECT to_timestamp('2025-01-01T00:00:00.000') date_from, to_timestamp('2025-03-31T23:59:59.999') date_to UNION ALL
  SELECT to_timestamp('2025-04-01T00:00:00.000') date_from, to_timestamp('2025-06-30T23:59:59.999') date_to UNION ALL
  SELECT to_timestamp('2025-07-01T00:00:00.000') date_from, to_timestamp('2025-09-30T23:59:59.999') date_to UNION ALL
  SELECT to_timestamp('2025-10-01T00:00:00.000') date_from, to_timestamp('2025-12-31T23:59:59.999') date_to
),
cte_1 AS (
  SELECT
    date_trunc('quarter', "prior_date__time_month") "prior_date__time_quarter",
    sum("prior_date__revenue_ytd") "prior_date__revenue_ytd"
  FROM prod_pre_aggregations.prior_date_main AS "prior_date__main"
  WHERE (
    CONVERT_TZ("prior_date__time_month", '+00:00') >= date_trunc('year',
      ( SELECT min("date_from") "value" FROM time_series )
    )
    AND CONVERT_TZ("prior_date__time_month", '+00:00') <= (
      SELECT max("date_to") "value" FROM time_series
    )
  )
  GROUP BY 1
  ORDER BY 1 ASC
),
cte_2 AS (
  SELECT
    "time_series"."date_from" "prior_date__time_quarter",
    sum("rolling_source"."prior_date__revenue_ytd") "prior_date__revenue_ytd"
  FROM
    time_series AS "time_series"
    LEFT JOIN cte_1 AS "rolling_source" ON "rolling_source"."prior_date__time_quarter" >= date_trunc('year', "time_series"."date_from") AND "rolling_source"."prior_date__time_quarter" <= "time_series"."date_to"
  GROUP BY 1
  ORDER BY 1 ASC
)
SELECT
  "fk_aggregate"."prior_date__time_quarter" "prior_date__time_quarter",
  "fk_aggregate"."prior_date__revenue_ytd" "prior_date__revenue_ytd"
FROM (
  SELECT * FROM cte_2 AS "cte_2"
) AS "fk_aggregate"
ORDER BY 1 ASC
```

Also, see the recipe for the [internal rate of return](https://cube.dev/docs/product/data-modeling/recipes/xirr) (XIRR) calculations, accelerated with pre-aggregations in the upgraded Cube Store. Here's the generated SQL query for multi-stage XIRR calculation in Cube Store:

```sql
WITH cte_0 AS (
  SELECT
    date_trunc('day', "payments__date_day") "payments__date_day",
    date_trunc('day', "payments__date_day") "payments__date_day",
    sum("payments__total_payments") "payments__total_payments"
  FROM prod_pre_aggregations.payments_main_xirr AS "payments__main_xirr"
  GROUP BY 1, 2
  ORDER BY 1 ASC, 2 ASC
),
cte_1 AS (
  SELECT
    "fk_aggregate"."payments__date_day" "payments__date_day",
    XIRR(
      "fk_aggregate"."payments__total_payments",
      "fk_aggregate"."payments__date_day"
    ) "payments__xirr"
  FROM (
    SELECT * FROM cte_0 AS "cte_0"
  ) AS "fk_aggregate"
  GROUP BY 1
  ORDER BY 1 ASC
)
SELECT
  "fk_aggregate"."payments__date_day" "payments__date_day",
  "fk_aggregate"."payments__xirr" "payments__xirr"
FROM (
  SELECT * FROM cte_1 AS "cte_1"
) AS "fk_aggregate"
ORDER BY 1 ASC
```

Using the upgraded Cube Store with Tesseract in the fashion shown above would require setting to `true` the following environment variables: `CUBEJS_TESSERACT_SQL_PLANNER`, `CUBEJS_TESSERACT_PRE_AGGREGATIONS`, `CUBEJS_CUBESTORE_ROLLING_WINDOW_JOIN`.

**Upgrade considerations.** Due to changes in the data types and storage format, the upgraded Cube Store builds pre-aggregation partitions that are not compatible with the previous Cube Store version. The upgraded Cube Store is able to read pre-aggregation partitions created by the previous Cube Store version, so only newly created partitions will use the new format. However, in some cases, the existing partitions might need to be rebuilt from scratch. Please keep this in mind when planning and executing the upgrade.

**Upgrade considerations for Cube Cloud users.** In Cube Cloud, all deployments will continue using the previous version of Cube Store while we're gradually rolling out the new Cube Store over the coming weeks. If you'd like to switch to the new Cube Store now, please contact the customer success team.

**Please report any issues you encounter with the upgraded Cube Store on [GitHub](https://github.com/cube-js/cube/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22cube%20store%22) and in the [Slack community](https://slack.cube.dev/).** We're really looking forward to your feedback and we'll be helping to get the issues resolved.

## Precise decimals in Cube Store

Previously, Cube Store only supported up to 16 digits of precision for decimal numbers, while the upgraded Cube Store in this release can now handle up to 38 digits of precision, aligning with the capabilities of many [modern databases](https://docs.snowflake.com/en/sql-reference/data-types-numeric).

So, this release introduces a new environment variable, [`CUBEJS_DB_PRECISE_DECIMAL_IN_CUBESTORE`](https://cube.dev/docs/product/configuration/reference/environment-variables#cubejs_db_precise_decimal_in_cubestore) (set to `false` by default), which controls how decimal columns are handled when exporting data from a data source to Cube Store. If this environment variable is turned on, when data is exported from a data source to Cube Store, decimal columns maintain their precision and scale specifications (e.g., `DECIMAL(10, 2)`) rather than being converted to a generic decimal type.

**Upgrade considerations.** Enabling precise decimals may require that existing pre-aggregation partitions are rebuilt from scratch. That is only going to happen if the columns in the underlying data source use decimal types with precision and scale specifications.

## BREAKING: Strict validation of join paths

[Join paths](https://cube.dev/docs/product/data-modeling/concepts/working-with-joins#join-paths) serve as a mechanism to remove the ambiguity of joins in the data model. When join paths are used in views, it's important to define them in a non-ambiguous manner to ensure that Cube can generate correct SQL queries.

Previously, Cube allowed to have the following set of join paths in the same view: `orders.locations` and `orders.customers.locations`. _Allowed_ here means that Cube would not raise an error during the data model compilation. However, such definitions are not sound since Cube would _only reference a single cube once in the generated SQL query_, e.g., `... FROM orders LEFT JOIN customers ... LEFT JOIN locations ...`, making it impossible to follow both join paths simultaneously. Ultimately, this can lead to getting incorrect query results without any indication of an issue. 

To prevent this from happening, now we've introduced strict validation of join paths in views. Data model compilation will fail with the following error if ambiguous join paths are detected: `Views can't define multiple join paths to the same cube. View 'order_info' has multiple paths to 'locations': 'orders.locations', 'orders.customers.locations'. Use extends to create a child cube and reference it instead`.

Please see the [test cases](https://github.com/cube-js/cube/pull/10264/files#diff-f43ae05673b555fc1e5cd641a7605ada68f0c4ea42d437207b397f97a1ce4d71) to learn more.

**Upgrade considerations.** If your data model contains unsound join paths in views, you will need to refactor it to eliminate the ambiguity. Currently, the recommended way to do so is by _aliasing_ cubes such as `location` above through creating a child cube using the [`extends` parameter](https://cube.dev/docs/product/data-modeling/reference/cube#extends). Then, you can reference the child cube in the join paths.

Going forward, we plan to support [join aliases](https://github.com/cube-js/cube/issues/10265) to eliminate the need for creating child cubes in such cases.

## BREAKING: Strict access policy matching

[Access policies](https://cube.dev/docs/product/auth/data-access-policies) serve as a way to define member-level and row-level access controls declaratively in the data model.

Previously, all access policies that match the request were combined together, _independently_ for member-level and row-level policies. Subsequently, combining multiple access policies with different sets of members could lead to a counter-intuitive outcome, when policies would expand the row-level access for non-overlapping members.

![](https://ucarecdn.com/d52b2408-0df6-42d3-a5eb-a24a1ee54109/)

To reduce confusion when using access policies, we've updated the access policy matching to apply and combine only policies that include _all members from the query_. As the result, the row-level access would not expand in a counter-intuitive manner. However, it also means that if a query contains members that are not _fully covered_ by any access policy, the query will return no data.

![](https://ucarecdn.com/b1fd9feb-7700-4392-8a7d-3a3154fb14af/)

See a [few examples](https://github.com/cube-js/cube/pull/10257/files#diff-34f766fe8eb9e519aeb939a10425b6928c4bfa5965337baa66a0cd54a24ad259R559-R647) to learn more.

**Upgrade considerations.** Review your access policies to ensure that they fully cover the members used in queries. Consider comparing the query results before and after the upgrade (in a production and a staging environment) to identify any discrepancies.

## IMPORTANT: General availability of query pushdown in the SQL API

With this release, [query pushdown](https://cube.dev/docs/product/apis-integrations/core-data-apis/sql-api#fundamentals) in the SQL API leaves the public preview and is now generally available. Since it was [enabled by default in v1.0](https://cube.dev/blog/cube-core-v1-0-query-pushdown-in-the-sql-api-by-default), it has proven to be a stable and important feature that significantly expands the capabilities of the SQL API.

## DEPRECATED: Elasticsearch driver

The Elasticsearch driver is deprecated and will be removed in a future release.

Due to the non-relational nature of Elasticsearch, the driver has amassed a number of [standing issues](https://github.com/cube-js/cube/issues?q=is%3Aissue%20state%3Aopen%20label%3Adriver%3Aelasticsearch) over time while still having very limited adoption as any production usage of it is hardly justified given known limitations.

## New in configuration

### New `CUBEJS_DEFAULT_TIMEZONE` environment variable

This new environment variable allows to specify the default [time zone for queries](https://cube.dev/docs/product/apis-integrations/queries#time-zone), used when no timezone is specified in queries. By default, it is set to `UTC`. It can be useful for cases whem the majority of queries are expected to use a specific time zone, e.g., all your users are sharing the same time zone and you want to avoid specifying it in every query.

## New in APIs and client libraries

### Query timezone in `/cubesql` API endpoint

Similarly to the [`/load` endpoint](https://cube.dev/docs/product/apis-integrations/rest-api/reference#base_pathv1load) of the REST API, the [`/cubesql` endpoint](https://cube.dev/docs/product/apis-integrations/rest-api/reference#base_pathv1cubesql) of the SQL API now supports the `timezone` parameter that allows to specify the time zone for a query. It can be useful for cases whem queries come from users located in different time zones.

### `lastRefreshTime` in `/cubesql` API response

Now the [`/cubesql` endpoint](https://cube.dev/docs/product/apis-integrations/rest-api/reference#base_pathv1cubesql) of the SQL API includes the `lastRefreshTime` field in its response. This field indicates the timestamp of the last cache refresh for the result set. This comes as a handy follow-up for the `cache` parameter support added in v1.5.0, allowing clients to specify [cache control](https://cube.dev/docs/product/apis-integrations/core-data-apis/rest-api#cache-control) for queries.

### `baseRequestId` in the JavaScript SDK

The new [`baseRequestId` parameter](https://cube.dev/docs/product/apis-integrations/javascript-sdk/reference/cubejs-client-core#loadmethodoptions) was added to the methods of the [JavaScript SDK](https://cube.dev/docs/product/apis-integrations/javascript-sdk). It allows to specify a base request ID ([`spanId`](https://cube.dev/docs/product/apis-integrations/core-data-apis/rest-api#request-span-annotation)) to be explicitly provided for the request. Might be useful when you'd like to use the same request ID across multiple requests for easier tracing and correlation. If not provided, a random request ID will be generated as before.

### `@cubejs-client/vue` package discontinued

Version 2 of the Vue front-end framework has reached its End of Life (EOL). Consequently, the client library for this version of Vue has been deprecated and will not receive further updates. We highly recommend upgrading to `@cubejs-client/vue3`, supporting Vue 3.

## New in data sources

### New default renewal threshold for Firebolt

By default, Cube uses 2-minute [refresh keys](https://cube.dev/docs/product/caching#default-refresh-keys) for all data warehouses. We've aligned [Firebolt](https://cube.dev/docs/product/configuration/data-sources/firebolt) with others by setting its default refresh key to 2 minutes as well.

## Perfomance optimizations

A lot of effort was put into further improving the performance of the data model compilation and reducing its memory footprint, especially in multi-tenant environments. On top of that, the API instance startup time was improved by lazy-loading vendor SDKs when needed, e.g., for AWS, GCP, Azure. Finally, the query planning performance in the SQL API has been significantly improved for cubes/views with many members.

## What’s next?

We're looking forward to your feedback on the upgraded Cube Store and other features in this release! Please join our [Slack community](https://slack.cube.dev/) to share your thoughts and ask questions.

We're hoping to bring the next release soon, focusing on Tesseract.

Don't hesitate to try the new release in our managed [cloud offering](https://cube.dev/cloud), which comes with a handy free plan.


Cube Core v1.6 — Cube Store upgrade, multi-stage pre-aggregations


This fall, we're excited to introduce powerful new capabilities that transform how you build your data models, share insights, and interact with your data. Here's what's new.

## 🤖 AI Widget: Your Dashboard Storyteller

Dashboards shouldn't just show data—they should tell you what it means. The **AI Widget** generates summaries and insights directly on your dashboards. It uses natural language to explain what your data shows and suggests next steps.

**What you can do:**

- Add AI-powered narrative widgets to any dashboard with a single click
- Get quick summaries of dashboard content in natural language
- Receive actionable insights and recommendations based on your metrics
- Customize prompts to focus on specific business questions
- Generate fresh narratives as your data updates

The AI Widget leverages Cube's semantic layer to ensure every insight is grounded in your governed data definitions—no hallucinations, just accurate analysis you can trust.

<video autoplay="true" loop muted playsinline="true" preload="auto">
  <source src="https://static.cube.dev/blog/2025/whats-new-in-cube-october-2025-product-updates/ai-widget.mp4" type="video/mp4" />
</video>

---

## 🌐 Dashboard Embedding: Analytics Everywhere

You can now embed dashboards into other tools and applications via iframe. This lets you share analytics across your organization while maintaining security and governance through the semantic layer.

**What's new:**

- Embed complete dashboards via iframe with full interactivity
- Maintain security and governance through your semantic layer
- Provide consistent metrics across all embedded analytics
- Enable self-service insights without leaving existing tools

Whether you're building internal portals, customer-facing applications, or collaborative workspaces, embedding ensures everyone works from the same source of truth.

[Learn more about dashboard embedding →](https://docs.cube.dev/embed/dashboard)

![Dashboard AI](https://static.cube.dev/blog/2025/whats-new-in-cube-october-2025-product-updates/dashboard-screenshot.png)

---

## 📓 Workbooks Updates

We've improved the visualization layer in Workbooks to give you more control over the details. The workbook agent builds analysis through natural language, and you can refine the results manually.

**Enhanced visualization control:**

- **Granular field management**: Directly adjust which fields appear in your analysis
- **Advanced filter controls**: Fine-tune filters at the query level for precise data slicing
- **Complete chart customization**: Control colors, labels, axes, and visual styling
- **Flexible layout options**: Arrange and size visualizations exactly as you envision
- **Query-level modifications**: Edit the underlying query when the AI gets close but not quite right

**Why this matters:**

Not every insight needs to be perfect on the first try. With enhanced workbooks, you can ask the AI to "show me sales by region with year-over-year comparison," let it build the foundation, then adjust the color scheme to match your brand, refine the date range, or swap in a different dimension—all without starting over.

This design philosophy recognizes that the best analytics comes from collaboration between human expertise and AI speed. The agent gets you 80-90% of the way there instantly; you add the context, nuance, and polish that transforms good analysis into great.

![Workbook-AI](https://static.cube.dev/blog/2025/whats-new-in-cube-october-2025-product-updates/workbook-screenshot.png)

---

## 🎨 Enhanced Visualization Capabilities

We've expanded our visualization toolkit with new chart types and customization options that give you complete control over how your data tells its story.

### Custom HTML Charts

Build exactly the visualization your data deserves with complete creative freedom. Write custom HTML, CSS, and JavaScript to create bespoke visualizations, integrate third-party libraries, and design branded experiences—all while accessing data through Cube's semantic layer.

### Map Charts

Turn location data into geographic intelligence. Visualize metrics across regions and geographies with interactive maps that integrate seamlessly with your dashboard filters and semantic layer.

### KPI Chart Enhancements

Three new components transform KPIs from simple numbers into rich performance displays: **Progress Indicators** for goal tracking, **Sparklines** for trend visualization, and **Rich Text Labels** for contextual formatting. Plus improved layouts with granular row height control for precise dashboard design.

---

## What's Next

These updates are part of our broader vision for [Agentic Analytics](https://cube.dev/blog/cube-agentic-analytics) – where dashboards evolve from static reports into intelligent, proactive analytical partners. We're not killing dashboards; we're making them intelligent.

All of these features are [available now](https://youtu.be/1tYd4xPPglY) in Cube. Whether you're building customer-facing embedded analytics, creating internal performance dashboards, or enabling self-service exploration, these updates give you more power, flexibility, and intelligence in every workflow.


What's New in Cube: Fall 2025 Product Updates


Cube Core version 1.5 is the [latest release](https://github.com/cube-js/cube/releases/tag/v1.5.0) to date.
It includes, among other goodies, improvements to the [performance of data model compilation](#performance-boost-to-data-model-compilation), introduces [calendar cubes](#improvements-to-tesseract-preview) in preview, and extends APIs with the new [HTTP transport for the SQL API](#sql-api) as well as explicit [cache control](#rest-api) options for REST API endpoints.

**This release does not contain breaking changes.** However, before upgrading, it is recommended that you check the following notes and adjust your data model and configuration if necessary:

* [Pre-aggregation matching with respect to join paths](#new-in-pre-aggregations).
* [DuckDB v1.4.1 upgrade](#new-in-data-source-support), affecting demo deployments in Cube Cloud.
* [NPM proxy settings](#new-in-configuration) no longer respected.

As always, we recommend testing the new version on a staging environment before deploying it to production.

## New in data modeling

### Performance boost to data model compilation

Cube provides a powerful data modeling layer that supports both YAML-based and JavaScript-based syntax,
allows executing Python and JavaScript code and using Jinja templates. This enables programmatic generation,
code reusability, and flexible multitenancy. However, it also complicates the process of data model compilation.

**In this release, the performance of data model compilation has been significantly improved,**
with approximately 2-3x compilation speedup, lesser memory consumption, and better utilization of multiple CPU cores.

> The performance increase is even more pronounced in Cube Cloud, which uses a different runtime for Cube, with up to 30x speedup for large data models.

You can read a full technical write-up about the performance optimization by [Konstantin Burkalev](https://github.com/KSDaemon) in [his blog](https://blog.ksdaemon.com/dev/turbocharging-cube-30x-faster-yaml-compilation/).

Also, note that `CUBEJS_TRANSPILATION_WORKER_THREADS` environment variable is now set to `true` by default.

### Improvements to views

**View members can now override `title`, `description`, `meta`, and `format` parameters,** allowing to customize
the presentation of cube members in different views, as shown in the [code example](https://github.com/cube-js/cube/pull/9496) on GitHub.

**View members can now be organized in nested folders,** which complements the previously introduced support for non-nested,
flat [folders in views](https://cube.dev/docs/product/data-modeling/reference/view#folders). While they are mostly useful for
[Microsoft Excel](https://cube.dev/docs/product/configuration/visualization-tools/excel) and
[Microsoft Power BI](https://cube.dev/docs/product/configuration/visualization-tools/powerbi) users in Cube Cloud,
nested folders can also be used by custom front-end applications built on top of Cube Core. See the support for data modeling
features in the [documentation](https://cube.dev/docs/product/apis-integrations#data-modeling).

Also, note that you can still define nested folders even if your visualization tools do not support them.
Cube provides two flattening mechanisms and the [`CUBEJS_NESTED_FOLDERS_DELIMITER` environment variable](https://cube.dev/docs/product/configuration/reference/environment-variables#cubejs_nested_folders_delimiter)
to control them.

### Improvements to YAML and Python support

**We've streamlined imports in Python code,** removing the necessity for [tricks with `PYTHONPATH`](https://github.com/cube-js/cube/issues/8443#issuecomment-2219804266).
You can check a Python example in the [documentation](https://cube.dev/docs/product/data-modeling/dynamic/jinja#imports).

**We've added support for [`{cube.sql()}` syntax](https://cube.dev/docs/product/data-modeling/syntax#cubesql-function) to YAML-based data models,** allowing for better data model code reusability,
especially when combined with [extension](https://cube.dev/docs/product/data-modeling/concepts/code-reusability-extending-cubes).
It also simplifies defining [polymorphic cubes](https://cube.dev/docs/product/data-modeling/concepts/polymorphic-cubes)
and using [data blending](https://cube.dev/docs/product/data-modeling/concepts/data-blending).

**Finally, we've supported [escaping of curly braces](https://cube.dev/docs/product/data-modeling/syntax#curly-braces-and-escaping) in YAML-based data models,** which makes it easier to use them
with JSON literals in SQL queries and similar scenarios.

### Improvements to Tesseract (preview)

Tesseract, the next-generation data modeling engine, is still in preview but has substantially expanded its capabilities.
It is recommended to give it a try by setting the `CUBEJS_TESSERACT_SQL_PLANNER` environment variable to `true`.
Please [report on GitHub](https://github.com/cube-js/cube/issues) any issues you encounter to help us improve Tesseract further.

Tesseract now supports all major [data sources](https://cube.dev/docs/product/configuration/data-sources).
It also supports [custom time dimension granularities](https://cube.dev/docs/product/data-modeling/reference/dimensions#granularities) and rolling window measures with custom granularities without an explicitly specified date range.
Finally, Tesseract supports [internal rate of return (XIRR)](https://cube.dev/docs/product/data-modeling/recipes/xirr) calculations and new [`switch` dimensions and `case` measures](https://github.com/cube-js/cube/pull/9951/files#diff-cec59fd0ac639e2ee756775c8115735e837c833c87a03e81934f4eb3edac12ba) (to be documented) for advanced data modeling use cases.

**Calendar cubes** feature, powered by Tesseract, has been introduced to provide a native way to [define and use custom calendars](https://cube.dev/docs/product/data-modeling/concepts/calendar-cubes),
simplify time-shift calculations, and provide better control over time dimension granularities.

Please review the [multi-stage calculations](https://cube.dev/docs/product/data-modeling/concepts/multi-stage-calculations)
and [calendar cubes](https://cube.dev/docs/product/data-modeling/concepts/calendar-cubes) documentation to familiarize yourself with Tesseract's capabilities.

## New in data source support

**Athena** now [supports](https://github.com/cube-js/cube/pull/9735) providing a default database to use via the `CUBEJS_DB_NAME` environment variable.
Also, Athena has received the [custom granularities](https://cube.dev/docs/product/data-modeling/reference/dimensions#granularities) support.

**Databricks** now supports [service principal access with OAuth](https://docs.databricks.com/aws/en/dev-tools/auth/oauth-m2m),
configured via the `CUBEJS_DB_DATABRICKS_OAUTH_CLIENT_ID` and `CUBEJS_DB_DATABRICKS_OAUTH_CLIENT_SECRET` environment variables.
Also, Databricks connection checking has been improved to avoid waking up SQL warehouses unnecessarily.

**DuckDB** has been upgraded to [version 1.4.1](https://r.duckdb.org/news/index.html#duckdb-141).
Also, DuckDB now supports installing and loading [DuckDB Community Extensions](https://duckdb.org/community_extensions/) via the `CUBEJS_DB_DUCKDB_COMMUNITY_EXTENSIONS` environment variable.
Finally, DuckDB can now use the default credential provider chain for S3 access when the `CUBEJS_DB_DUCKDB_S3_USE_CREDENTIAL_CHAIN` environment variable is set to `true`.

> Note that the `httpfs` extension used by this DuckDB version now [constructs S3 URLs differently](https://github.com/duckdb/duckdb-httpfs/pull/83/files), leading to the following errors in previously created demo deployments in Cube Cloud: `Error: IO Error: Unknown error for HTTP HEAD to 'https://cube-tutorial.s3.us-east-1.amazonaws.com/orders.csv'`. You can fix this issue by setting the `AWS_DEFAULT_REGION` environment variable to `us-east-2` in these deployments.

**Presto** now supports [export buckets](https://cube.dev/docs/product/configuration/data-sources/presto#export-bucket) on AWS S3 in addition to previously supported export buckets on GCS.
Also, Presto has received the [custom granularities](https://cube.dev/docs/product/data-modeling/reference/dimensions#granularities) support.
Finally, custom authentication headers can now be specified via the new `CUBEJS_DB_PRESTO_AUTH_TOKEN` environment variable.

**Snowflake** can now use the new `CUBEJS_DB_SNOWFLAKE_OAUTH_TOKEN` environment variable to provide an OAuth token for authentication,
complementing previously available `CUBEJS_DB_SNOWFLAKE_OAUTH_TOKEN_PATH`. It also works with deeply nested paths for export buckets,
specified via `CUBEJS_DB_EXPORT_BUCKET`. Finally, the `queryTag` parameter can be [passed](https://github.com/cube-js/cube/pull/9889/files)
to enable [enhanced monitoring](https://select.dev/posts/snowflake-query-tags) in Snowflake.

**Trino** now uses a custom Trino-specific connection check.
Also, custom authentication headers can now be specified via the new `CUBEJS_DB_PRESTO_AUTH_TOKEN` environment variable.

**Amazon Redshift**, **MS SQL Server**, and **SQLite** drivers have got a few bug fixes.

## New in APIs and client libraries

### REST API

[`/v1/load`](https://cube.dev/docs/product/apis-integrations/rest-api/reference#base_pathv1load) and [`/v1/cubesql`](https://cube.dev/docs/product/apis-integrations/rest-api/reference#base_pathv1cubesql) endpoints of the REST API now accept the new `cache` parameter that allows to specify the [caching strategy](https://cube.dev/docs/product/apis-integrations/rest-api#cache-control) that Cube should use when fulfilling requests. Related `cache` parameter has also been added to the [JavaScript client library](https://cube.dev/docs/product/apis-integrations/javascript-sdk/reference/cubejs-client-core).

The REST API query format now supports specifying the granularity for time dimensions in the [`order` property](https://cube.dev/docs/product/apis-integrations/rest-api/query-format#query-properties) of the query.
This is useful when the same time dimension is used multiple times in the query with different granularities.

Also, [`beforeOrOnDate`](https://cube.dev/docs/product/apis-integrations/rest-api/query-format#beforeorondate) and
[`afterOrOnDate`](https://cube.dev/docs/product/apis-integrations/rest-api/query-format#afterorondate) filter operators of the REST API have now been documented.

### SQL API

The SQL API was complemented with a new [HTTP transport](https://cube.dev/docs/product/apis-integrations/sql-api#transport),
supported by the [`/v1/cubesql` API endpoint](https://cube.dev/docs/product/apis-integrations/rest-api/reference#base_pathv1cubesql).
It allows to execute SQL API queries over HTTP and get a streaming response. This can be useful for custom front-end applications,
embedded analytics scenarios, and AI-based experiences. Related `cubeSql` method has also been added to the [JavaScript client library](https://cube.dev/docs/product/apis-integrations/javascript-sdk/reference/cubejs-client-core).

Finally, the SQL API has got various compatibility improvements, including better support for DBeaver, DataGrip, SQLAlchemy, Tableau, and other BI tools.
It now supports cursors in the [streaming mode](https://cube.dev/docs/product/apis-integrations/sql-api#streaming) and ignores transactions-related statements such as `SAVEPOINT`, `ROLLBACK`, and `RELEASE`.

## New in pre-aggregations

The pre-aggregation matching algorithm has been improved to use the [join tree](https://cube.dev/docs/product/data-modeling/concepts/working-with-joins#join-tree) structure of the query and pre-aggregations.
Now pre-aggregations not only allow to specify [join paths](https://cube.dev/docs/product/data-modeling/concepts/working-with-joins#join-paths) for their members, but also implement stricter checks that prevent incorrect pre-aggregation matching
when a query has joins that are not covered by the pre-aggregation's join tree.

> After the upgrade, some of the queries might stop using pre-aggregations due to stricter matching. It is recommended to review joins defined in the data model and add join paths to pre-aggregations if necessary.

## New in query orchestrator

Some performance optimizations have been introduced to reduce the number of refresh key queries and improve the overall reliability of the query queue.

## New in Cube Store

Various performance optimizations have been made to Cube Store, including debouncing information schema queries and reducing memory usage.

Also, a substantial work has been done to support common-table expressions (CTEs) and joins in Cube Store queries, enabling the use of pre-aggregations for multi-stage calculations powered by Tesseract. It is not included in the current release but will be released in the upcoming versions.

## New in configuration

NPM proxy settings are [no longer respected](https://github.com/cube-js/cube/pull/9715) and only common `HTTP_PROXY` and/or `HTTPS_PROXY` environment variables are used.

## New in documentation

The page about [joins between cubes](https://cube.dev/docs/product/data-modeling/concepts/working-with-joins) has been significantly expanded
with new sections about join trees, join paths, and join hints. It is recommended to review this page to get better understanding of how joins work in Cube.

## Version changes

This release also upgrades Node.js, used internally by Cube, to v22.20. Python is also upgraded to v3.15.5.

## What’s next?

We're looking forward to your feedback on this release! Please join our [Slack community](https://slack.cube.dev/)
to share your thoughts and ask any questions.

We are already working on the next release, which will include further improvements to Tesseract and Cube Store.

And don't hesitate to try the new release in our managed [cloud offering](https://cube.dev/cloud), which provides a free plan.


Konstantin Burkalev

Cube Core v1.5 — Performance, calendar cubes, SQL API over HTTP


We're announcing that the previous [long-term support](https://cube.dev/docs/product/distribution#long-term-support) (LTS) release, Cube Core v1.0, has reached its end-of-life and it's now superseded by the new LTS release: Cube Core v1.4.

**Feature-wise, it's equivalent to the latest Cube Core v1.5 release, for which we've published a separate [comprehensive changelog](https://cube.dev/blog/cube-core-v1-5-performance-calendar-cubes-sql-api-over-http).** Users upgrading from v1.0 or earlier releases are advised to take a look at all [changelogs](https://cube.dev/blog/category/changelog) covering the version range for their upgrade.

We also recommend Cube Cloud users to use the [regular update channel](https://cube.dev/docs/product/deployment/cloud/deployments#update-channels), tracking the Cube Core v1.5 branch, potentially pinning used versions to specific ones within that branch. This allows to receive bug fixes and new features in a more timely manner compared to the LTS branch.

As always, please feel free to share your feedback in our [Slack community](https://slack.cube.dev) or file [issues on GitHub](https://github.com/cube-js/cube/issues).


Cube Core v1.4 — New LTS release


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


We're excited to share that Cube has been recognized as a **Leader and Outperformer** in the 2025 GigaOm Radar for Semantic Layers and Metrics Stores. This recognition positions Cube in the Innovation/Platform Play quadrant, reflecting our commitment to rapid innovation and comprehensive platform capabilities that serve the evolving needs of data teams navigating the transformation from traditional BI to agentic analytics.

## **The AI-Driven Future of Data Applications**

This recognition comes at a pivotal moment. We believe AI is fundamentally transforming the landscape of data tools, and the semantic layer has never been more critical. As organizations move from traditional business intelligence toward what we call "Agentic Business Intelligence," the need for a trusted, governed foundation becomes paramount.

GigaOm's analysis highlights what makes Cube uniquely positioned for this transformation: our ability to serve as a foundation for embedded analytics, accelerate AI-augmented BI workflows, enable modern agentic analytics applications, and deliver all of this through a developer-friendly, API-first platform with intelligent caching and pre-aggregation.

The report emphasizes Cube's versatility across the modern data stack—from standardizing metrics in business intelligence to enabling real-time analytics and building embedded analytics applications. This breadth, combined with Cube's advanced data modeling capabilities and comprehensive API support (REST, GraphQL, SQL, MDX and DAX), positions Cube as a universal semantic layer that can power any data application: internal, external, human, or AI-driven.

## **Why Semantic Layers Matter More Than Ever for AI**

While AI can dramatically increase productivity and lower barriers to analytics, it also introduces new risks around data quality and governance. This is precisely where semantic layers become indispensable. A semantic layer provides the "safe zones" that AI agents need—governed, trusted definitions that prevent hallucinations and ensure accurate insights.

At Cube, we've seen this firsthand. Almost every organization wants a semantic layer; the challenge has always been the complexity of building and maintaining one. Now, with AI, we can significantly streamline this process. AI can handle mundane tasks, assist with modeling, and act as an intelligent guide—but it needs the semantic layer as its foundation to deliver trustworthy results.

This is why we've evolved from being a headless semantic layer to building our own native AI/BI [frontend](https://cube.dev/blog/cube-native-ai-bi-frontend). We're applying AI across all three core BI functions—Modeling, Exploration, and Presentation—while maintaining human oversight and control at every step.

## **What Sets Cube Apart**

GigaOm scored Cube highly across multiple critical areas:

**Modeling Language Support**  
Cube's declarative YAML syntax combined with JavaScript and Python support for complex modeling gives data engineers the flexibility they need. Whether you're building straightforward metrics or dynamic data models, Cube provides the right tools for the job—and now, with Cube Copilot, AI assistance to accelerate the process.

**Advanced Data Modeling Capabilities**  
From multiple fact tables and many-to-many relationships through bridge tables to polymorphic cubes for parent-child relationships, Cube captures complex business logic that reflects real-world data scenarios. This richness in the semantic layer becomes the context that powers accurate AI-driven insights.

**DataOps Integration**  
With deep Git integration across major providers, Cube enables version control, pull requests, CI/CD, and separate development, staging, and production environments. Your semantic layer models benefit from the same software engineering best practices you apply to application code—critical as AI starts generating and modifying these models.

**Native API Support and Caching**  
Cube's comprehensive API offerings, including REST, GraphQL, SQL, MDX and DAX, ensure seamless connectivity with your existing tools and workflows. Combined with Cube's intelligent pre-aggregation and caching layer, queries are accelerated dramatically, providing the performance AI applications and BI tools demand.

## **Why We're an Outperformer**

The Outperformer designation recognizes our ambitious roadmap and rapid pace of innovation. Over the past year, we've launched transformative capabilities including a Visual Modeler for no-code data modeling, AI assisted data model generation, DAX support and first class integrated AI/BI capabilities. We've also introduced next-generation capabilities with our Tesseract data modeling engine and expanded our integration ecosystem.

This momentum continues to accelerate. We're continuing to develop our agentic AI features that enable users to interact with their data through natural language, powered by AI agents tailored to different personas—data analysts, data scientists, and data engineers. Our new native AI/BI frontend represents a fundamental shift in how organizations will work with data, augmenting human intelligence at every stage of the analytics workflow.

The goal isn't to replace data professionals, it's to amplify their capabilities and make analytics accessible to a broader range of knowledge workers. With AI handling mundane tasks and providing intelligent assistance, data teams can move faster while maintaining the governance and accuracy that only a well-designed semantic layer can provide.

## **Looking Ahead: Agentic Business Intelligence**

The GigaOm Radar report arrives as we're witnessing a transformation in how organizations approach analytics. Traditional BI isn't disappearing, it's evolving into Agentic Business Intelligence, where AI augments modeling, exploration, and presentation workflows while humans maintain fine-grained control over every AI action.

Cube provides the essential foundation for this evolution. As organizations face increasingly decentralized data and the growing complexity of AI/BI initiatives, the need for a universal semantic layer has never been clearer. Cube helps eliminate confusion, standardize metrics, and deliver trusted data to any endpoint—whether that's a BI tool, an embedded analytics application, or an AI agent.

GigaOm identifies areas where Cube continues to evolve, particularly around GenAI enablement. While our agentic features are actively in development, our existing platform already empowers teams to enrich LLMs with appropriate business context and complex logic captured in semantic models. As these capabilities reach general availability, they'll further strengthen Cube's position as the platform that bridges traditional BI and the AI-driven future.

## **Use Cases Where Cube Excels**

The report highlights several areas where Cube delivers exceptional value:

* **Standardizing metrics** across business intelligence and reporting, ensuring consistency for both human analysts and AI agents  
* **Enabling embedded analytics** with developer-friendly APIs and comprehensive integration options  
* **Powering agentic analytics** applications with a trusted semantic foundation that prevents AI hallucinations  
* **Accelerating query performance** through intelligent pre-aggregation and caching

## **Try Cube Today**

Whether you're looking to standardize metrics across your organization, build embedded analytics experiences, or prepare your data infrastructure for AI-driven applications, Cube provides the foundation you need.

For a comprehensive look at Cube's evaluation and to understand how semantic layers fit into modern data architectures, we encourage you to [read the complete GigaOm Radar report](https://cube.dev/gigaom-rates-cube-as-a-leader-for-semantic-layers).

Thank you to the entire Cube community—our users, partners, and contributors—for making this recognition possible. Your feedback and collaboration continue to drive our innovation forward as we build the future of Agentic Business Intelligence together.

Ready to see what Cube Cloud can do for your organization? [Get started today](https://cube.dev/) or [contact our team](https://cube.dev/contact) to learn more about how Cube can power your AI/BI transformation.


Brian Bickell

Cube Cloud Named Leader and Outperformer in 2025 GigaOm Radar for Semantic Layers and Metrics Stores


_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


TL;DR — Cube joins Snowflake to participate as a launch partner in a new industry initiative to define an **Open Semantic Interchange (OSI)**: an open-source, vendor-agnostic specification for describing and exchanging semantic models. Our goal is to help customers move definitions of metrics, dimensions, and business logic safely and consistently across tools thereby accelerating AI/BI adoption while preserving choice.

## Why this matters

Organizations today run analytics and AI across a mosaic of platforms—data clouds, transformation frameworks, BI tools, notebooks, and AI agents. The business meaning of data (metrics, dimensions, relationships, access policies) too often gets re-implemented differently in each place, creating inconsistency and friction.

The **Open Semantic Interchange (OSI)** initiative aims to change that by establishing:

* **A common, open specification** for semantic metadata—portable across vendors and tools.

* **Open-source code modules** that translate one party’s semantic model into another’s, making interoperability practical, not aspirational.

* **A collaborative consortium** focused on vendor neutrality, efficiency for data teams, and faster, more reliable AI/BI outcomes.

For customers, standardized semantics mean fewer rewrites, simpler governance, and greater freedom to choose the best tools for each job without losing the meaning of their data.

## Cube’s role

Cube exists to make governed, reusable semantics available everywhere. As a launch participant in OSI, we plan to:

1. **Contribute to the OSI specification** with learnings from our work powering semantic layers at scale across the Snowflake ecosystem and beyond.

2. **Provide open adapters/translation modules** to read and write OSI from Cube, enabling customers and partners to move models and metrics definitions between Cube and other OSI-compatible systems.

3. **Champion interoperability for AI** by making OSI semantics addressable by AI applications and agents, improving accuracy and governance for LLM-powered analytics.

## What customers can expect

* **Interoperability by design.** Define a metric once and use it in multiple tools via Cube’s world class APIs with consistent results. Synchronize it to other platforms like Snowflake Semantic Views as desired.

* **Operational efficiency.** Reduce duplicate model work, simplify migrations, and streamline semantic governance.

* **Vendor flexibility.** Adopt new AI/BI tools—or consolidate existing ones—without starting semantic modeling from scratch.

## Timeline and what’s next

As materials, repositories, and other resources go live, we’ll update this post with links and add technical guidance for Cube users and partners.

If you’d like to learn more about the open semantic interchange with Cube please reach out via our contact us form.

## A note of thanks

We appreciate Snowflake’s leadership in convening this cross-industry effort and are excited to collaborate with fellow launch participants. Standardized, open semantics are a win for customers, partners, and the broader data and AI community and we’re proud to help build them.


Cube joins Snowflake’s Open Semantic Interchange launch initiative


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


The term “AI” is everywhere, but it has become a confusing umbrella for a wide range of capabilities. We have chatbots that answer simple questions, copilots that suggest code, and generative tools that write prose. While powerful, many enterprises are finding these tools hit a ceiling. They are helpful, but they don't fundamentally change the workflow. This is because most AI today is reactive. It waits for a command and executes a single task. This has led many organizations into "pilot purgatory," where impressive demos fail to translate into scalable, operational value. The reason is simple: real data work isn't about single questions; it's about multi-step investigation and reasoning.

This is where agentic analytics comes in. An __agentic analytics platform__, like [Cube D3](https://cube.dev/product/cube-d3), operates on a different paradigm. It doesn’t just answer; it reasons, acts, and learns. It’s a digital teammate, not just a tool. The future of work is agentic. We are seeing it transform software engineering, and now it's coming for analytics.

![](https://lgo0ecceic.ucarecd.net/20383d36-41cb-4476-9eca-5fcc7cc9f8b2/)

## Reasoning: The Power of Deep Context
A simple chatbot might translate "show me revenue" into a SQL query. But what does "revenue" mean? Is it gross or net? Does it include returns? Is it based on cash or accrual accounting? A generalist AI will guess, and its guess might be confidently wrong, leading to the inconsistent metrics that plague data teams.

D3’s agents reason because they are grounded in the deep context of your business, provided by Cube Cloud’s universal semantic layer. They don’t just see a database schema; they see a curated model of your business. They know precisely how "revenue" is calculated, what defines an "active user," and which filters are appropriate for a given business question because you have defined it once in a central, governed location. This moves the AI from syntactic understanding (matching keywords) to semantic understanding (grasping business meaning). This is the foundation of trust. An agent that can reason with your business logic is an agent that produces reliable, defensible outputs.

## Acting: From Single Queries to Multi-Step Analysis
The most significant leap from a chatbot to an agent is the ability to act on a goal through a series of steps. As Artyom demonstrated in the webinar, this is an interactive and iterative process. The workflow looked like this:
1. __Initial Prompt__: "Show me revenue numbers." The agent queries the governed revenue metric.
2. __Follow-up__: "Add a monthly breakdown." The agent adds the time dimension.
3. __Complex Derivation__: "Now, add prior month's revenue and month-over-month growth."

<video width="100%" controls><source src="https://player.vimeo.com/progressive_redirect/playback/1101351336/rendition/1080p/file.mp4?loc=external&signature=114fcc6b87c8df5e3a37f6c0539a223945e08b500b3cbac4593812a5d8512af2" type="video/mp4"/></video>

This final step is where the agentic capability shines. The "month-over-month growth" metric didn't exist in the data model. Instead of failing, the AI Data Analyst agent acted as a true analytical partner. It understood the user's intent, formulated a plan, and executed a series of calculations on top of the governed metrics to produce the answer. It performed a multi-step task, moving from simple data retrieval to on-the-fly analysis. This ability to plan and execute complex workflows is what allows agents to automate tasks that would otherwise require hours of manual work from a human analyst.

## Learning: Building Institutional Knowledge
Finally, an agentic platform must learn. If every analysis starts from scratch, you are simply speeding up redundant work. D3 is designed to build institutional memory, ensuring the system becomes smarter and more reliable over time. This happens through several mechanisms:
1. __Memories__: D3 agents remember the context of past conversations. When a user provides feedback (a thumbs up or down), it reinforces which analytical paths were successful. The agent learns what a "good" answer looks like for a specific team or use case. Great analysts remember what worked. So do great AI teammates.
2. __Certified Queries__: When an analyst crafts a particularly insightful or complex query, it can be "certified" as a gold-standard report. This becomes a reusable, trusted pattern that other users and agents can leverage, codifying best practices directly into the system.

The future of data work isn't just about getting faster answers. It's about augmenting data teams with AI teammates that can handle complex, multi-step analytical workflows with a deep understanding of the business. That is the core of agentic analytics, and it’s a fundamental redefinition of the entire analytics experience.

*Next up: In our next post, we’ll explore the engine that makes this all possible: the universal semantic layer.*

---

Curious to explore D3 further? [Sign up for the waitlist](https://learn.cube.dev/cube-d3-early-access?utm_source=cube&utm_medium=blog&utm_content=d3_webinar_blog1) or access [the on-demand webinar](https://cube.ondemand.goldcast.io/on-demand/21d74532-3035-4eb8-b06d-7739230a8d29?utm_source=cube&utm_medium=blog&utm_content=d3_webinar_blog1).


David Jayatillake

Beyond the Chatbot: What is an Agentic Analytics Platform?


The advent of AI agents - AI systems that can autonomously achieve goals in the world, with little to no explicit human instruction about how to do so - is ushering in a transformative era for businesses. Leading tech companies, AI startups, and investors are heavily focused on these developments, envisioning a future where millions or billions of agents autonomously perform complex tasks across society. As these "AI teammates" become integral to daily operations, from automating data pipelines to generating executive insights, the critical challenge shifts to effectively managing, monitoring, and governing their behavior to ensure trust, consistency, and security.

## The Imperative of Agent Governance
Deploying capable AI agents en masse promises transformative benefits but also introduces profound and novel risks. Without proper governance, issues like conflicting interpretations of data, inadvertent exposure of sensitive information, cascading errors from bad inputs, and an inability to reconstruct decision logic can arise. This necessitates a robust framework for managing the agent lifecycle, ensuring that these autonomous systems operate within trusted boundaries.

Only a few researchers are currently actively working on agent governance challenges, primarily in civil society organizations, public research institutes, and frontier AI companies. Fortunately, platforms like Cube D3 are emerging to provide enterprise-grade solutions for this nascent field.

## Managing Your AI Teammates: D3's Approach to Spaces and Scoping
Cube D3 is the first agentic analytics platform built on a universal semantic layer, designed to enable the development and deployment of AI data co-workers across the enterprise. A core aspect of managing these AI teammates effectively in D3 revolves around its concepts of "Agent Spaces" and scoping agent operations.

- __Agent Spaces__ are logical groupings used to manage agents and their related resources. These spaces support a role-based permission model, simplifying the management and oversight of agent groups. This allows organizations to facilitate the creation, viewing, and deletion of agent groups in a structured manner.
- __Scoping Agent Operations__: Within these spaces, agents can be restricted to specific data views for enhanced security and focus. This ensures that each agent only interacts with the data relevant to its defined role, minimizing the risk of unauthorized access or misuse. For instance, an AI Data Analyst assists Data Consumers by creating Semantic SQL queries and visualizations, while an AI Data Engineering Agent supports Data Stewards in creating and optimizing semantic models.
- __Rules for Behavior__: D3 also incorporates "Rules," which are defined guidelines within a space that manage agent behavior and data interaction. These can include "always rules" and "agent requested rules," providing a crucial mechanism for guiding AI on how to query specific data points or respond to complex scenarios.
- __Bring Your Own Model (BYOM)__: D3 supports the selection of various Large Language Models (LLMs), including the ability to Bring Your Own Model (BYOM). This flexibility allows enterprises to meet stringent requirements and keep their data secure.

This structured approach to agent management through spaces and scoping ensures that agents operate within defined boundaries, mirroring how human teams are organized with distinct responsibilities and access levels.

## Monitoring Your AI Teammates: Transparency, Logging, and Rectification
For AI agents to be trusted, their actions must be transparent and auditable. D3 provides robust mechanisms to monitor agent activities, understand their reasoning, and rectify any incorrect approaches.

- __Explainable Outputs__: D3 agents don't just generate answers; they explain their decisions. Every result includes transparent query logic, data sources, filters, metric lineage, and calculation logic. This "legibility of agent activity" provides users with the transparency and oversight necessary to understand how the agentic AI system works and why it carried out a particular action. This allows executives and data consumers to click into every result, inspect every query, and feel confident in every recommendation.
- __Traceable Actions and Logging__: D3 ensures that every agent’s action is logged, version controlled, and auditable for traceability. This includes Semantic SQL Tool Call Messages (SSTCMs), which are immutable records of agent-generated queries and visualizations. This capability is crucial for audit readiness and compliance, especially in regulated industries.
- __Iterative Refinement and Rectification__: The D3 Analytics Chat Interface allows users to interact with agents using natural language. When an agent generates a query or visualization, it's presented as an SSTCM in the chat. Users can then open these SSTCMs or "Workbooks" (saved analytical outputs) in the Data Explorer to view the underlying SQL query, results, and visualizations. Crucially, users can modify the SQL query, run it, and send the updated query back to the chat to refine their analysis or provide feedback to the agent. This direct ability to inspect and correct the agent's generated SQL facilitates understanding and rectifying incorrect approaches, enhancing the agent's learning over time.
- __Certified Queries__: To further ensure trust and consistency, D3 allows for Certified Queries, which are SQL queries that have been reviewed and approved by administrators. Agents can then reliably use these certified queries within a specific space, reinforcing best practices and preventing deviations from established logic.

This comprehensive approach to monitoring provides both visibility and control, addressing the concerns of businesses moving from AI experimentation to AI-driven execution.

## Governing with a Semantic Core: The Single Source of Truth
The foundation of trusted AI agent operations in D3 is Cube Cloud's universal semantic layer. This semantic core is not merely a data catalog; it is a structured bridge between complex data sources and business requirements, transforming technical data language into the understandable vocabulary of the business.

- __Single Source of Truth__: The semantic layer provides a single source of truth for business metrics and dimensions, ensuring consistent definitions and reducing ambiguity across the organization. This is paramount because if agents interpret key performance indicators (KPIs) differently, it can lead to conflicting recommendations and undermine trust.
- __Deep Contextual Understanding__: By embedding metadata and standardizing business logic, the semantic layer offers the deep contextual understanding necessary for AI agents. Without this governed, business-friendly layer, AI agents querying raw data directly are prone to errors, miscalculations, and "hallucinations".
- __Automated SQL Generation__: Cube's semantic layer includes a compiler that translates high-level business requests into correct and optimized SQL queries. This offloads the complex task of SQL generation from the AI agent, drastically reducing error risk and ensuring that the queries align with enterprise standards and policies.
- __Fine-Grained Governance and Access Control__: D3 extends the semantic governance of Cube Cloud into the agent ecosystem. This means that access policies are enforced at the semantic level, not just at the application layer. D3 validates inputs and outputs, enforces metric definitions, controls access permissions, and logs every action for traceability. This ensures that no matter how or where an agent acts, sensitive data remains protected and that agents cannot operate outside of defined rules or permissions. This provides enterprise-grade governance over every AI output.

By grounding every agent in this consistent semantic model, D3 ensures that every human and every machine thinks consistently, acts responsibly, and drives real, scalable outcomes. This robust semantic foundation is what differentiates D3, delivering a modern, agentic analytics experience where all outputs are governed, consistent, and aligned with business logic.

## Manage, Monitor, and Govern AI Teammates
In conclusion, managing, monitoring, and governing AI teammates is not just about isolated controls but about an integrated system. Cube D3, with its agent spaces and scoping capabilities, its transparent logging and explainability features, and its foundation in Cube Cloud's universal semantic layer, provides a comprehensive framework for enterprises to build trusted multi-agent architectures, accelerate insight generation, and ensure the trustworthiness of AI-driven analysis. The future of data work is agentic, and with D3, organizations can unlock faster, more accurate, and more impactful decisions at every level of the business. 

Ready to take the next step? Be among the first to gain Cube D3 access by [joining the waitlist](https://learn.cube.dev/cube-d3-early-access?utm_source=cube&utm_medium=blog&utm_content=d3%20lifecycle%20blog%202) and upgrading the data and analytics lifecycle for your data teams.


The Agent Lifecycle: How to Manage, Monitor, and Govern AI Teammates


Modern BI changed the way we think about data access, but even the most advanced dashboards and self-serve tools are starting to show their limits. As AI reshapes the enterprise software landscape, static dashboards and spreadsheet workflows are no longer enough.

What organizations need next is agentic analytics, an entirely new paradigm where AI-powered teammates work alongside humans to explore data, build models, generate insights, and explain their decisions.

This is exactly what Cube D3, the agentic analytics platform from Cube, is designed to deliver. Built on Cube Cloud’s universal semantic layer, D3 empowers organizations to move from a dashboard-driven culture to an agent-driven one—without compromising governance, consistency, or control.

So how do you transition? Whether you’re relying on a mix of traditional BI tools and spreadsheets or struggling with backlog and bottlenecks, this guide provides a step-by-step framework for adopting agentic analytics in a repeatable, scalable way.

## Step 1: Identify High-Impact Use Cases

### Start where repetitive questions slow down productivity

Every organization has recurring analytics tasks that eat up time: marketing campaign summaries, weekly sales breakdowns, inventory audits, or customer behavior trends. These are exactly the types of use cases that Cube D3’s AI Data Analyst can tackle from day one.

Begin your journey to agentic analytics by identifying:

- Common ad-hoc requests from business stakeholders
- Reports that require multiple SQL queries or iterations to build
- Metrics that are consistently re-analyzed in different contexts

With Cube D3, business users can type natural language questions—like “Which regions had the highest margin last quarter?”—and get visual, governed results instantly. This alone can cut reporting cycles from days to minutes.

📌 Tip: Prioritize use cases where automation reduces the load on your data team and improves time-to-insight for business users.

## Step 2: Build the Semantic Foundation

### Agentic analytics requires a semantic layer—and Cube Cloud provides it

AI agents are only as effective as the context they’re grounded in. If your AI is pulling from raw tables or inconsistent logic, you’ll get fast answers—but they won’t be trustworthy or consistent.

That’s why Cube Cloud’s universal semantic layer is so critical to D3’s architecture. It acts as the business logic brain for all AI-generated outputs—ensuring that every chart, metric, and recommendation comes from a governed, centralized source of truth.

Steps to get started with Cube Cloud:

- Define critical business metrics, dimensions, and data relationships
- Model them in Cube Cloud using YAML, JSON, or code-based workflows
- Apply role-based access controls and lineage to enforce governance

When D3’s agents query data, they don’t guess—they generate semantic SQL grounded in these models, ensuring accuracy, explainability, and auditability every time.

📌 Tip: Start by aligning with business stakeholders on critical KPIs and definitions. Then translate these into semantic models in Cube Cloud. Treat the semantic layer as living documentation that agents and humans alike can depend on.

## Step 3: Onboard Your First AI Teammate

### Activate Cube D3’s analytics agents and start exploring  

With semantic models in place via Cube Cloud, you can now deploy your first agents in Cube D3. These agents are more than chatbots—they’re intelligent AI teammates that assist with analysis, model maintenance, and workflow execution.

Start with:

- AI Data Analyst: For business users and analysts to query data using natural language, generate visualizations, and save reusable reports.
- AI Data Engineer: For data stewards to automate semantic model creation, propose new metrics, and reduce backlogs.

Cube D3 provides a conversational interface where users can ask questions, inspect SQL, drill down into data, and iterate—all without waiting on a ticket or change request.

📌 Tip: Choose a business team (e.g., Sales Ops or Marketing Analytics) and guide them through a defined use case. Track adoption and satisfaction as part of your success criteria. Document data points like time to complete manually versus with agents to build your business case.

## Step 4: Monitor Usage and Improve Agents

### Refine the experience using transparency and governance features

Adopting agentic analytics isn’t a “set it and forget it” initiative. Success comes from governed iteration—observing how users interact with Cube D3 and improving both the agents and underlying models over time.

With Cube D3:

- Every query is fully traceable and can be audited
- Reports can be verified by admins to ensure reuse across teams
- Query logic, filters, joins, and sources are always visible and inspectable
- You can drill down into agent-generated results or override logic when needed

By using Cube Cloud’s semantic layer as a governance backbone, you can improve trust in AI outputs while still delivering speed and flexibility.

📌 Tip: Interview users about where they still encounter friction. Are definitions unclear? Are agents over- or under-confident? Use this data to tune prompts and improve semantic coverage.

## Step 5: Scale Across Tools, Teams, and Agents

### Extend agentic analytics into your existing workflows

Once you’ve validated the value of Cube D3 within a small team or use case, it’s time to embed agentic workflows across the enterprise. This means putting D3’s agents in the tools your teams already use—without requiring a context switch.

Examples:
- Embed the Analytics Chat Interface in your intranet, apps, and tools
- Use Model Context Protocol (MCP) or iframe embedding to integrate with external tools
- Allow D3 agents to participate in multi-agent workflows, driving outcomes with agents from other domains via A2A (agent-to-agent)

This is where the full power of agentic analytics shows up: not just answering questions, but accelerating action, collaboration, and impact.

📌 Tip: Identify the workflows and daily tools your business teams already rely on. Add Cube D3 agents directly into them to minimize change management and maximize adoption of agentic workflows.

## Begin a New Chapter in Analytics Powered by Cube
Traditional BI got us dashboards. “Modern BI” added interactivity. But now, Cube D3 with Cube Cloud is ushering in a new era: agentic analytics, where AI coworkers automate routine tasks, help data teams scale, and enable business stakeholders to get answers faster.

To recap the journey:

- Identify high-friction workflows where AI can deliver value quickly
- Model your business logic in Cube Cloud’s universal semantic layer
- Deploy your first AI coworkers using Cube D3’s analyst and engineering agents
- Govern, monitor, and explain every result to build trust
- Scale across your org by embedding D3 into the tools people use every day

By transitioning to agentic analytics, you don’t just get faster reports. Now you can enable every team to act on data with confidence, speed, and autonomy.

Ready to take the next step? Be among the first to gain Cube D3 access by [joining the waitlist](https://learn.cube.dev/cube-d3-early-access?utm_source=cube&utm_medium=blog&utm_content=d3%20campaign%20blog%202) and upgrading the data and analytics lifecycle for your data teams.


Michael Hetrick

How to Transition to Cube D3’s Agentic Analytics


For decades, modern analytics has been a rallying cry for data teams seeking to break free from legacy BI tools. This era brought powerful advances from cloud data warehouses and ELT workflows to self-service BI platforms and dashboards promising agility and democratization. But in 2025, everything has changed. The modern data stack, once the future, is now beginning to show its age.

The rise of generative and agentic AI is exposing the limitations of today’s modern analytics tools. Business users still wait in line for answers. Data teams still manage backlogs. Dashboards still tell you what happened, but rarely why and never what to do next. In short: the modern analytics stack optimized for speed, not autonomy. What’s next? It’s called agentic analytics.

## From Self-Serve to Self-Acting
Self-service BI was supposed to empower the business. Tools like Looker, Tableau, and Power BI made it easier to explore data. But they assumed users knew what to look for, how to filter it, and which charts to build. These tools provided more control but not always more insight. 

Even though analytics and BI tools have gotten easier to use, average adoption by enterprise employees is between 25-32%, since 2007 according to Gartner. Year-after-year this number has remained relatively unchanged, indicating that a greater opportunity to democratize data exists within every organization.

Agentic analytics flips the model. Instead of expecting humans to define every input and interaction, AI agents act as autonomous teammates. They generate queries, explore patterns, surface anomalies, and recommend actions, all grounded in context and driven by logic.

## Why “Modern” Starts to Feel Legacy
The tools we’ve long labeled “modern” were revolutionary in a world of on-premises databases and Excel spreadsheets. But they weren’t designed for the AI era. Many are now retrofitting “AI Assistants” or “natural language query” buttons. And while useful, these bolt-on features often lack the depth, trust, and automation needed for enterprise-grade decision-making.

Here’s what today’s BI tools often don’t do well:
- Maintain consistent metric definitions across tools and teams
- Understand natural language in a way that supports follow-up questions
- Offer full explainability of how results were generated
- Integrate into workflows to trigger actions beyond charts
- Collaborate with other agents or systems

And perhaps most importantly, they don’t act autonomously. They require humans to click, filter, and configure every insight. Modern analytics tools helped us analyze faster. Agentic analytics helps us act smarter.

## What Makes Agentic Analytics Different
According to Gartner, agentic analytics represents the evolution of augmented analytics. It does this by applying AI agents, which are software powered by generative AI (GenAI), including Large Language Models (LLMs) and other AI techniques, for data analysis. These AI agents are designed to autonomously decide what to do and when to do it, using planning, short and long-term memory, tools, and learnings. 

Cube D3’s agentic analytics bridges the gap between your data and decisions with AI data agents, matching human roles in the data and analytics lifecycle. It doesn’t rely on dashboards and drag-and-drop interfaces. It leverages Cube Cloud’s universal semantic layer to ensure data integrity, and AI agents to automate exploration, decision-making, and even follow-up tasks.

Let’s break down what this means in practice:

### 1. Semantic Intelligence at the Core
Every D3 agent is grounded on Cube Cloud’s universal semantic layer. That means when the AI Data Analyst answers a question like “What was our churn rate last quarter?”, it’s not guessing or improvising. It’s using pre-approved metric definitions, governed access controls, and consistent data logic.

Now, compare that to traditional NLQ add-ons in BI tools, which often misinterpret business terms or operate outside governance policies. In fact, these can be confidently and convincingly wrong.

### 2. Agents That Understand, Reason, and Explain
Agentic analytics is more than query generation. D3 agents can explore trends, suggest root causes, recommend next best actions, and most importantly, explain their logic and assumptions
That last part is key. In an enterprise context, trust is everything. D3 doesn’t just show you an insight. It shows you how it got there with the semantic SQL query, metric definitions, and context—all fully explainable.

### 3. Built to Act, Not Just Analyze
The most popular BI tools available today were built to visualize. Agentic analytics platforms are built to integrate. With D3, agents don’t live in isolation. They can participate in your workflows, trigger actions in external platforms via MCP, and work alongside other agents via A2A. It’s not just about seeing the data. It’s about doing something with it in real time.

## Agentic Analytics in Action
Cube D3 is not just faster; it’s transformational. Let’s say your VP of Sales asks, “Why did revenue from the West Coast spike in Q3?”

In a traditional BI tool, you would:
1. Open a dashboard, but which one?
2. Filter by region and time
3. Hunt through dimensions and drilldowns
4. Maybe identify a few contributing factors
5. Possibly export the data and explain it in email or PowerPoint

With D3, a human simply asks the question into the Analytics Chat Interface. The AI Data Analyst:
1. Interprets the question using business logic from the semantic layer
2. Generates a governed semantic SQL query
3. Returns a chart and explanation within seconds
4. Offers follow-ups: “Would you like to see the top contributing SKUs?”
5. Suggests next steps: “There was a price drop in July—should I compare impact across other regions?”

And the shift isn’t only for data analysts and business users. Now engineering workflows can be completed with fewer errors and faster delivery, providing more time for data engineers to focus on strategic work.

Traditional data engineering means:
1. Writing SQL transformations by hand.
2. Managing models across tools.
3. Waiting for pull requests to deploy.
4. Chasing down metric drift.

With D3, you describe what you want. The AI Data Engineer:
1. Builds and validates the transformation logic.
2. Updates the semantic model.
3. Flags dependencies and impact.
4. Documents everything—automatically.

## The Bottom Line
Modern analytics served us well, but the world has changed with the fast pace of AI innovations. What we need now is something smarter and more aligned with how people actually work.

Agentic analytics brings the next leap because it:
- Understands natural language
- Automates trusted insights
- Enforces semantic governance
- Integrates across tools and workflows
- Explains its decisions and acts on them

That’s what agentic analytics delivers and why it’s the new definition of modern. With Cube D3, your AI teammates don’t just help you analyze. They help you act, explain, and scale AI adoption confidently. Be among the first to gain Cube D3 access by [joining the waitlist](https://learn.cube.dev/cube-d3-early-access?utm_source=cube&utm_medium=blog&utm_content=d3%20campaign%20blog) and upgrading the data and analytics lifecycle for your data teams.


Why Agentic Analytics Is the New Modern Analytics


For the last two decades, dashboards have defined the way organizations engage with data. From real-time sales performance to executive KPIs, the modern BI stack has trained us to visualize everything. We built beautiful charts, fast queries, and interactive filters. But in the process, we forgot something important. Insight isn’t the end of the workflow. Action is.

As agentic AI reshapes the analytics landscape, one truth is becoming clear. The future of data workflows isn’t dashboards. It’s decisions.

## The Dashboard Plateau
At first, dashboards were revolutionary. They democratized data access and replaced static reports with self-service exploration. But over time, they became cluttered, overwhelming, and reactive. We created more dashboards than we could manage. And instead of clarity, many users got lost in a maze of tabs, filters, and conflicting charts.

Ask any analyst and they’ll tell you BI adoption has plateaued. Most dashboards have a few power users, and a long tail of stakeholders who rarely log in. They don’t want data for data’s sake. They want direction. They want to know: What changed? Why did it happen? And what should I do about it?

Dashboards are great at presenting data. But they’re bad at explaining what’s significant, identifying patterns or anomalies, recommending actions, and following up on results. In other words, dashboards surface information, but they don’t drive decisions. As business moves faster and complexity increases, waiting for someone to interpret a chart is no longer scalable.

## Enable a Decision-Centric Workflow
Cube D3's AI data agents, when integrated into the analytics process, transform how data is delivered, consumed, and automated. Instead of just surfacing a KPI, they can:
- Detect deviations from expected performance
- Investigate potential causes
- Suggest possible next steps
- Automate routine follow-ups or validations

This is the shift from reporting to reasoning. For example, imagine seeing not just a revenue dip, but an AI-generated explanation in plain language:

> “Revenue in Region A fell 9% last week, driven by a drop in conversion from channel X. This coincides with a campaign pause noted in the CRM. Would you like me to validate the attribution or notify the marketing lead?”

That’s not a dashboard. That’s a decision support system.

## From Metrics to Motions
At its best, analytics doesn’t just tell you what happened. It should propel you toward what to do next. That requires:
- A shared understanding of definitions (so everyone agrees on the numbers)
- Contextual awareness (so the AI knows what’s normal vs. not)
- Autonomy (so some steps can be taken without waiting for human intervention)
- Guardrails (so trust, governance, and explainability stay intact)

This is why the next generation of analytics tools won’t look like dashboards. They’ll look like collaborative workspaces, powered by AI agents who understand business logic, trigger actions, and provide explainable recommendations.

## The Role of the Universal Semantic Layer
None of this vision is possible without a strong semantic foundation. These decision-centric workflows require Cube Cloud's universal semantic layer. It is used to define business logic, ensure consistency across tools, and govern how data is accessed.

When Cube D3's AI agents reason using Cube Cloud's universal semantic layer, they act both quickly and accurately. They’re grounded in the same definitions other teams use. They inherit access controls. And they can explain every recommendation they make. This means that you get the same answers across AI, BI, spreadsheets, and embedded analytics.

The dashboard may still exist, but it’s no longer the end product. It’s the canvas. The real output is the decision, made faster and with more confidence. Consider what this might look like in practice:  
- A marketing analyst asks: “Are there any channels underperforming this month?”
- The AI Data Analyst agent detects a drop in return on ad spend in one campaign, investigates spend trends, compares to benchmarks, and suggests pausing the campaign.
- The analyst approves, and the system updates the task in the campaign planning tool.

No dashboard was opened. But the insight happened. And more importantly, so did the decision.

## Action Is the New Insight
In the agentic analytics era, the measure of a great analytics system won’t be how many dashboards it has. It will be how many decisions it drives. The future isn’t about more charts. It’s about fewer steps between question and action. And that future is already arriving in the form of AI agents built to reason, explain, and act.

So ask yourself: Is your data stack optimized for dashboards? Or for decisions? [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=future-of-data-workflows-blog) to learn how Cube Cloud and Cube D3 help you make smarter decisions and take action faster with trusted data.


The Future of Data Workflows Isn’t Dashboards. It’s Decisions.


AI has entered the enterprise, but not in the way most imagined. Instead of a single, all-knowing assistant managing everything from contracts to forecasts, companies are realizing a new harsh truth. Generalist AI falls short in specialist environments.

And so, a new trend is taking shape: the rise of domain-specific AI agents and assistants that deeply understand the workflows, terminology, data structures, and logic of a particular business function. These are not general-purpose chatbots, but digital teammates that know what your enterprise data teams need.

## Why Generalist AI Isn’t Enough
Most enterprise AI projects start with a vision of simplicity: ask a question in natural language, and get an answer from your data. In theory, this unlocks efficiency and insight. In practice, generalist AI tools often misinterpret the request, pull from the wrong data, or generate outputs that are directionally correct but operationally useless.

Why? Because context matters. A generalist AI may know that “conversion rate” is a metric, but it doesn’t know how your company defines it. It may be able to run a SQL query, but not understand which joins are needed, which tables are canonical, or which filters match your board-approved KPIs.

In high-stakes business environments, close enough isn’t good enough. Teams don’t need ideas; they need answers they can act on.

## The Value of Domain Understanding
Now consider a domain-specific AI agent—one built to support, say, a data analyst. It understands common analyst tasks: running time comparisons, slicing metrics by segments, generating dashboards, writing explainable commentary, and flagging anomalies.

It doesn’t need retraining for every task, because it already knows the patterns. It understands which metrics are shared across the organization. It knows which filters are typically applied. It can explain not just the number, but why the number matters.

This is about relevant intelligence. It’s about building AI systems that work with data just like you do in the language of your business.

## Examples in the Enterprise
We’re already seeing this shift play out. Data engineers are deploying AI to validate pipelines, identify schema mismatches, and refactor queries. Finance teams can use AI to reconcile numbers, generate variance reports, and surface anomalies, not just answer generic budget questions. Customer support leaders can use AI to detect recurring complaint patterns and escalate root causes, not summarize chats. These aren’t general AI tasks. They require AI agents with domain context and the ability to reason within constraints.

## The Infrastructure Behind Domain-Specific AI
Building domain-specific AI isn’t just about training a model differently. It requires a different architecture. That's why we built [Cube D3](https://cube.dev/product/cube-d3), the trustworthy agentic analytics platform.
- __Semantic foundation__: Domain agents must be grounded on consistency found in [Cube Cloud](https://cube.dev/product/cube-cloud), the universal semantic layer that defines metrics, dimensions, and data relationships.
- __Governance-first access__: They need to enforce role-based data access policies by default, not as an afterthought, across every data consumer. 
- __Explainability and auditability__: Every action must be logged and explainable, especially when decisions are made autonomously. You can inspect and audit every agent's decisions and actionsi in Cube D3.
- __Interoperability__: Domain agents must work across tools, whether answering in Slack, annotating dashboards, or integrating into CI/CD pipelines. Cube D3 integrates via A2A and MCP.

With these building blocks in place, Cube D3 doesn’t just assist. It operates alongside your team, within your rules, and in service of your business goals.

## Why This Matters Now
Enterprise leaders are growing wary of one-size-fits-all AI. After the initial excitement, they’re asking tougher questions:
- Can we trust the outputs?
- Will this integrate with our stack?
- Who owns the logic?
- How do we scale without sacrificing control?

Cube D3's domain-specific AI agents offer better answers to these questions because it’s designed for the way real data teams work. It doesn’t replace people. It extends them by automating what’s tedious, accelerating what’s manual, and enhancing what’s strategic.

## Conclusion: Teammates, Not Tools
The most successful AI deployments in the enterprise won’t be general copilots. They’ll be domain-specific AI agents that act like digital teammates that are always available, always consistent, always explainable. 

They won’t just process data. They’ll understand it. They won’t just answer questions. They’ll follow through. And they won’t just live in a chat box. They’ll integrate into workflows, learn over time, and drive real outcomes. 

Together, Cube Cloud’s universal semantic layer and Cube D3's domain-specific AI agents help you  scale your data teams' capacity and productivity without increasing headcount. Join the [waitlist for D3](https://learn.cube.dev/cube-d3-early-access?utm_source=cube&utm_medium=blog&utm_content=d3%20postlaunch%20blog1). We will gradually roll out access to users throughout the summer, with plans for general availability in the fall.


Why You Need Domain-Specific AI


Cube D3, our-first party agentic analytics platform, is here. There are two great blogs by my colleagues [Artyom and Pavel](https://cube.dev/blog/announcing-cube-d3) and [David](https://cube.dev/blog/unleashing-agentic-analytics-with-cube-d3) that will give you all of the information about what exactly D3 is, how you can get ahold of it, and why we built it. If you haven’t read those first, I’d encourage you to stop right here (please come back!) and read those. This will make a lot more sense with that background information.

With that warning I’m sure you all read the other posts, but for a quick refresher, Cube D3 is an agentic analytics platform powered by the Cube semantic layer. It represents an evolution of Cube, in which we are now shipping an analytical interface for users to interact with, in addition to the other core pieces of the Cube Cloud platform such as semantic data modeling, access control, caching, and our comprehensive suite of API endpoints. Prior to this, Cube was a headless platform, and in fact if you’ve followed Cube long enough you might remember that we marketed on the phrase “headless BI” in the very early days. 

In fact, Cube has always existed in the middle of many technologies. Whether those are our data source partners from which we read data, our hyperscaler partners whose platforms we sit on top of, and our BI and spreadsheet partners that users interact with - Cube has always been a part of a larger ecosystem. That’s the fun, and rewarding part of developing the partner motion here at Cube. A key belief at Cube is in the interoperability and openness of our software. This belief has enabled us to grow our partner ecosystem to be larger than that of any other semantic layer. We want to enable our customers to arrange the pieces how they see fit to best support their goals.

The introduction of Cube D3 as a first-party analytical interface doesn’t change anything about this. Cube will remain an open platform that continues to introduce integrations for the technologies that our customers and partners request. 

If you take a deeper look into the architecture of D3, you can see this at play. At launch, D3 will support LLM inference from our major partners at Snowflake, Databricks, Amazon, Microsoft and Google. We will add additional inference partners as requested by our customers. D3 also supports data from all of our existing data source partners supported in Cube Cloud. 

![](https://ucarecdn.com/256a4081-f391-4df0-9783-8b91698e545d/)

As we launch Cube D3, and present our take on where the future of agentic analytics is going, I look forward to collaborating with all of our partners - ISV, hyperscaler, and consulting partners to drive value for our joint customers. 

We will gradually roll out access to users throughout the summer, with plans for general availability in the fall. Join the [D3 waitlist](https://learn.cube.dev/cube-d3-early-access?utm_source=cube&utm_medium=blog&utm_content=d3%20partner%20blog) today.


Cube Cloud, Headless No More? 


Data is everywhere, and making sense of it is more critical than ever. Yet, organizations continue to face challenges with increasing data complexity, governance hurdles, and the difficulty of providing unified access to insights. While traditional Business Intelligence (BI) tools have benefited from semantic layers, bridging the gap between complex data structures and business insights often still requires significant technical expertise.

The rapid advancements in Artificial Intelligence (AI), particularly Large Language Models (LLMs), offer a transformative opportunity for data analysis. However, for AI agents to deliver reliable and trustworthy insights, they need to accurately interpret and interact with corporate data. This is precisely the problem Cube Cloud's new D3 agentic analytics platform is designed to solve. D3 leverages the power of Cube's robust semantic layer to empower both data consumers and data stewards with augmented self-serve capabilities.

## The Essential Role of the Semantic Core
At the heart of D3 is Cube's semantic layer. For AI agents to be effective, they need more than just raw data or database schemas. They require a foundational understanding of the business context, terminology, and the intricate relationships within the data. The semantic layer serves as this crucial structured bridge between complex data sources and business requirements. It transforms the technical language of data into the understandable vocabulary of the business, much like a Rosetta Stone translates ancient text.

The semantic layer provides a single source of truth for business metrics and dimensions, ensuring consistent definitions and reducing ambiguity. By embedding metadata and standardizing business logic, it offers the deep contextual understanding necessary for AI agents. This layer defines concepts, relationships, and rules that guide agents in interpreting user queries and generating accurate results. Without this governed, business-friendly layer, AI agents querying raw data directly are prone to errors, miscalculations, and "hallucinations".

Cube's semantic layer includes components like metadata repositories, schema mapping, taxonomy/ontology management, and robust query engines. It embodies the principles of a knowledge graph, allowing D3's agents to grasp the business relevance of data. Critically, the semantic layer includes a compiler that translates high-level business requests into correct and optimized SQL queries, offloading this complex task from the AI agent and drastically reducing error risk. This approach is fundamentally superior to solely relying on text-to-SQL methods for enterprise data.

## How D3 Works: Agentic Analytics Powered by Semantics
D3 is designed as an agentic analytics platform part of Cube Cloud. Its core idea is to allow users, regardless of their SQL knowledge, to interact with data using natural language. The platform augments users with analytics agents grounded in Cube's semantic layer to eliminate technical bottlenecks, enabling rapid, independent data exploration and driving insight velocity.

## Key Components: Agents, Spaces, and Rules
D3 introduces several key components to enable this agentic analytics experience:

![](https://ucarecdn.com/256a4081-f391-4df0-9783-8b91698e545d/)

- Analytics Agents: These are the AI-powered entities that assist users. They search the semantic model and can learn from experience and data model context. They support the selection of various LLMs, including the ability to Bring Your Own Model (BYOM). Agents can be restricted to specific data views for enhanced security and focus.
- AI Data Analyst: This agent is specifically designed to assist Data Consumers. It creates Semantic SQL queries, visualizations, and data apps. Results are provided in the chat interface as Semantic SQL Tool Call Messages (SSTCMs). SSTCMs are immutable but can be opened in the Data Explorer for further investigation.
- AI Data Engineering Agent: This agent supports Data Stewards. It helps in creating and optimizing semantic models, such as building a model from existing data marts or adding measures and dimensions.
- Agent Spaces: These are logical groupings used to manage agents and related resources. Spaces support a role-based permission model for simplified management and facilitate the creation, viewing, and deletion of agent groups.
- Rules: Defined guidelines within a space manage agent behavior and data interaction. This includes "always rules" and "agent requested rules". Establishing rules is crucial for guiding the AI on how to query specific data points, like snapshot measures.
- Certified Queries: These are SQL queries that have been reviewed and approved by admins, which agents can use within a specific space.

Other key components include the Analytics Chat Interface (for natural language interaction), the Data Explorer (for interacting with SSTCMs and Reports), Reports (saved analytical outputs derived from SSTCMs), and the Data Assets Pane (listing available semantic views, reports, and data source tables).

![](https://ucarecdn.com/9e3bfded-588c-44da-893f-589bed4a7fe3/)

## Using and Setting Up D3
The D3 experience is designed around an interactive chat interface and the Data Explorer.

__For Data Consumers__: Users can start by typing analysis requests in plain language into the chat interface. The AI Data Analyst generates queries and visualizations, presenting results as SSTCMs in the chat. Users can then open SSTCMs or Reports in the Data Explorer to view the underlying query, results, and visualizations. The Data Explorer allows users to modify the SQL query, run it, and send the updated query back to the chat to refine their analysis or provide feedback to the agent. Valuable results can be saved as Reports, which can include names, descriptions, and context, and can be shared. The Data Assets Pane provides navigation to available assets.

__For Data Stewards__: The AI Data Engineering Agent assists in creating and optimizing semantic models, potentially generating YAML code for cubes and views from existing tables.

__For Admins (Setup and Management)__: Access the Admin Panel via the Main Menu sidebar. Here, you can manage Users (viewing, changing roles), Global Settings (including the BYOM section to configure custom AI models by specifying name, provider, model, and potentially access keys - note that MCP server settings are coming soon), Agent Spaces (creating, viewing, and deleting spaces), manage Certified Queries within spaces (viewing, deleting), and manage Rules within spaces (adding rules with type, prompt, and description). Admins also manage individual Agents(creating agents by name, model, and space; deleting agents; clearing chat history) and can restrict agent visibility to specific views in the agent settings.

For initial customers, the Cube team will provide guided setup, collecting views or tables and sample questions, enabling D3, and scheduling a demo. A recommended onboarding for general availability involves the Platform Admin using the AI Data Engineer to create the initial model and creating verified reports for context and examples.

## Availability
D3 is an agentic analytics platform that is part of Cube Cloud. It is being rolled out, with the initial focus on supporting existing and new Cube Cloud customers via a guided process.

## Release Features & What's Next
The initial release introduces core D3 capabilities, including features available in public preview:
- Core platform functionality: settings, users, agents and spaces management.
- AI Data Analyst capabilities.
- Analytics Chat interface.
- Data Explorer & Reports Management.
- Semantic Model Development assistance via the AI Data Engineering Agent.
- Data Assets Navigation panel.

But this is just the beginning. We are actively developing exciting new features, including those planned for future releases:
- Reports sharing capabilities.
- Interactive data apps.
- Pro-active semantic model development suggestions from agents.
- Structured Queries interface within the Data Explorer.
- Future support for AI Data Scientist capabilities.

## Conclusion
The convergence of AI and BI is reshaping how organizations interact with data. Cube D3 stands at the forefront of this shift by combining agentic AI with the power of a robust semantic layer. By providing a governed, contextualized bridge between complex data and business users, D3 empowers organizations to achieve greater data accessibility, accelerate insight generation, and ensure the trustworthiness of AI-driven analysis. This approach positions D3 as a key component for unlocking the full potential of AI in data analytics workflows.

We will gradually roll out D3 access to users throughout the summer, with plans for general availability in the fall. Join the [D3 waitlist](https://learn.cube.dev/cube-d3-early-access?utm_source=cube&utm_medium=blog&utm_content=d3%20technical%20blog) today.


Unleashing Agentic Analytics with Cube D3


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


AI tools have never been more accessible or more distrusted. Across enterprises, data and analytics leaders are deploying LLMs, chatbots, copilots, and AI agents to deliver insights faster than ever. Yet when business users receive those insights, the reaction is often skepticism, not action. You’ve heard questions like these before:
- “Where did this number come from?”
- “Is that calculation using the right filters?”
- “Why doesn’t this match our dashboard?”

There’s too much guesswork in data and analytics when questionable data raises more questions than answers. In many cases, the answers are technically accurate, but if users don’t trust them, they won’t act on them. When AI becomes just another tool to double-check or ignore, its value vanishes. So why don’t business users trust AI? And what can we do about it?

## The Trust Gap Isn’t Technical—It’s Human
Most business users aren’t worried that the AI is broken. They’re worried that it doesn’t understand their world. They’ve been burned before by dashboards that misrepresented the business, reports built on outdated logic, or KPIs that didn’t match what the CFO presented. 

When that history is layered on top of a black-box system that produces fast answers but not explanations, it’s no surprise that trust erodes. AI doesn’t have to be wrong to lose trust. It just has to be unexplainable. Most AI systems today provide answers without showing their work.

## Confidence Comes from Context
Imagine this: you ask an AI tool, “What was our Q1 revenue in the Northeast region?” It responds: “$12.7M.” Is that good? Is that net or gross? Is it aligned with what Finance reported? What filters were applied to get that number? So many questions, instead of the answer.Without answers to those questions, the output feels less like insight and more like a guess. 

When AI can explain itself, meaning that it can say, “This figure comes from the ‘Sales_Transactions’ table, filtered by ‘Region=Northeast’ and ‘Quarter=Q1’, using the ‘Net_Revenue’ measure as defined in our universal semantic layer”—something changes.Now, it’s not just a number. It’s an auditable statement, becoming a decision-making asset and most importantly, it’s something a business user can trust.

## Why Explainability is the Real Key to Adoption
Many enterprise AI initiatives focus on accuracy. They should, but accuracy without explainability is fragile. The first time something looks off, users disengage. Trust is built when:
- Users can see where the data came from
- Definitions match across tools and departments
- Metrics are aligned with executive reporting
- AI doesn’t just answer, but explains how it got there

This is especially true for users outside of the data team, such as finance leaders, operations managers, marketers. These are the people who turn insights into actions, but they won’t act if they don’t feel confident.

## Closing the Trust Gap with a Universal Semantic Layer
A universal semantic layer helps AI move from opaque to explainable. By defining key metrics, dimensions, and joins in a centralized, governed layer, the universal semantic layer becomes a reference point for all data interactions, including AI.

When AI tools are powered by a semantic layer, they use shared definitions that have been approved by stakeholders. They can point to exactly how a metric is calculated. They respect role-based access controls and data masking. They offer lineage, so users know how the answer was derived

Instead of guessing, AI systems are grounded. Instead of improvising, they’re consistent. And instead of sounding like magic, they sound like a well-informed analyst who’s read the playbook.

## Empowering Business Users Through Transparency
Transparency doesn’t mean exposing every line of code. It means designing AI outputs to anticipate user skepticism:
- Annotate results with sources and filters
- Offer “drill down” options to show calculation steps
- Allow users to trace answers back to the metric definition
- Embed contextual help that reinforces shared logic

When business users feel like they’re in control and not at the mercy of a black box, they engage. They ask more questions. They move faster, and they stop feeling like they’re playing defense against bad data.

## What Trustworthy AI Looks Like in Practice
A sales leader asks: “How did we perform across our top three regions last month?”
A trustworthy AI agent responds with:
- A visual breakdown of revenue by region
- A callout explaining that the metric is based on ‘Net Revenue’ as defined by Finance
- A note confirming that the filters applied match those used in the latest board report

An option to view the SQL logic or underlying semantic definition
The result? The sales leader doesn’t forward the report to an analyst for double-checking. They use it in their next meeting. That’s the moment AI starts delivering value.

## Trust Is Earned With Explainability
Business users don’t need their AI to be magical. They need it to be understandable. When AI systems are transparent, consistent, and grounded in a shared semantic foundation, trust becomes a feature, not a missing piece. The next generation of enterprise AI won’t win by answering faster. It’ll win by answering better because it shows its work. [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=users-dont-trust-ai-blog) to learn how Cube Cloud delivers trusted data with full transparency.


Why Business Users Still Don’t Trust AI


AI is rapidly transforming the landscape of data work, pushing data teams beyond traditional roles to become strategic partners within their organizations. The advent of AI, particularly agentic AI, is ushering in a new era for data teams, moving from reactive data provisioning and analysis towards more proactive, insightful, and even autonomous capabilities. This evolution is powered by AI tools that streamline workflows, enhance data accessibility, and enable more sophisticated data experiences. An AI-first data team leverages these technologies not just to answer questions, but to build systems that proactively contribute to business success, starting with conversational interfaces and evolving towards intelligent agents.

## The Foundation: AI Enhancing Data Team Efficiency
At its core, AI helps data teams work more efficiently by automating routine and time-consuming tasks, freeing up valuable human resources for more strategic activities. Traditionally, data preparation, including collecting, cleansing, and integrating data from disparate sources, consumes a significant portion of an analyst's time. AI addresses this through automated data structuring, assisting with tasks like writing data transformation models, data extraction, and data profiling to ensure consistency and accuracy. AI-powered automation can handle data validation, cleansing, and deduplication, reducing manual effort and minimizing errors.

Beyond preparation, AI provides predictive insights and recommendations by analyzing historical data to forecast trends and identify patterns. This capability enables data teams to make more informed, data-driven decisions. AI can also analyze and optimize business logic, ensuring that data-driven decisions align with organizational goals and compliance requirements. Furthermore, AI simplifies the often challenging process of integrating data from legacy systems by automating extraction, transformation, and modeling, enabling seamless data flow to modern platforms.

The benefits for data teams leveraging AI are numerous, including increased data accuracy, improved decision-making, enhanced user experience, and cost reduction by automating processes and minimizing errors. AI data pipelines, for instance, streamline the entire data workflow, offer real-time data processing, and are built for scalability, allowing businesses to handle massive data volumes as needed.

## The First Step: Natural Language Chatbots
A key initial application of AI for data teams is enabling natural language querying through chatbots or conversational interfaces. This empowers non-technical users across the organization to ask data questions in plain language, lowering the barrier to entry for working with data. However, enabling AI to reliably answer questions based on business data is not as simple as connecting an LLM to a database.

This is where the universal semantic layer becomes essential. The semantic layer acts as a structured bridge between raw data sources and business requirements. It is the foundation for trustworthy AI access to data using LLMs, providing the necessary context and governance to reduce errors and hallucinations that can occur when LLMs attempt to generate raw SQL directly on database schemas. Without a semantic layer, it's far too easy for an LLM to hallucinate or get small things wrong.

The semantic layer provides a governed layer of business logic that AI can understand and apply. It allows teams to define dimensions, metrics, relationships, and hierarchies in plain business terms, creating a shared language between data, AI, and users. This is crucial because raw data often lacks intrinsic meaning, and different teams or AI models might interpret it differently. By connecting AI tools to a governed semantic model, a system like Cube Cloud ensures that vague human language is translated into precise, context-aware queries using the definitions, filters, and calculations the business already trusts.

The architecture supporting natural language querying often involves several components leveraging the semantic layer:
- __Semantic layer__: Provides declarative metric definitions, data modeling, and metadata.
- __Large language models__: Used for natural language processing, generation, and interpreting results.
- __Retrieval Augmented Generation (RAG)__: Extends internal business knowledge and context for the LLM.
- __Semantic Catalog__: Allows users and potentially AI to search, understand, and reuse trusted data products.
- __API and SQL Transpiler__: Compiles user prompts into queries against the semantic layer (like Cube's API), which then deterministically generates SQL. The constrained nature of API requests, compared to raw SQL, makes it less likely for the LLM to generate technically valid hallucinations.
- __Query execution and planner engine__: Runs the generated queries and returns results.
- __Cache layer__: Optimizes query performance.
- __Access control & governance__: Manages security and permissions.

This first step provides significant value by democratizing data access and making data exploration easier for non-technical users.

## Evolving Towards Agents: Beyond Reactive Answers
While chatbots are valuable for answering specific data questions, the vision for AI-first data teams extends beyond reactive querying to building more proactive and action-oriented systems – AI agents. These agents aim to go beyond merely responding to user prompts by leveraging data insights to perform tasks, trigger workflows, or provide unsolicited, relevant information to help the business.

These are the capabilities and systems that lay the groundwork for such a future:

- __AI-Powered Data Quality Management__: AI actively works on data to identify anomalies, inconsistencies, and errors, and in some cases, automate rectification. This is an example of AI taking action directly on the data layer, ensuring data reliability which is critical for any agent relying on that data.
- __Exploratory Data Analytics Enhanced by AI__: AI automates data preprocessing, data modeling, model training, and can facilitate continuous learning for models. While EDA is often seen as analysis, the automation and continuous learning components enable AI systems that can constantly monitor data, detect patterns (anomalies, trends), and generate insights that could inform an agent's actions.
- __AI Copilots__: Copilots assist data practitioners in building data models and defining metrics. AI can actively help users do something (build models, pipelines) rather than just answering questions about existing data. This suggests a path towards agents that assist or automate complex data tasks.
- __Enhancements to Conversational AI__: For example, an agent might deliver insights or recommended actions directly into a team's communication channel.

An AI agent, built on the foundation of a governed semantic layer, could leverage these capabilities. Instead of simply answering "What cities have the most sales?", an agent could:

- Proactively monitor sales data for anomalies or trends using AI-powered analytics pipelines.
- Alert the relevant team in Slack if sales in a key city drop below a threshold, delivering the insight directly.
- Suggest a potential cause based on correlated data (e.g., marketing spend in that region) as identified by the AI pipeline's analysis.
- Potentially trigger a workflow in an integrated business system (like a CRM or marketing platform) based on the detected pattern and insights.

This shift from reactive chatbot to proactive agent requires the AI system to not only understand the data (context from the semantic layer) but also to apply business logic, perform complex analysis, and integrate with other systems, capabilities facilitated by AI data pipelines and the semantic layer's role as a central data access point.

## The Horizon: Autonomous Agents
The ultimate vision for AI-first data teams involves autonomous agents – AI systems that can independently perform complex data-driven tasks and potentially initiate actions without direct human prompting. While this stage is still evolving, the sources hint at possibilities:

- The idea of AI generating entire dashboards autonomously based on high-level requests.
- AI models continuously improving and adapting as new data becomes available through continuous learning loops in AI pipelines.
- AI taking over lower-level tasks, enabling humans to focus on strategy and decision-making, suggesting a future where AI handles routine data-related actions independently.

In this advanced stage, the semantic layer remains paramount. For autonomous agents to be trustworthy and effective, they must operate on a consistent, governed, and reliable data foundation. The semantic layer provides the necessary context, business logic, and access controls to ensure that autonomous actions are based on accurate, compliant, and business-aligned insights. Traceability and auditability, provided by the semantic layer, become even more critical when AI systems are taking actions independently.

Human oversight and trust remain crucial. Even with autonomous agents, humans need to understand why AI is taking a particular action and be able to verify the underlying data and logic. The semantic layer helps make AI more predictable and interpretable by embedding business understanding into AI interactions.

## The Essential Role of the Semantic Layer and Governance
Throughout this evolution, the universal semantic layer is the critical missing piece for scaling AI-enabled analytics and moving from simple chatbots to sophisticated agents and beyond. It provides the context and constraint that LLMs need to reliably interact with business data, performing far better than methods that attempt text-to-SQL directly on database schemas.

A semantic layer like Cube Cloud ensures consistency and accuracy by defining metrics and business logic once and making them available across all downstream applications, including various AI tools. This eliminates conflicting numbers and builds trust in AI outputs, which is essential for user adoption and critical for high-stakes decisions driven by AI.

Furthermore, the semantic layer provides traceability and auditability. Every AI-generated response or action can be traced back to the exact data model, metric definition, and data source, transforming AI from a potential black box into a transparent system. It also centralizes and enforces data access controls and governance rules, ensuring that AI systems operate within defined boundaries, supporting compliance and security at scale.

AI Governance starts with Data Governance. You cannot govern AI outputs if the underlying data and business logic are not governed. Cube Cloud operationalizes AI governance by centralizing business definitions, ensuring traceability, and governing data access controls within the semantic layer, which feeds all AI interactions.

## Challenges and Lessons Learned
While the potential is vast, AI-first data teams face challenges, many of which echo the difficulties encountered scaling Business Intelligence initiatives. These include data quality issues, a lack of skilled personnel with AI expertise, and privacy concerns. Lessons from BI teach us that data access isn't enough without context and consistency, complexity overwhelms self-service, trust is fragile, and people and processes often lag behind technology. Scaling AI will be even harder than scaling BI if these foundational issues are not addressed.

Addressing these challenges requires investing in data cleaning and preprocessing, providing training for team members, implementing robust data governance practices, and adopting a holistic approach that balances technology with the right people, training, and governance structures. A universal semantic layer is crucial here, as it abstracts complexity and provides the necessary governance and context to make data usable for both humans and AI.

## Conclusion
The journey for AI-first data teams begins with leveraging AI to enhance core data workflows and introduce user-friendly interfaces like natural language chatbots. These conversational tools make data accessible to a wider audience by translating natural language into structured queries via a governed semantic layer. Building on this foundation, teams can evolve towards creating AI agents that go beyond simple question-answering. These agents, powered by AI data pipelines and leveraging the semantic layer's context, can perform advanced analytics, detect patterns, integrate with business systems, and potentially trigger actions or provide proactive insights. The future vision extends to autonomous agents capable of performing complex data tasks independently.

Crucially, this entire evolution hinges on establishing a strong, governed data foundation. The universal semantic layer is the essential component that provides the necessary context, consistency, governance, and traceability for AI to reliably understand and act upon business data. It ensures that AI systems, whether simple chatbots or future autonomous agents, are grounded in trustworthy business logic and deliver outputs that are accurate, auditable, and aligned with organizational standards.

AI is transforming the role of data teams, making them more strategic and impactful. By building on the right data foundation, centered around a universal semantic layer, organizations can confidently navigate this transformation, moving from enabling data curiosity to enforcing confidence in AI-driven decisions and actions. The lessons from the BI era teach us that success lies not just in technology, but in ensuring data is trusted, accessible, and understood by everyone and every system that uses it.

[Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=rise-data-ai-agents) to learn more about how AI can transform your data stack.


The Rise of AI Data Teams: From Chatbots to Autonomous Agents


One of the most compelling benefits of the universal semantic layer is its ability to reduce work across teams. Without clear visibility into existing assets, organizations often experience:

- Multiple analysts creating similar dashboards
- Engineers building overlapping data models
- Inconsistent definitions of key business metrics
- Redundant data transformation pipelines

Cube already directly addresses these issues by providing unified metrics in a governed location, so that you can model your data once, and deliver it anywhere. However, what about this visibility of the universal semantic layer beyond the code? It is important to make existing work visible and discoverable. This reduces the likelihood of duplicate versions being created by different engineering teams or by analysts and engineers separately.

Greater visibility can also lead to better collaboration between technical and business teams by providing a shared understanding of data assets.  Analysts can see what's already available, engineers can understand how their work is being used, and business users can see metric definitions and how they were calculated. 

## From Fragmentation to Integration
If you already are using Cube as the integration point between data sources and data consumers, by embedding catalog functionality within this layer, you create a natural discovery mechanism.

The integrated approach contrasts with the typical experience, where different roles utilize separate tools to access information about their data:

- Instead of jumping between systems, analysts, engineers and business users can access what they need in the same place.
- Instead of being limited to seeing the universal semantic layer on its own, users see connected data assets and their relationships.
- Instead of struggling with outdated documentation, users access self-updating metadata
- Instead of wondering about the impact of a change, engineers can visualize dependencies and downstream effects for some of the most popular BI.

In today's complex data environments, the common refrain "I know that data exists somewhere" reflects the frustration many data consumers experience daily. Similarly, data engineers often worry that their pipeline updates might have unintended consequences that they aren’t aware of. If this resonates with your experience, let's explore these challenges, and how Cube's Semantic Catalog addresses them.

## Understanding the Catalog Challenge
The data landscape has become increasingly fragmented. Each component in the modern data stack—from data warehouses to BI platforms—generates its own metadata. This creates a complex web of information about data assets that are sometimes marketed as a ‘catalog’ feature, and sometimes not.

Your orchestrators, transformation tools, data warehouses, semantic layers, BI platforms, and ETL solutions all create metadata about the data they process. Traditional data catalogs then attempt to harvest this distributed metadata, and in doing so, generate even more metadata themselves!

This proliferation creates significant challenges for organizations:

1. __Metadata Fragmentation__: information about data exists in silos across multiple tools
2. __Maintenance Burden__: Keeping information current requires constant manual updates
3. __Persona-Specific Needs__: Different data users need different views of the metadata
4. __Discovery Difficulties__: Finding data asset becomes challenging as data volumes grow

It is both time-consuming and difficult for engineers and analytics engineers to look across many catalogs including: orchestrators, transformation tools, system catalogs like Salesforce, Iceberg, data platforms/lakehouses, and the list goes on. Meanwhile, business users and analysts struggle to find the data they need, often unaware of existing assets that could answer their questions. Poor discovery capabilities lead to inconsistent metrics, competing versions of the truth, and ultimately, diminished trust in data.

## Why The Universal Semantic Layer is the Ideal Catalog Location
Traditional data catalogs often attempt to be comprehensive, which ironically means they don't serve any specific user group particularly well. They're frequently too broad for analysts who need focused information, too disconnected from the workflow for engineers, and too technical for business users.

The universal semantic layer, by contrast, already serves as the natural bridge between technical implementation and business meaning. It has the ability to define business metrics and relationships in a way that's understandable to both technical and non-technical users. This makes it the ideal location for catalog functionality.

Several key advantages emerge from placing catalog functionality in the universal semantic layer:

1. __Production Integration__: The catalog exists within a component that's already maintained as part of regular engineering work
2. __Consistent Governance__: Users see only the data assets relevant to their needs and permissions, based on defined [data access policies](https://cube.dev/docs/reference/data-model/data-access-policies)
3. __Business Context__: Technical details like SQL definitions are presented alongside business definitions and context
4. __Shared Understanding__: All users work from the same consistent definitions and metrics

## Semantic Catalog: The Right Metadata in the Right Place
What makes Cube's Semantic Catalog different is not just what it does, but where it lives: directly in the universal semantic layer. Let’s take a look at some of the UI components:

### Self-Documenting & Always Current
Unlike traditional catalogs that quickly become outdated repositories of your data assets, the Semantic Catalog is self-documenting and up-to-date based on a schedule of your choosing.

![](https://ucarecdn.com/1c81dd6d-b85e-4037-980c-7436709a32f2/)

Previously, data engineering teams have had a different experience with data catalogs, which involve manual entry, duplicative work and eventually become stale. When engineers modify data models, the catalog reflects these changes without requiring additional documentation efforts. 

![](https://ucarecdn.com/cd7b420e-1c4a-4e3e-8985-edd3b8bc4682/)

### Unified Search
Many data professionals spend significant time searching for assets across multiple tools. The Semantic Catalog addresses this challenge by providing unified search capabilities across modeled data, downstream BI content, and upstream tables—all from a single interface.

![](https://ucarecdn.com/5f3e5bb0-ea38-4880-9456-9b944fa17cc0/)

This unified search capability is particularly powerful because it's contextual. When a user searches for a specific entity, like ‘orders view’, they can immediately see:
- What metrics and dimensions are associated with this entity, along with what type of column it is, the original data source name, and a description.
![](https://ucarecdn.com/921befc9-f746-4d95-ac7e-c12d14e33558/)

- Which upstream sources contribute to this entity - down to the source tables.
![](https://ucarecdn.com/eea887ba-44be-41c7-af65-6a74fe19e055/)

- What downstream BI assets (dashboards, reports, etc.) consume this entity
![](https://ucarecdn.com/24b21ca4-8b2a-43c4-8c73-4716e0c0eb04/)

- Details about a measure including your written description, a SQL definition, and other data facets.
![](https://ucarecdn.com/eb656edd-0b9e-468b-b414-90279dbc62cf/)

This contextual understanding accelerates the time to insight and promotes consistency across the organization. Instead of searching in separate locations, users can find everything they need in one place with a single search tool.

### Comprehensive Lineage and Impact Analysis
Perhaps the most valuable feature is the ability to visualize data lineage and explore downstream content. Before implementing changes, engineers can now identify which dashboards and reports might be affected—preventing situations where changes to seemingly unused tables disrupt critical reports.

The Data Graph visualization makes these relationships intuitive to understand, showing connections from source tables through the universal semantic layer to consumption points. This visual approach makes complex data relationships accessible even to less technical users.

## A Catalog Where Everyone Can Work
The philosophy behind Cube's Semantic Catalog embodies a fundamental shift: let people use a catalog where they all can work, rather than forcing them to have separate catalogs.

For Data Engineers, an orchestrator like Airflow or Dagster may be the best place for a metadata catalog. Every step of their pipeline and workflow can be seen through the orchestrator. For data analysts and data consumers in general, having metadata they either shouldn’t or can’t consume is superfluous. Data consumers don’t need visibility into the entire contents of a data lake. However, a data catalog only meant for them doesn’t provide the depth that data engineering would need. 

The approach of the Cube Semantic Catalog acknowledges the reality that different user personas interact with data in different ways and through different tools. When data teams must optimize resources, having catalog functionality integrated directly into the universal semantic layer offers both operational efficiency and cost effectiveness.

## Clarity Through Connection
Cube's Semantic Catalog represents a significant advancement in how organizations manage and discover their data assets. By embedding catalog functionality directly within the universal semantic layer, Cube has created a solution that addresses many of the fundamental challenges that have plagued traditional data catalogs.

Key benefits of this approach include:
- __Auto-refreshed metadata__ that updates automatically with data model changes
- __Unified search__ of assets across from source tables to consumption 
- __Clear visualization__ of data lineage and impact analysis
- __Reduced duplication__ through improved discoverability
- __Enhanced collaboration__ between technical and business teams

As data ecosystems continue to grow in complexity, solutions like the Semantic Catalog will become increasingly valuable. By integrating discovery into existing workflows and focusing on production data that matters, Cube has created a catalog that actually delivers on the promise of making data more accessible, trustworthy, and valuable.

We invite you to try the [Semantic Catalog](https://cube.dev/docs/product/workspace/semantic-catalog) and experience how it can improve data discovery. Stay tuned for more updates and enhancements as we continue to innovate and expand the capabilities. [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=semantic%20catalog%20blog) to learn more about Semantic Catalog.


Arynn Martin-Post

Cube Semantic Catalog: A Unifying Catalog Embedded in Your Universal Semantic Layer


Every enterprise analytics team knows the drill. A business leader asks a question—“How are we trending on customer retention this quarter?” An analyst pulls data, runs some calculations, builds a quick report. Days or even hours later, another stakeholder asks a variation of the same question. A second analyst gets involved. The report is recreated. The numbers don’t match. Confusion sets in.

Welcome to the world of ad hoc redundancy, where repeat questions create more than just extra work. They expose the structural inefficiencies baked into how most companies handle data—and why that’s a serious obstacle to scaling AI.

## It’s Not Just a Time Problem
At first glance, this might seem like a simple productivity issue. Redundant questions cost time, but the bigger problem is what they reveal. A number of factors, such as inconsistent definitions, a lack of shared logic, and weak institutional memory, are behind it.

When one analyst calculates retention using current month churn over last month’s active users, and another includes only subscription cancellations, the business ends up with two different truths. Not because either person did anything wrong, but because there’s no standard for what “retention” actually means.

This kind of misalignment isn’t new. It’s plagued BI efforts for years. But in the age of AI, the stakes are higher. Because now, the answers don’t just come from humans. They come from machines—fast.

## AI Without Memory is a False Efficiency
One of the promises of generative and agentic AI is speed. Ask a question, get an answer. But what happens when that answer isn’t grounded in a shared understanding of the business?
AI tools that lack a memory of organizational logic will generate responses based on the data they can access and the logic they infer. That means two users asking similar questions might get totally different answers. Worse, they might trust those answers, because the AI sounded confident.

Without shared definitions and reusable logic, AI creates the illusion of efficiency while quietly multiplying inconsistency. Every question becomes a new experiment in interpretation. Every answer adds to a growing backlog of reconciling what the system told one team versus another.

## Why Semantic Alignment Matters
To break the cycle of redundancy and confusion, enterprises need more than faster query tools. They need a consistent, semantic foundation.

A universal semantic layer acts as the memory of your organization’s data logic. It defines how metrics like retention, revenue, churn, or CAC are calculated and makes those definitions available to every data consumer, including AI agents.

When you centralize and share this logic, analysts stop reinventing the wheel. Business users get consistent answers across tools, and AI agents produce outputs that align with BI dashboards and spreadsheets. Most importantly, every stakeholder starts working from a single source of truth.

## The Compounding Cost of Inconsistency
The hidden cost of asking analysts the same questions twice isn’t just billable hours. It’s the erosion of trust. When executives see different numbers from different teams, they lose confidence, not just in the analysis, but in the entire data function.

That loss of trust has ripple effects. Strategic decisions get delayed or second-guessed. Teams resort to shadow systems like spreadsheets, and adoption of AI and BI tools stalls. Eventually, when AI gives the “wrong” number, the whole system gets blamed.

## The Way Forward: Institutionalizing Memory
To build truly scalable analytics and AI, enterprises need systems that remember. That means:
- Codifying business logic in a central semantic layer
- Training analysts to use shared definitions instead of writing bespoke SQL
- Configuring AI agents to inherit those definitions, not invent their own
- Auditing outputs across tools to ensure consistency

This isn’t just about making analysts more efficient. It’s about creating a data culture where the organization stops asking the same questions twice because the answers are already trusted, accessible, and explainable.

## Investing in Your Data Foundation
The future of analytics isn’t about doing the same thing faster. It’s about doing it once, and doing it right. When you invest in shared logic and semantic structure, every answer compounds in value. Each insight reinforces the next. If your team is answering the same question multiple times, don’t just look for a quicker way to do it. Look for a smarter way to stop needing to.

Because in the AI era, scale isn’t about adding more analysts or more dashboards. It’s about building institutional memory, so your humans and your machines can stop repeating themselves and start accelerating together. [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=hidden-cost-analyst-blog) to learn how Cube Cloud’s universal semantic layer provides consistency to every data consumer.


The Hidden Cost of Asking Your Analysts the Same Questions Twice


Today, AI systems often face a silent limitation: access. While models have become smarter, faster, and more capable, their ability to interact with real-world data and systems remains constrained by fragmented, bespoke integrations. Anthropic’s Model Context Protocol (MCP) introduces a bold new vision: a universal standard for connecting AI models to the world’s data and tools—seamlessly, securely, and at scale. In this blog, we’ll explore MCP at both a conceptual and technical level, examine its relevance to analytics and semantic layers, and share a practical code example for building an MCP server.

## What is MCP?
Imagine a world where AI assistants can seamlessly connect to any data source or tool you use, without needing custom integrations for each one. MCP aims to make this a reality by providing a universal, open standard for connecting AI systems with the vast amounts of data and capabilities that exist across different platforms. Think of it like a "USB for AI integrations", where a common interface allows various AI applications to plug into a multitude of tools and data sources. This eliminates the time-consuming and error-prone process of building custom code for each data connection.

## Inside MCP: A Detailed Explanation
MCP operates on a client-server architecture:
- __Hosts__: These are the AI applications that you interact with, such as the Claude Desktop app, an IDE with AI assistance (like Cursor), or a custom AI agent. Hosts contain MCP clients.
- __Clients__: These reside within the Host application and manage the connection to specific MCP servers. Each client typically connects to one MCP server.
- __Servers__: These are external programs that expose Tools, Resources, and Prompts via a standard API to the AI model through the client. They act as bridges between the MCP world and the underlying systems.

### Key Components of MCP Servers
1. __Tools (Model-controlled)__: These are functions that the LLM can call to perform specific actions, similar to function calling in other AI models. Examples include fetching weather data from an API or querying a database.
2. __Resources (Application-controlled)__: These are data sources that the LLM can access, akin to GET endpoints in a REST API. Resources provide data without significant computation or side effects. They serve as context for the AI.
3. __Prompts (User-controlled)__: These are pre-defined templates designed to optimally use tools or resources. Users can select from available prompts to guide the AI's interaction. However, the sources suggest that uptake of prompts and resources has been less significant so far, with __tools being the primary focus.__

### How MCP Works (Simplified Flow)
1. When a Host application starts, it initializes MCP Clients.
2. Clients discover the capabilities (Tools, Resources, Prompts) offered by the connected MCP Servers.
3. Based on the user's request, the LLM within the Host decides if it needs to use a Tool.
4. The Host directs the Client to send an invocation request to the appropriate Server.
5. The Server executes the requested action (e.g., calls an external API) and retrieves the result.
6. The Server sends the result back to the Client.
7. The Client relays the result to the Host, which incorporates it into the LLM's context to generate a final response.

### Communication between Clients and Servers
MCP servers can be built in various languages. Communication primarily occurs through:
- __stdio (Standard Input/Output)__: Used when the Client and Server run on the same machine, suitable for local integrations.
- __HTTP via SSE (Server-Sent Events) / Streamable HTTP__: For remote connections, the Client connects to the Server via HTTP, and the Server can push messages to the Client over a persistent connection. The protocol is evolving to use a more flexible Streamable HTTP transport.
- __JSON-RPC 2.0__: MCP uses JSON-RPC as the underlying message format for communication.

### Security and Trust
Given the potential for data access and code execution, MCP emphasizes __user consent and control__. Users must explicitly authorize data access and tool usage. The protocol also recommends robust consent flows, clear documentation of security implications, and appropriate access controls. Authentication for remote HTTP servers is mandated using OAuth 2.1.

## Short Code Example: Setting up an MCP Server for an API Tool (Python)
This example demonstrates a simple MCP server using the `fastmcp` library (mentioned in the sources) to interact with a hypothetical weather API.

```python
from mcp.server.fastmcp import FastMCP
import requests
import json

# Create an MCP server named "WeatherService"
mcp = FastMCP("WeatherService")

@mcp.tool()
def get_weather(city: str) -> str:
    """
    Retrieves the current weather for a given city using the weatherapi.com API.
    """
    api_key = "YOUR_WEATHERAPI_COM_API_KEY"  # Replace with your actual API key
    url = f"http://api.weatherapi.com/v1/current.json?key={api_key}&q={city}"
    try:
        response = requests.get(url)
        response.raise_for_status()  # Raise an exception for bad status codes
        weather_data = response.json()
        temperature = weather_data["current"]["temp_c"]
        condition = weather_data["current"]["condition"]["text"]
        return f"The current weather in {city} is {temperature}°C with {condition}."
    except requests.exceptions.RequestException as e:
        return f"Error fetching weather data: {e}"

if __name__ == "__main__":
    mcp.run()
```

### Explanation
1. We import the necessary libraries, including `FastMCP`.
2. We create an MCP server instance named "WeatherService".
3. We define a tool called `get_weather` using the `@mcp.tool()` decorator.
4. The tool function takes a city as input and makes a request to a hypothetical weather API.
5. The function processes the API response and returns a formatted string with the weather information.

To use this tool with a Claude Desktop app configured for MCP, you would need to:
1. Save this code as a Python file (e.g., `weather_server.py`).
2. Update the Claude Desktop app's configuration file (`claude_desktop_config.json`) to include this server, specifying its name and the command to run it (e.g., `python weather_server.py`).
3. Restart the Claude Desktop app.
4. Now, when you ask Claude a question like "What's the weather in London?", it could potentially invoke this `get_weather` tool (after you grant permission) to fetch and provide the information.

## Relevance of MCP to the Field of Analytics
MCP holds significant relevance for the field of analytics by:
- __Simplifying Data Access__: Traditionally, connecting AI models to various analytical data sources (databases, data warehouses, SaaS platforms) required building custom connectors for each. MCP standardizes this process, allowing AI-powered analytics tools and agents to __seamlessly access diverse datasets__ through a unified protocol.
- __Enhancing Performance and Efficiency__: By streamlining data access, MCP can lead __faster and more accurate responses__ from AI-driven analytics applicationsto . Direct connections to data sources, facilitated by MCP servers, can reduce latency compared to indirect methods.
- __Facilitating Agentic AI in Analytics__: MCP supports the development of __AI agents capable of performing complex analytical tasks autonomously__ on behalf of users. By maintaining context across different analytical tools and datasets, MCP enables these agents to execute multi-step workflows, such as querying data, performing calculations, and generating reports.
- __Broadening Applicability__: Unlike solutions limited to specific applications, MCP is designed to work __across all AI systems__ and data sources relevant to analytics. This universality makes it a versatile tool for various analytical use cases, from automated data exploration to AI-powered business intelligence.
- __Lowering Development Costs and Complexity__: By providing a standardized framework for tool use and data access, MCP can __reduce the development effort and complexity__ associated with building AI-powered analytics solutions. Developers can focus on the analytical logic rather than the intricacies of data integration.

## The Power of MCP and a Universal Semantic Layer
A semantic layer, like Cube (or the general concept of a semantic layer), provides a business-friendly abstraction of underlying data. It defines metrics, dimensions, and relationships in terms that business users understand, shielding them from the complexity of the physical data model.

MCP and a semantic layer can work together synergistically to enhance AI-driven analytics:
1. __Semantic Layer as Information Source for MCP Tools__: An MCP server could be built on top of a semantic layer. The tools exposed by this server could leverage the semantic layer's definitions to construct intelligent queries and access data in a business-aware manner. For example, an AI agent could ask, "What was the total revenue for the last quarter in the marketing channel 'Email'?", and the MCP tool, informed by the semantic layer, would know how to translate this business query into the appropriate data retrieval operations on the underlying data sources.
2. __MCP for Accessing Data Underlying the Semantic Layer__: Conversely, AI agents using MCP could directly access the data sources that the semantic layer sits on top of. While the semantic layer provides a curated and consistent view, there might be scenarios where a more direct or granular access is needed for advanced analytical tasks. MCP could provide the standardized means to achieve this, with appropriate authorization and understanding of the underlying data structures.
3. __Orchestrating Analytical Workflows__: An AI agent using MCP could interact with both a semantic layer (via an MCP server exposing its capabilities) and the underlying data sources (via other MCP servers). It could use the semantic layer to understand the available data and perform high-level analysis, and then use direct data access via MCP for more detailed investigations or specific data manipulations.
4. __Consistent Data Definitions__: By using a semantic layer in conjunction with MCP, organizations can ensure that AI-powered analytics tools and agents are working with consistent and well-defined business metrics and dimensions, reducing the risk of misinterpretations and errors.
5. __Leveraging Semantic Layer APIs for Data Retrieval__: MCP tools could be designed to interact directly with the Semantic Layer's APIs to request data, rather than generating code to query the underlying data sources. This approach relies on the deterministic compilation capabilities of the Semantic Layer, which translates business terms into database queries. This method reduces errors by utilizing the Semantic Layer's built-in error handling, query rewrite capabilities and increases transparency as the requests are made using known and defined business terms.

In essence, the semantic layer provides the "what" and "how" of business data, while MCP provides the standardized "access" mechanism for AI agents to interact with that data (either directly or through the abstraction of the semantic layer) and perform analytical tasks. This combination can lead to more powerful, efficient, and user-friendly AI-driven analytics solutions.

## MCP’s Role in the Future of AI and Analytics
While still in early stages, MCP offers a compelling path toward a more interoperable, dynamic AI ecosystem. By abstracting the complexity of integrations, it allows AI models to focus on what they do best:reasoning, decision-making, and creating value.

For enterprises looking to supercharge AI-driven analytics, combining MCP with semantic layers may prove to be the ultimate force multiplier. As the ecosystem matures with more MCP servers, clients, and standards, expect MCP to become not just a tool for connecting AI to the world, but a foundational element in the architecture of the AI-native enterprise. [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=mcp%20blog) to learn more about how MCP and Cube can work together to deliver trusted agentic analytics.


Unlocking Universal Data Access for AI with Anthropic's Model Context Protocol


Trust in financial data isn’t just beneficial. It’s critical. Financial institutions are bound by their ability to confidently meet regulatory requirements, drive decisive actions, and maintain investor and client trust. Yet today, maintaining trust is alarmingly difficult. Fragmented data sources, inconsistent metrics, and opaque governance create confusion and costly errors. The answer to this escalating crisis is Cube Cloud’s universal semantic layer, which is a transformative solution delivering clarity, consistency, and centralized control.

## The Hidden Cost of Fragmented Financial Data
Financial firms face an urgent problem: fragmented data. Disparate sources, legacy systems, and departmental silos mean multiple, conflicting versions of the truth. Fragmentation painfully impacts everything from straightforward revenue calculations to complex risk assessments, creating constant uncertainty. Without a reliable source of truth, decisions slow down, regulators lose confidence, and strategic initiatives falter.

The urgency is amplified as financial firms increasingly deploy advanced analytics and AI. Poor quality, inconsistent data doesn’t only slow processes, it actively harms credibility, undermines strategic planning, and jeopardizes regulatory compliance. These data inconsistencies aren’t mere inconveniences; they’re expensive, carrying real risks of fines, lost market opportunities, and diminished investor trust.

## Why Financial Firms Need Cube Cloud’s Universal Semantic Layer
Cube Cloud’s universal semantic layer is the solution financial institutions urgently need. Sitting centrally between raw data and analytical tools, whether it’s AI, BI, spreadsheets, or embedded analytics, it ensures consistent, governed definitions for all business-critical metrics. Analysts, compliance officers, and executives receive the same trusted data, dramatically reducing the risk of costly discrepancies.

For example, when multiple departments reference metrics like EBITDA or risk-weighted assets, Cube Cloud’s universal semantic layer ensures all stakeholders receive identical figures. This consistency directly eliminates costly reconciliation efforts and significantly improves accuracy in financial reporting, regulatory submissions, and strategic decisions.

## Streamlined Governance and Compliance
Financial regulations like Basel III, Dodd-Frank, and GDPR demand rigorous compliance and traceability. Non-compliance is not just risky; it’s potentially catastrophic. Cube Cloud’s universal semantic layer centralizes governance and provides clear, transparent data lineage. Auditors and regulators can easily trace metrics to their original data sources, dramatically simplifying compliance audits and significantly lowering risk.
With centralized governance, financial firms ensure that all data complies with internal and external standards. By simplifying governance, Cube Cloud’s universal semantic layer dramatically reduces the costly administrative burden associated with regulatory compliance.

## Moving Beyond the Burden of Legacy OLAP 
Finance and risk teams live and breathe Excel, and they won’t abandon it. Cube Cloud meets this reality head-on, offering native Excel connectivity via the MDX API without requiring legacy OLAP systems or duplicative tabular models. Teams maintain their familiar Excel workflows while seamlessly benefiting from centralized governance. With the DAX API, financial services teams can perform multidimensional analysis in Power BI. These integrations solve a long-standing pain point, drastically simplifying processes and enhancing reliability without disruptive changes.

## Simplify Without the Pain of Replatforming
Most financial institutions rely on complex, layered technology stacks, including cloud data platforms like Snowflake or Databricks and BI tools like Tableau, Power BI, dbt, and Python notebooks. Cube Cloud’s universal semantic layer integrates effortlessly with these existing tools, bringing immediate governance and clarity without forcing costly or disruptive replatforming. Institutions quickly realize simplified management, reduced complexity, and enhanced ROI on existing technology investments.

## AI You Can Actually Trust
Financial firms recognize AI’s strategic potential but often hesitate due to concerns about transparency and explainability. Cube Cloud’s universal semantic layer directly addresses this challenge, providing deep context and  clear, traceable reasoning. This transparency ensures AI outputs are explainable, trustworthy, and compliant, which is exactly what CIOs demand. Firms can confidently deploy AI-driven strategies, secure in the knowledge their models meet stringent regulatory and internal standards.

## Accelerating Decisions and Driving Competitive Advantage
Speed is critical in financial markets. When data trust is compromised, decision-making grinds to a halt amid endless reconciliation. Cube Cloud’s universal semantic layer ensures data reliability from the start, significantly accelerating insight-to-action cycles. Analysts spend less time validating and more time interpreting trusted insights, enabling swift, decisive responses to market shifts.

Imagine portfolio managers confidently making real-time decisions backed by accurate, trusted data. Speed translates directly into profitability and competitive differentiation.

## Leveraging Trusted Data for Strategic Initiatives
Ultimately, restoring trust in financial data unlocks strategic value. With trustworthy, consistent data at their core, financial firms can fully embrace digital transformation, predictive analytics, and advanced AI-driven forecasting. Reliable data empowers accurate market predictions, optimized risk management, and personalized client services, turning data from a cost center into a competitive asset.

## Building Long-Term Trust
In the highly competitive and regulated financial sector, trustworthy data isn’t optional. It’s fundamental. Adopting Cube Cloud’s universal semantic layer doesn’t just fix today’s urgent challenges; it establishes a robust foundation for future success. Firms investing in this approach position themselves confidently to lead in tomorrow’s data-driven financial landscape. [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=trust-financial-data-blog) to learn more about how Cube can restore trust in financial services data.


Restoring Trust in Financial Data with Cube Cloud’s Universal Semantic Layer


Over the past year, organizations have poured time, money, and resources into AI experimentation. They’ve fine-tuned models, integrated copilots, and explored everything from customer service chatbots to predictive forecasting agents. But despite impressive proof-of-concepts, most enterprises find themselves stuck in pilot purgatory and unable to scale AI across real teams and workflows. The issue isn’t the model. It’s the organization.

## The Hidden Barrier to Scalable AI
We’ve been conditioned to treat AI readiness as a technical challenge. Do we have enough GPU capacity? Are our models fine-tuned? What’s our vector database strategy? While those questions matter, they miss a more fundamental issue: enterprise alignment.

In reality, AI transformation doesn’t just require better models. It requires a cultural and operational shift in how organizations handle data, decision-making, and trust. It’s one thing to generate a useful answer. It’s another to get your organization to act on it. And that leap—from insight to action—is where most enterprises fall short.

## Where the Disconnect Begins
AI pilots often live in isolated innovation teams. They succeed in demos, generate headlines, and occasionally get showcased at company all-hands. But when business users try to engage, things get messy. Different teams use different tools. No one agrees on the numbers. The same metric is calculated three different ways. And when the AI gives a surprising answer, no one can explain it or why it should be trusted.

This is not a problem of model quality. It’s a problem of organizational unpreparedness. The AI may be accurate, but the business isn’t aligned around consistent logic, clear data access policies, or even shared expectations for what “done right” looks like.

## Why Organizational Readiness Matters More Than Ever
In the BI era, [inconsistency and misalignment](https://cube.dev/blog/the-harsh-lessons-of-modern-bi-and-why-scaling-ai-will-be-even-harder) meant longer meetings and slower decisions. In the AI era, those same issues become dangerous. AI tools move fast. They act, recommend, automate. If they do so based on fragmented logic or unclear policies, they scale chaos.

This is why AI transformation can’t be handled solely by the IT, Data Science, or Innovation department. It must become a cross-functional initiative with the same rigor as financial planning or regulatory compliance. Everyone from data engineers to frontline operators to C-level executives needs to know what AI can do, how it works, and when to trust it.

## What Training the Organization Looks Like
Training the organization doesn’t mean teaching everyone to write prompts or tune models. It means aligning the company around a few key principles:
- __Shared definitions__: Everyone must use the same definitions for key metrics. If “active user” or “churn” means different things to different teams, AI will only deepen the divide.
- __AI literacy with context__: Teach teams not just how to interpret charts, but how AI uses data to generate outputs. Explain the role of semantic models, policy enforcement, and lineage because [AI literacy is the new data literacy](https://cube.dev/blog/ai-literacy-is-the-new-data-literacy-why-a-semantic-layer-is-the-missing).
- __Governance clarity__: Make sure AI agents and copilots respect access controls and can explain every action. Define escalation paths, review protocols, and compliance requirements, making [AI governance](https://cube.dev/blog/why-ai-governance-starts-with-data-governance) start with data governance.
- __Feedback loops__: Create systems where users can question, correct, or enhance AI outputs. Make it normal to ask, “Where did this number come from?”—and easy to get an answer.

## The Role of a Semantic Modeling
One of the most effective ways to operationalize these principles is by investing in a universal semantic layer. It centralizes business logic and makes it available to AI agents, BI tools, spreadsheets, and embedded analytics apps. It becomes the connective tissue between teams, tools, and data.
When AI is built on a solid semantic foundation, it no longer relies on assumptions. It queries using the same definitions. It calculates metrics the way your dashboards do. It respects row- and column-level security without needing custom code. And when someone asks, “Why does AI say churn increased?”—there’s an answer. Not a guess.

## From Technology Project to Change Initiative
The best AI strategies start small but think big. They don’t just ask, “What can this model do?” They ask, “What will our people need in order to trust and adopt it?”

That means running training sessions not just on prompting, but on how the data model works. It means looping in Finance and Legal early to define governance policies. It means measuring adoption and trust, not just response accuracy.

The organizations that scale AI successfully are the ones that treat it as an operating model, not a feature. They build internal knowledge, invest in semantic alignment, and create systems where AI enhances—not replaces—decision-making.

## The Real AI Readiness Checklist
So before your AI rollout, ask:
- Do all teams agree on how our key metrics are defined?
- Can we trace any number back to its logic and source?
- Have we embedded access policies into the tools—not just into the people?
- Do users know what to expect from AI—and what to do when something looks wrong?

If not, it’s not your model that needs training. It’s your organization.

## Build Trust Before Scale
The models are ready. The tools are available. But real transformation requires more than output. It requires organizational trust. Yes, train the models, but also train the business. Align your logic. Build feedback loops. Invest in explainability. The future of enterprise AI doesn’t depend on more intelligence. It depends on more alignment.

That starts with preparing your organization to trust AI. Trust starts with structure, transparency, and shared understanding. [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=train-the-org-blog) to learn more about how Cube Cloud’s universal semantic layer is the critical foundation for your people to trust and benefit from everything AI has to offer.


You Trained the Models, Now You Need to Train the Organization


We’re excited to share that Cube has officially achieved Snowflake Ready Technology Validation, a recognition that underscores the strength of our integration with Snowflake and our shared vision for a more performant, consistent, and scalable data analytics ecosystem.

This milestone highlights not just a technical achievement, but a deepened commitment to all of teams that rely on Cube and Snowflake to power mission-critical data experiences—from BI dashboards to AI-powered applications.

## A Seamless, Certified Experience on Snowflake
The Snowflake Ready Technology Validation is a rigorous third-party assessment of integration performance, functionality, and best practices. Cube has met and exceeded Snowflake’s benchmarks for reliability, security, and performance—meaning our platform is officially certified to help you get the most out of your Snowflake investment.

This validation sits alongside our Premier Tier status in the Snowflake Partner Network, placing Cube among a select group of technology providers recognized for their impact, innovation, and success in helping customers accelerate data outcomes.

“Data analytics is the lifeblood of any company,” said Kieran Kennedy, Global Head, Data Cloud Products at Snowflake. “Cube’s Technology Ready status reflects the company’s commitment to enhancing performance, increasing reliability, and deriving more value for joint customers.”

## Built for the Modern Data Stack—and What Comes Next
Cube’s universal semantic layer integrates natively with Snowflake to support today’s full spectrum of data use cases: Modern OLAP, embedded analytics, enterprise BI, and AI-powered workflows. Whether you’re building trusted dashboards in Tableau and Power BI, operationalizing metrics in embedded data applications, or connecting governed data directly to an LLM, Cube acts as a translation and acceleration layer between the Snowflake Data Cloud and any downstream tool.

In our [deep dive on the Snowflake + Cube architecture](https://cube.dev/blog/how-cubes-universal-semantic-layer-and-snowflake-data-cloud-work-together), we walk through how Cube enhances performance by reducing data sprawl, unifying business logic, and optimizing query orchestration—especially important for organizations managing dozens of tools and users across teams.

And if you’re exploring [LLM-powered experiences with Snowflake](https://cube.dev/blog/bring-your-own-snowflake-llm), Cube can serve as the semantic layer that governs which metrics, models, and dimensions AI can access—ensuring both usability and security.

## What This Means for You
When you pair Cube and Snowflake, you get: 
- __Confidence__: Cube is validated by Snowflake to meet their highest technical and performance standards.
- __Velocity__: Our joint customers can move faster with fewer errors, more consistent data, and better alignment across teams.
- __Future-readiness__: Whether you’re scaling BI or prototyping AI agents, Cube and Snowflake together offer a future-proof foundation for your analytics stack.

This achievement is part of our ongoing commitment to helping data teams modernize and scale their analytics infrastructure with trust, performance, and flexibility at the core.

If you’re building on Snowflake and looking to unlock governed, AI- and BI-ready data at scale—Cube is ready when you are. [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=snowflake-validation-blog) to learn more.


Snowflake

Cloud Data Warehouses (CDW)

Cube Achieves Snowflake Ready Technology Validation


Agentic AI and the ability for AI agents to act autonomously within trusted boundaries are reshaping not just the way we interact with data, but the very roles and responsibilities across the data ecosystem.

Rather than simply automating isolated tasks, Agentic AI is poised to redefine how value is created from data by enabling new capabilities, accelerating insights, and expanding the reach of data-driven decision-making.

In this blog, we’ll explore how Agentic AI will disrupt traditional data roles, transform the data lifecycle, and unlock new possibilities that were once impractical.

## Rethinking Data Roles in the Era of Agentic AI 
### Data Engineers: From Builders to Strategists
Data engineers will experience a disruption in many routine tasks with the introduction of AI agents. These tasks include creating ingestion pipelines, authoring new data transformation assets, performing multi-file refactoring, and even automated incident resolution. For instance, AI can already assist in coding ingestion pipelines from various sources and is rapidly being integrated into tools like dbt for authoring, documenting, and testing data transformations. This could lead to a significant enhancement in efficiency, potentially in the higher end of the 20%-80% range. 

However, this doesn't mean data engineers will be replaced; instead, their roles will likely shift towards more strategic activities. They will focus more on designing overall data architectures, managing data platforms for performance and governance, building business automations based on data insights, and acting as enablement and support for the insight generation process. The importance of frameworks, tooling, and standards will be enhanced as they provide a consistent foundation for AI to operate effectively. Furthermore, AI can act as a co-pilot in tasks like semantic layer development and maintenance, enhancing their productivity.

### Data Scientists: From Model Builders to Orchestrators
Agentic AI will redefine the role of data scientists. While foundational knowledge remains crucial, their focus will shift from solely solving predefined problems to proactively framing complex business challenges. This requires a deeper understanding of business nuances. Data scientists will need to upskill in areas like agentic AI frameworks, reinforcement learning, and multimodal AI. They will increasingly act as orchestrators of agentic AI systems, balancing technical frameworks, business goals, and ethical considerations. Their ability to fine-tune performance across multiple data sources and ensure data transparency and interpretability in multimodal AI will be enhanced in importance. Agentic AI is not expected to replace data scientists but rather elevate their role to a more strategic and coordinating position.

### Data Analysts: From Dashboards to Dynamic Insights
Agentic AI offers a significant opportunity to enhance the productivity of data analysts by automating tasks and speeding up the time to generate insights. Their role in ensuring a strong data foundation – by preparing, cleaning, structuring, and augmenting data – becomes even more critical for the effective deployment of AI. AI can also enable data analysts to generate insights faster and potentially reduce reliance on dashboards in some cases.

### Business Users: From Requestors to Explorers
AI agents, especially when combined with semantic layers, will disrupt the traditional reliance on technical teams for basic data access for business and non-technical users. Natural language querying, powered by AI and semantic layers, will enable non-technical users to explore data and discover insights through simple questions. This promises to enhance data accessibility and democratize data consumption. AI can also assist in rapidly creating business dashboards through generative AI, enhancing the speed at which business needs can be met.

## Reimagining the Data Lifecycle with Agentic AI
In data preparation, AI agents can enhance the process by automating feature engineering, data cleaning, and transformation techniques. Orchestrator Agents can automate the ingestion and preprocessing of raw data, while Specialist Agents can apply AI-driven feature extraction.

Agentic AI will significantly enhance data analysis and insight generation. AI agents can automate self-service analytics, reducing dependency on data teams. They can perform real-time anomaly detection and provide predictive and prescriptive insights for business optimization.

Agentic AI promises to disrupt traditional manual data governance processes by automating access control, policy enforcement, regulatory compliance, and data security. Governance Agents can enforce security policies and access rules in real-time, automate compliance audits, and manage data masking and security policies.

AI agents, particularly Trust Agents, will enhance data trust by automating data quality validation, assigning trust scores to datasets, and ensuring regulatory compliance. AI-enhanced data provenance and lineage tracking will provide full visibility into data transformations.

## Preparing for New Agentic AI Capabilities
Agentic AI will enable systems to make day-to-day work decisions autonomously, a significant shift from traditional analytics. Gartner predicts that 15% of such decisions will be made by agentic AI by 2028. The combination of AI and semantic layers will enable more accurate and context-aware natural language querying of data, making data exploration accessible to a wider audience. 

AI can act as a co-pilot for data engineers and scientists, assisting in code generation, semantic layer creation, and providing explanations and fixes for errors. Companies can build their own internal AI agents to act as central hubs for knowledge and access across various applications and data stores. These agents could route questions to the appropriate systems and provide unified answers. 

AI agents can enable real-time trust scoring of data, ensuring that AI models and BI systems use reliable and validated information. AI-powered tools can enable faster iterations in data modeling, dashboard creation, and overall analytics workflows, reducing technical bottlenecks and accelerating the delivery of insights. Semantic layers, crucial for effective AI interaction with data, help raise and ideally solve ambiguities in business terms and metrics, which LLMs alone struggle with.

## The Future of Data Work
Agentic AI, when combined with strong data foundations and semantic models, will fundamentally reshape the data landscape. It will automate what can be automated. It will enhance what must be enhanced. And it will elevate human roles—moving data professionals closer to strategy, orchestration, and innovation.

The organizations that embrace this evolution—not just technologically, but culturally—will unlock faster, more accurate, and more impactful decisions at every level of the business. The age of data-driven enterprises is evolving. The future of work is agentic.  

AI agents are poised to significantly affect various data roles and the overall data lifecycle, leading to disruptions, enhancements, and the enablement of new capabilities that were previously impractical.

__Impact on Data Roles__
- __Data Engineers__: AI agents are expected to disrupt many routine tasks. These include creating ingestion pipelines, authoring new data transformation assets, performing multi-file refactoring, and even automated incident resolution. For instance, AI can already assist in coding ingestion pipelines from various sources and is rapidly being integrated into tools like dbt for authoring, documenting, and testing data transformations. This could lead to a significant enhancement in efficiency, potentially in the higher end of the 20%-80% range. However, this doesn't mean data engineers will be replaced; instead, their roles will likely shift towards more strategic activities. They will focus more on designing overall data architectures, managing data platforms for performance and governance, building business automations based on data insights, and acting as enablement and support for the insight generation process. The importance of frameworks, tooling, and standards will be enhanced as they provide a consistent foundation for AI to operate effectively. Furthermore, AI can act as a co-pilot in tasks like semantic layer development and maintenance, enhancing their productivity.

- __Data Scientists__: Agentic AI will redefine the role of data scientists. While foundational knowledge remains crucial, their focus will shift from solely solving predefined problems to proactively framing complex business challenges. This requires a deeper understanding of business nuances. Data scientists will need to upskill in areas like agentic AI frameworks, reinforcement learning, and multimodal AI. They will increasingly act as orchestrators of agentic AI systems, balancing technical frameworks, business goals, and ethical considerations. Their ability to fine-tune performance across multiple data sources and ensure data transparency and interpretability in multimodal AI will be enhanced in importance. Data scientists will also play a critical role in ensuring the ethical development and governance of AI models, working alongside ethicists and regulators. Agentic AI is not expected to replace data scientists but rather elevate their role to a more strategic and coordinating position.

- __Data Analysts__: Agentic AI offers a significant opportunity to enhance the productivity of data analysts by automating tasks and speeding up the time to generate insights. Their role in ensuring a strong data foundation – by preparing, cleaning, structuring, and augmenting data – becomes even more critical for the effective deployment of AI. AI can also enable data analysts to generate insights faster and potentially reduce their reliance on dashboards in some cases.
Business Users/Non-Technical Users: AI agents, especially when combined with semantic layers, will disrupt the traditional reliance on technical teams for basic data access. Natural language querying, powered by AI and semantic layers, will enable non-technical users to explore data and discover insights through simple questions. This promises to enhance data accessibility and democratize data consumption. AI can also assist in rapidly creating business dashboards through generative AI, enhancing the speed at which business needs can be met.

__Impact on the Data Lifecycle__
- __Data Preparation__: AI agents can enhance data preparation by automating feature engineering, data cleaning, and transformation techniques. Orchestrator Agents can automate the ingestion and preprocessing of raw data, while Specialist Agents can apply AI-driven feature extraction.
Data Analysis and Insight Generation: Agentic AI will significantly enhance this stage. AI agents can automate self-service analytics, reducing dependency on data teams. They can perform real-time anomaly detection and provide predictive and prescriptive insights for business optimization.
- __Data Governance__: Agentic AI promises to disrupt traditional manual data governance processes by automating access control, policy enforcement, regulatory compliance, and data security. Governance Agents can enforce security policies and access rules in real-time, automate compliance audits, and manage data masking and security policies.
- __Data Trust__: AI agents, particularly Trust Agents, will enhance data trust by automating data quality validation, assigning trust scores to datasets, and ensuring regulatory compliance. AI-enhanced data provenance and lineage tracking will provide full visibility into data transformations.

__New Capabilities Enabled by AI Agents__
- __Autonomous Decision-Making__: Agentic AI will enable systems to make day-to-day work decisions autonomously, a significant shift from traditional analytics. Gartner predicts that 15% of such decisions will be made by agentic AI by 2028.
- __Enhanced Natural Language Interaction__: The combination of AI and semantic layers will enable more accurate and context-aware natural language querying of data, making data exploration accessible to a wider audience.
- __AI Co-pilots for Data Professionals__: AI can act as a co-pilot for data engineers and scientists, assisting in code generation, semantic layer creation, and providing explanations and fixes for errors.
- __Internal Company AI Agents__: Companies can build their own internal AI agents to act as central hubs for knowledge and access across various applications and data stores. These agents could route questions to the appropriate systems and provide unified answers.
- __Real-time Data Trust Scoring__: AI agents can enable real-time trust scoring of data, ensuring that AI models and BI systems use reliable and validated information.
Faster Iterations and Reduced Bottlenecks: AI-powered tools can enable faster iterations in data modeling, dashboard creation, and overall analytics workflows, reducing technical bottlenecks and accelerating the delivery of insights.
- __Improved Handling of Ambiguity__: Semantic layers, crucial for effective AI interaction with data, help raise and ideally solve ambiguities in business terms and metrics, which LLMs alone struggle with.

Overall, AI agents, particularly when coupled with robust data foundations and semantic layers, will drive a significant evolution in data roles and the data lifecycle. They will automate many existing tasks, enhance efficiency and capabilities, and enable new ways of interacting with and leveraging data that were previously impractical or impossible. [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=agentic%20ai%20data%20roles) to learn more about agentic AI.


How Agentic AI Is Changing Data Roles


Scaling AI and analytics means making data more accessible to everyone in the organization, but that also comes with growing costs. Every query your team runs against a cloud data platform eats into your budget, especially when dashboards refresh on a schedule, embedded analytics serve end users, or AI agents are constantly querying your data sources. And those prices can quickly spiral out of control. 

Understanding the actual cost of a single query becomes more important than ever. Whether you're building internal dashboards or powering a public-facing data app, every query to your data warehouse has a price, and cumulatively, they rack up a large bill. That’s why we put Cube Cloud to the test. Using a standardized benchmark, we compared the cost-per-query of Cube Cloud against direct queries to a modern cloud data platform with the cost-per-query model outlined in this [Select.dev blog post](https://select.dev/posts/cost-per-query#complete-sql-query). We'll show why Cube's compute model offers more predictable and lower costs per query, especially at high throughput.

## How Compute Pricing Works
Let’s break down how compute-based pricing works in both scenarios.

### 1. Modern Cloud Data Warehouses
Most modern platforms charge based on the following:

- __Compute time__: Measured in seconds or minutes, typically billed in "credits" or "slots."
- __Concurrency scaling__: Simultaneous users can spin up additional compute clusters.
- __Query complexity__: Longer or more complex queries consume more resources.
- __Data Scanned__: The amount of data read to execute the query.

So when 10 users hit a dashboard at once, you're not necessarily paying for 10 separate compute sessions but increasing total compute time. The cost-per-query can be estimated by pro-rating the warehouse cost over the number of queries completed during that time, as outlined in [Select.dev's cost-per-query model](https://select.dev/posts/cost-per-query#complete-sql-query). This is exactly how we calculated query costs in our benchmark, by measuring how many queries ran within a fixed window and then allocating the total compute cost proportionally.

To make the comparison fair and realistic, we also ran a separate [load test](https://cube.dev/blog/comparative-analysis-of-load-tests-on-cube-store-and-cloud-data-warehouse) to identify the maximum __QPS (queries per second)__ the data warehouse could sustain for this specific query type. This allowed us to optimize concurrency and throughput to minimize cost-per-query, a common practice in real-world production environments, where teams tune dashboards and batch queries to get the most out of their warehouse time.

### 2. Cube Cloud
Cube Cloud works differently:

- __Pre-aggregations__ and __Cube Store__ eliminate the need to hit the warehouse for most queries. However, building pre-aggregations could be costly since these long-running queries require considerable computing power.
- Cube costs are based on __API instance and worker compute usage__, not query volume or amount of data scanned.
- You're effectively __paying for throughput__, not for query complexity.

## Benchmarking Query Cost: Cube vs Modern Data Warehouse
We ran a benchmark using the industry-standard __TPC-H__ dataset at __scale factor 100__ to compare query cost predictability and performance. The test simulates a realistic dashboard scenario, with users issuing an increasing number of concurrent requests. Each query will contain a random set of parameters for the filters, ensuring we have a low cache-hit ratio to showcase the cost difference and be closer to a more realistic scenario.

![](https://ucarecdn.com/d0c57ed7-45ca-46c3-9e6c-45ff4f9fef92/)

Here's the exact SQL query used in the benchmark:
```sql
SELECT
  "part"."P_TYPE" "item_information__part_type",
  "region"."R_NAME" "item_information__region_name",
  "customer"."C_MKTSEGMENT" "item_information__market_segment",
  "lineitem"."L_SHIPMODE" "item_information__ship_mode",
  count(
    CAST(
      CONCAT(
        "lineitem"."L_ORDERKEY",
        "lineitem"."L_LINENUMBER"
      ) as TEXT
    ) || CAST("lineitem"."L_ORDERKEY" as TEXT)
  ) "item_information__count",
  sum("lineitem"."L_DISCOUNT") "item_information__total_discount",
  sum("lineitem"."L_EXTENDEDPRICE") "item_information__total_price",
  sum("lineitem"."L_EXTENDEDPRICE") - sum("lineitem"."L_DISCOUNT") - sum("lineitem"."L_TAX") "item_information__total_profit",
  sum("lineitem"."L_QUANTITY") "item_information__total_quantity",
  sum("lineitem"."L_EXTENDEDPRICE") - sum("lineitem"."L_DISCOUNT") "item_information__total_revenue"
FROM
  (
    SELECT *
    FROM TPCH_100.LINEITEM
    WHERE L_LINESTATUS = 'O' AND L_RETURNFLAG = 'N'
  ) AS "lineitem"
  LEFT JOIN "TPCH_100"."PART" AS "part" ON "lineitem"."L_PARTKEY" = "part"."P_PARTKEY"
  LEFT JOIN (
    SELECT *
    FROM TPCH_100.ORDERS
    WHERE O_ORDERSTATUS = 'O'
  ) AS "orders" ON "lineitem"."L_ORDERKEY" = "orders"."O_ORDERKEY"
  LEFT JOIN "TPCH_100"."CUSTOMER" AS "customer" ON "orders"."O_CUSTKEY" = "customer"."C_CUSTKEY"
  LEFT JOIN "TPCH_100"."NATION" AS "nation" ON "customer"."C_NATIONKEY" = "nation"."N_NATIONKEY"
  LEFT JOIN "TPCH_100"."REGION" AS "region" ON "nation"."N_REGIONKEY" = "region"."R_REGIONKEY"
WHERE
  "lineitem"."L_SHIPDATE" BETWEEN '1994-01-01' AND '1995-02-01'
  AND "part"."P_TYPE" = 'PROMO POLISHED NICKEL'
  AND "nation"."N_NAME" IS NOT NULL
  AND "region"."R_NAME" IS NOT NULL
  AND "lineitem"."L_RETURNFLAG" IS NOT NULL
GROUP BY 1, 2, 3, 4
ORDER BY 5 DESC
LIMIT 100
```

### How Cube Optimized This Query
In Cube, we modeled the same query using a __[pre-aggregation](https://cube.dev/docs/product/caching/using-pre-aggregations)__ that rolls up the relevant measures and dimensions. This reduces the complexity of the query and shifts heavy computation to the pre-aggregation layer.

Here's the pre-aggregation configuration used:
```sql
pre_aggregations:
  - name: item_rollup
    measures:
      - CUBE.total_discount
      - CUBE.total_price
      - CUBE.total_profit
      - CUBE.total_quantity
      - CUBE.total_revenue
      - CUBE.count
    dimensions:
      - CUBE.ship_mode
      - customer.market_segment
      - part.part_type
      - nation.nation_name
      - region.region_name
    allow_non_strict_date_range_match: true
    time_dimension: ship_date
    granularity: month
    partition_granularity: year
    refresh_key:
      every: 1 hour
```
__Note__: We assume a complete rebuild of this pre-aggregation once per hour, a common scenario in real-world systems, especially with slowly changing dimensions.

### Benchmark Setup

To make the comparison fairer, we ran the benchmark assuming you need a [Cube Cloud Production](https://cube.dev/docs/product/deployment/cloud/deployment-types#production-cluster) cluster turned on 24/7. That is to keep the pre-aggregations updated. Since there's a fixed cost of building pre-aggregations, there's a scenario when querying directly the Data Warehouse is cheaper than using pre-aggregations. This is a real-world consideration that has to be made when using Cube Cloud in production. When using Cube Cloud, you don't want to pre-aggregate everything; you should add pre-aggregations for queries with repeatable query patterns and a very low Cube's in-memory cache-hit ratio.  

Then, to size the Cube Cloud Production Cluster, we started with the minimum size of two API instances, and we scaled up every 100 queries to simulate the increased required throughput. When we reach the maximum of 10 API instances per Production Cluster, the next level of horizontal scaling will be using a [Cube Cloud Multi-Cluster deployment](https://cube.dev/docs/product/deployment/cloud/deployment-types#production-multi-cluster). That complicates the calculation a bit since sometimes having more Multi-Clusters than API instances is better. So, for this exercise, we will stick to regular Production Clusters and theoretically unlimited API instances.  Having a Cube Store Cluster turned on 24/7 costs [96 CCUs per day](https://cube.dev/docs/product/deployment/cloud/pricing#small-scale-deployment), and assuming a $0.3 price per credit, we get $28.8 per day, which only includes 2 API instances. There's a maximum of 10 API instances per cluster with a maximum theoretical throughput of 100 Queries Per Second; each additional API instance costs 1 CCU per hour. For the Data Warehouse the cost used was $2 per credit, using the same tier as Cube Cloud with no discounts.

That means that while a Data Warehouse could take hours to calculate 1000 queries, a Cube Cloud Production Cluster just needed 13 seconds on average to finish serving 1000 queries when scaled to 10 API instances. Read more about how Cube is consistently faster than modern Data Warehouses for OLAP queries.

### Benchmark Results
As expected at the beginning of the series, the initial cost of building pre-aggregations makes the cost per query more expensive in Cube Cloud. Still, as volume increases, the cost per query in Cube Cloud decreases drastically, while the cost per query in the Data Warehouse decreases at a slower rate.

![](https://ucarecdn.com/89b8ccd6-444d-4254-a00a-a84cf6a0fa5e/)

| Metric     | Cube Cloud with pre-aggregations     | Data Warehouse - no pre-aggregations     | Improvement - as % of change     |
| ---------- | ---------- | ---------- | ---------- |
| Avg Response Time - p50       | 1.3 seconds       | 40.7 seconds       | <mark>__-3,031%__</mark>       |
| Cost per Query at 10,000
queries per day.       | $0.0453       | $0.0528       | <mark>-14.19%</mark>       |
| Cost per Query at 20,000 
queries per day.       | $0.0230       | $0.0504       | <mark>-54.34%</mark>       |
| Cost per Query at 100,000 queries per day.       | $0.0052       | $0.0485       | <mark>-89.32%</mark>       |
| Cost per Query at 1,000,000 queries per day.       | $0.0012       | $0.0480       | <mark>-97.57%</mark>       |

Now, 1000 queries in a day is nothing in a real-world scenario. At one million queries per day, the cost per query in Cube Cloud is __$0.0012__, the cost per query in a Data Warehouse is __$0.0480__, even after increasing compute size to increase throughput. That's around __40 times cheaper__ to run your high-throughput workloads in Cube Cloud using pre-aggregations. In addition to that, running this type of query in Cube Cloud with pre-aggregations is __31 times faster__.

The main difference between the cost of both scenarios is that in the Data Warehouse, the cost grows proportionally with usage at a high rate. In Cube Cloud, there is a fixed cost for building pre-aggregations. The cost per query for using [Cube Store](https://cube.dev/docs/product/deployment#cube-store) is much lower than the cost per query in any modern Data Warehouse; in other words, Cube Store has excellent economies of scale compared to cloud data platforms.

![](https://ucarecdn.com/fd265ac3-50d5-496e-81b8-a519e3b818d0/)

The actual cost of running this experiment in Cube Cloud was no more than $200 per day; I extrapolated the results to consider having this deployment running 24/7, while the cost for the Data Warehouse was  $719.70, which was calculated using this [Select.dev blog post](https://select.dev/posts/cost-per-query#complete-sql-query). 

## Scale Smarter, Not Harder
Cube Cloud fundamentally changes the cost dynamics of querying data at scale by acting as a smart query acceleration layer. While cloud data platforms rack up charges as usage grows, Cube’s fixed-cost pre-aggregation model unlocks massive savings, especially once you cross into high-volume territory. Using pre-aggregations and in-memory stores, Cube can reduce your cost-per-query with performance and scale to match.

At 1 million queries per day, Cube is 40x cheaper and 31x faster than running the same queries directly on the warehouse. That’s not just better performance. That’s operational optimization. Now you can pay for throughput, instead of how complex a SQL query is. If you’re looking to make your analytics architecture future-ready with predictable costs and lightning-fast query times, it’s time to put Cube in the middle. [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=query%20costs%20blog) to learn how Cube could reduce cloud data platform costs.


Paco Valdez

Why Cube Cloud Makes Your Query Costs Predictable (and Lower)


Over the past four installments, we’ve explored how data leaders can bring consistency, clarity, and performance to their analytics through a universal semantic layer. We’ve discussed the dangers of the confidence gap, the need for clarity over chaos, and the limitations of relying solely on a data warehouse.

Now, we bring it all together. In part five, we’ll focus on the outcome that every data leader, executive, and analyst ultimately wants: trustworthy data that leads to confident, data-backed decisions. We’ll show how Cube Cloud, as a universal semantic layer, doesn’t just fix technical fragmentation. It builds the foundation for a reliable, governed, high-performance analytics ecosystem.

Because when the stakes are high, whether it’s quarterly earnings, compliance reporting, or product roadmap decisions, you need more than insights. You need data you can trust.

## Data Can’t Be Trusted, and Decisions Are at Risk
Even with the best intentions and modern tools, many organizations continue to struggle with:

- Conflicting reports for the same metrics across departments
- Manual reconciliation of numbers ahead of board meetings or audits
- Excel exports used to bypass slow dashboards or access restrictions
- Missed insights due to performance issues or ungoverned tools

The result? Teams lack confidence in their analytics. Leaders hesitate. Business decisions are slowed, or worse, made on inaccurate or outdated data. In highly regulated industries like financial services, healthcare, and insurance, these problems aren’t just operational. They’re compliance and reputational risks.

## Deliver Trustworthy Data in Every Connection
Defensibility doesn’t come from one tool. It comes from a system of controls, consistency, and visibility that spans your entire data ecosystem. To get there, enterprises need to take a number of steps:

- Unify their definitions of metrics, KPIs, and dimensions
- Govern access consistently across tools, users, and data types
- Optimize performance to ensure users stay within trusted platforms
- Deliver trust at scale every data consumer: AI, BI, spreadsheets, and embedded analytics

That’s exactly what Cube Cloud enables.

## How Cube Cloud Delivers Data You Can Trust
Cube Cloud is a universal semantic layer that connects to your cloud data warehouse and acts as a single source of truth for AI and analytics. It ensures that every tool, application, and user is working from consistent, governed, and performant data, without duplication or drift.

Here’s how Cube Cloud powers trust and defensibility at every level:

__1. Consistency Across Every Tool__

At the heart of Cube Cloud is a centralized data model that defines business metrics, logic, and dimensions in one place. These definitions are then exposed via APIs to all downstream tools from —BI platforms, spreadsheets, embedded dashboards, and AI/ML models.

- One definition of revenue.
- One way to calculate churn.
- One consistent customer segmentation.

No matter the interface, the data stays aligned. No more reconciling logic between Tableau, Power BI, Excel, and internal apps.

__2. Governance Built In__

As regulatory demands and data security concerns grow, maintaining centralized control over data access is critical. Cube Cloud centralizes and enforces fine-grained access controls, ensuring that sensitive data is governed consistently across the organization. This unified approach not only helps meet compliance requirements but also increases trust in data so that AI outputs are accurate and BI content is actionable. This means you can apply data access policies once, and they’ll be enforced in every connected tool. No more rebuilding permissions in every BI platform. No more compliance headaches.

__3. High-Performance Query Acceleration__

Cube Cloud includes a high-performance caching layer and supports intelligent pre-aggregations. This dramatically improves dashboard performance, reduces data warehouse load, and eliminates the need for business users to extract data for offline analysis. Now you can get sub-second dashboards, performant queries from AI, and spreadsheets that stay connected to governed sources. And with fewer workarounds, you gain better control, lower risk, and higher adoption of your data tools.

__4. Auditability and Transparency__

For decisions to be defensible, you need to show how they were made and what data supported them. Cube Cloud provides complete visibility into what data was queried, who accessed it, and what definitions were applied. This traceability is critical for regulated industries, executive reporting, and AI ethics reviews.

__Why Defensibility Matters More Than Ever__
In an era of AI- and BI-driven decisions, regulatory scrutiny, and real-time customer engagement, organizations can’t afford to treat data consistency as an afterthought. You need systems that enforce trust, not rely on it. Defensibility isn’t just for audits. It’s for every strategic initiative, every product launch, every quarterly forecast. That means your universal semantic layer must be consistently applied, governed and monitored, and integrated into every touchpoint of your data ecosystem. Cube Cloud was built to meet this moment.

__The Future of Data Is Trusted, Governed, and Unified__

With Cube Cloud, data leaders can finally build an analytics stack that delivers data you can trust and decisions you can stand behind. By unifying definitions, enforcing governance, optimizing performance, and delivering consistent logic everywhere, Cube Cloud transforms your warehouse into a trusted source of insights and your organization into one that moves confidently, strategically, and with clarity.

We hope this series has helped illuminate how a universal semantic layer can close the confidence gap, eliminate chaos, and bring clarity to your organization’s data. Ready to turn insights into action with data you can stand behind? Now is the time to take action and make Cube Cloud’s universal semantic layer part of your stack. [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=exec%20blog5) to learn more.


Deliver Data You Can Trust and Decisions You Can Stand Behind


Enterprise AI is accelerating. From chatbots and copilots to embedded assistants and AI agents, organizations are testing or integrating generative and agentic capabilities across the stack. Yet for all the investment, AI often fails to deliver on its promise. Models are trained. Interfaces are deployed. But the insights are wrong. The numbers don’t match, then trust erodes fast. Why? Because your AI can only go as far as your data model allows.

## The Real Bottleneck Isn’t the Model
When AI doesn’t deliver, most organizations blame the model. It must not be fine-tuned enough or the prompt wasn’t written correctly. Maybe it’s just not “smart” yet? In reality, the problem is often upstream, buried in inconsistent logic, metric drift, and fragmented definitions. The model is doing exactly what it was asked. It just doesn’t have the right data foundation.

Consider this: an AI assistant tells you revenue increased by 12%, but your dashboard shows 8%. A copilot generates a report that includes unapproved or sensitive fields. Two teams ask the same question and get different answers depending on the tool. These aren’t hallucinations. They’re symptoms of a much deeper issue: structural inconsistency in your data model.

## The Foundation Beneath the Interface
When we talk about data models, we often think of schemas and table structures. But in a business context, a data model is where meaning and context live. It defines how revenue is calculated, what counts as an active user, or how to group transactions by customer type. These definitions are the lifeblood of every dashboard, spreadsheet, and every AI agent.

When different tools or teams create their own definitions, even subtle variations can lead to drastically different answers. The resulting metric drift undermines trust, triggers endless reconciliation cycles, and ultimately slows decision-making. What made the BI era painful is now being magnified in the AI era.

## Why Your LLM Sounds Smart but Gets It Wrong
Large Language Models (LLM) have extraordinary capabilities in understanding and generating natural language, but they don’t inherently understand your business logic. If you ask an LLM to generate a revenue report without clearly defining what counts as revenue—or where the data comes from—it will make its best guess. And while that guess may sound convincing, it could be wrong. 

Critically, it might not be obvious that it’s wrong until it’s too late.
The danger is in the illusion of confidence. LLMs don’t self-correct for logic inconsistencies unless they’re explicitly trained or instructed not to. That’s why structure matters. A well-defined data model—consumed by AI tools—is what ensures that the outputs they generate reflect your actual business.

## How a Universal Semantic Layer Changes the Game
A universal semantic layer solves this problem by centralizing your data logic and making it available to every tool, including AI agents. It defines how metrics are calculated, which dimensions are used, and what policies apply to each dataset. More importantly, it creates a shared language—a contract—that tools must adhere to.

This changes the game for AI adoption. When AI agents draw from a semantic layer, they don’t guess how to define customer lifetime value or churn. They know, because it’s already defined. And when they generate reports or answer questions, those outputs are aligned with your dashboards, your spreadsheets, and your executive briefings. The result is consistency, and with consistency comes trust.

## From Chaos to Confidence
This is a cultural shift, instead of just a technical one. When every part of the organization relies on the same definitions, teams can collaborate more effectively. When AI tools are grounded in governed logic, they become accelerators rather than liabilities. And when leadership knows that the insights they’re seeing are built on a trusted data foundation, they can move with confidence.

Of course, implementing a universal semantic layer isn’t a silver bullet. It takes thoughtful modeling, change management, and the right tools. It’s a necessary step if you want to operationalize AI at scale. Without it, every chatbot and copilot is just building on sand.

## A Smarter Path Forward
If you’re serious about scaling AI, don’t start with prompts or plugins. Start with definitions. Define your KPIs, your dimensions, your access policies—and centralize them. Align your data stack around those definitions. Then—and only then—can AI deliver on its promise.
Because no matter how powerful your model is, it’s only as reliable as the data logic that supports it. Your AI can only go as far as your data model. So make sure that model is one your entire organization can stand on. [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=ai-data-model-blog) to learn now Cube Cloud’s universal semantic layer makes AI trustworthy.


Your AI Can Only Go as Far as Your Data Model


The ability to extract meaningful insights and make informed decisions hinges on our capacity to understand and interact with vast and complex datasets. For business users, this understanding isn't about database schemas and intricate joins; it’s about interpreting data through the lens of familiar business concepts like customers, products, revenue, and churn. This is where semantics comes into play – the layer of abstraction that translates the raw, technical language of data into the understandable vocabulary of the business. Imagine trying to decipher ancient hieroglyphics without a key – that’s the challenge business users face with raw data. A semantic layer acts as the Rosetta Stone, providing the definitions, relationships, and context needed to unlock meaning. It’s a business representation of corporate data, managed through business semantics management, offering a unified and consolidated view across the organization.

The recent explosion of interest in Artificial Intelligence, particularly Large Language Models (LLMs), has opened up exciting possibilities for automating data analysis and decision-making through AI Agents. AI Agents are envisioned to perceive, reason, plan, leverage tools, and act autonomously to solve complex business problems. From answering natural language questions about performance to proactively identifying anomalies and suggesting actions, the potential of AI Agents in data analytics is transformative.

However, just as a human analyst needs a solid understanding of the business and its data to perform effectively, so too do AI Agents. Simply feeding raw database schemas to an LLM and expecting it to generate accurate SQL queries to answer complex business questions is a recipe for disaster. This approach, known as text-to-SQL, has been conclusively proven to be inferior to using a semantic layer with an LLM. It’s akin to asking someone who speaks only English to translate a complex legal document written in Mandarin simply by showing them the character set – the fundamental understanding of meaning and context is missing.

This is where semantic layers become utterly indispensable for building enterprise-grade AI Agents focused on data analytics. Without this foundational layer, AI Agents risk generating inaccurate results, making flawed recommendations, and ultimately failing to deliver on their promise.

A key aspect of a semantic layer is its inherent nature as a knowledge graph. A knowledge graph is a massive, interconnected web of facts that illustrates the semantic relationships between entities. By encoding domain knowledge and business logic, knowledge graphs within semantic layers provide the essential business context that AI Agents need to interpret data accurately. They define the concepts, relationships, and rules that your AI Agent uses to make sense of the world. For an AI Agent to truly understand that a "customer" in one system is the same as a "client" in another, or how "discounts" and "returns" impact "adjusted revenue," it needs this codified business context – the interconnected knowledge that a semantic layer provides.

However, while all semantic layers embody the principles of a knowledge graph, very few knowledge graphs function as semantic layers in the context of data querying and AI Agents. A standalone knowledge graph might excel at representing relationships, but it often lacks the crucial mechanisms needed for seamless data interaction, particularly with underlying data warehouses. The distinguishing factor lies in the compiler and the interfaces that a semantic layer offers.

A semantic layer typically includes a compiler that can take a simplified request, often expressed in a high-level query format, and deterministically translate it into executable SQL that can be run against the data warehouse. This is a game-changer for AI Agents. Instead of having to grapple with the intricacies of database schemas, table joins, and aggregation functions, an AI Agent leveraging a semantic layer can simply request "total revenue for product X last month" using business terms. The semantic layer's compiler, armed with the codified business logic and understanding of the underlying data model, takes care of generating the correct, optimized SQL query.

This capability drastically reduces the risk of AI hallucinations – the generation of incorrect or nonsensical information. Without a semantic layer acting as a guardrail, an AI Agent attempting text-to-SQL might make incorrect assumptions about data relationships or metric calculations, leading to flawed outputs. The semantic layer, by providing a centralized framework that defines key metrics and business logic, embeds metadata, and offers business context, ensures that the AI system queries only approved, governed, and contextualized metrics.

Consider the earlier example of "adjusted revenue". Without a semantic layer, an AI Agent might struggle to define this metric accurately, potentially leading to untrustworthy data. However, with a semantic layer in place, "adjusted revenue" is clearly defined, accounting for discounts, returns, and currency fluctuations. 

The benefits of using a semantic layer for AI Agents extend far beyond preventing hallucinations:

- __Consistency and Governance__: A semantic layer ensures that metrics and business logic are applied consistently across teams and systems, providing a single source of truth. It also facilitates governance by restricting access to sensitive data and tracking changes to metrics, ensuring compliance and trust.
- __Context for Smarter Decisions__: By embedding metadata, defining relationships between data elements, and standardizing business logic, the semantic layer provides AI Agents with the deep contextual understanding needed to answer complex questions and uncover meaningful insights.
- __Improved Performance and Scalability__: Semantic layers often incorporate smart caching mechanisms and pre-aggregation capabilities, allowing AI Agents to retrieve data and insights much faster than querying raw data directly. This also streamlines scaling by allowing the reuse of standardized metrics across projects.
- __AI Preparedness__: The structured and consistent nature of a semantic layer, along with its compiler and interfaces, provides the ideal foundation for AI agents to analyze data with higher accuracy. It allows AI to easily understand what data is available and how to ask for it in a simple, consistent format.

The evolution of semantic layers, from their early forms in BI tools to the modern standalone solutions, underscores their enduring value in making data accessible and understandable. In the age of AI, they are no longer just a "nice-to-have" but act as the backbone for AI-powered data experiences. The combination of LLMs and semantic layers represents a powerful synergy – a "marriage made of data" – where the LLM's natural language understanding capabilities are coupled with the semantic layer's structured knowledge and governed access to data.

While the allure of directly asking an AI to query data is strong, the reality is that without the intermediary of a well-defined semantic layer, these interactions are prone to error and inconsistency. The semantic layer provides the necessary constraints and context that enable AI Agents to operate reliably and deliver trustworthy insights. It bridges the gap between raw data and business meaning, ensuring that AI's analytical prowess is grounded in a solid understanding of the organization's key concepts and metrics.

In conclusion, for organizations looking to harness the power of AI Agents for data analytics, a semantic layer is not merely an option – it is a fundamental prerequisite. It acts as the crucial Rosetta Stone, translating the complexities of data into the understandable language of business, providing the essential knowledge graph for context, and offering the vital compiler for seamless data interaction. By investing in a robust semantic layer, businesses can ensure that their AI Agents are not just powerful tools, but also reliable, consistent, and ultimately, successful in driving data-driven decisions. The future of intelligent data analysis hinges on this critical link between AI and well-defined, semantically rich data.

[Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=semantic-core-blog) to learn more.


Why Agentic AI Needs a Semantic Core


In [part three](https://cube.dev/blog/from-data-chaos-to-data-clarity-how-cube-cloud-empowers-decision-makers-with), we explored the journey from data chaos to data clarity, highlighting how Cube Cloud brings structure, speed, and trust to fragmented analytics workflows. Today, we’re addressing a common and costly assumption in the modern data stack: that your cloud data warehouse is enough.

Don’t get us wrong: cloud data warehouses are essential. Platforms like Snowflake, Databricks, BigQuery, and Redshift have revolutionized how organizations store and process data at scale. But even the most powerful data warehouse doesn’t solve the challenges of consistency, governance, and performance across all tools.

In this blog, we’ll unpack the limitations of a warehouse-only approach and show why Cube Cloud’s universal semantic layer is the critical missing piece in your data strategy.

## Your Stack Is Powerful, But Not Consistent
Cloud data warehouses give organizations the scale, elasticity, and power to run massive analytical workloads. But the warehouse is just one part of the data stack. It’s where data lives, not how it’s interpreted, accessed, or governed across your teams and tools.

Here’s the issue: without a semantic layer, every downstream consumer, such as AI, BI, spreadsheets, and embedded analytics, interprets the data independently. That leads to:
- Inconsistent KPIs across tools
- Redundant and conflicting business logic
- Slow queries and frustrated users
- Siloed governance policies that are hard to enforce

Warehouses store data efficiently. But they don’t ensure consistency, optimize user-facing performance, or govern how that data is consumed across the enterprise. That’s where a universal semantic layer comes in.

## The Hidden Gaps in a Warehouse-Only Approach
Let’s explore three core gaps data leaders encounter when relying solely on a warehouse.

__1. Inconsistency in Metric Definitions__

Data warehouses store raw and transformed data. But metric definitions, like revenue, churn, or lifetime value, are often recreated in BI tools or notebooks. Power BI users define revenue one way. Tableau dashboards use a slightly different calculation. Product analytics in a custom app calculates it differently still. Over time, these definitions drift. Teams build logic tailored to their tools. As a result, even if everyone’s pulling from the same tables, they get different answers to the same question.

__2. Governance that Doesn’t Scale__

Warehouses allow you to define permissions at the schema or table level. But once data is in a BI tool or spreadsheet, those controls are no longer enforced. Users might see more data than they should. Sensitive information could be exported to insecure environments. Compliance risks grow with every new tool added to the stack. Without centralized governance across tools, security becomes fragmented and reactive.

__3. Performance Bottlenecks and User Frustration__

Large data volumes, complex joins, and unoptimized queries can strain even the best data warehouses. And if users experience slow dashboards or timeouts, they often turn to Excel for faster answers, downloading data from your BI tool, which bypasses governance and consistency altogether. You’re left with growing warehouse costs, sluggish analytics, and business teams operating outside of governed systems.

## The Role of Cube’s Universal Semantic Layer
A universal semantic layer sits between your data warehouse and the tools that consume data. It standardizes metrics, enforces governance, and optimizes performance, transforming your warehouse into a single source of truth.

Cube Cloud is the universal semantic layer built for the modern data stack. It connects directly to your warehouse and provides a centralized layer to unify, govern, and optimize data access across every interface. Let’s break down what Cube Cloud adds to your warehouse:

__1. Unify: Standardize Metrics Across All Tools__

Define your models and metrics once in Cube Cloud, and expose them consistently across AI, BI, spreadsheets and embedded analytics. Unlike data warehouse views or duplicate data sources within tools, Cube makes your data AI- and BI-ready, allowing you to share and reuse data definitions and business logic for every data consumer. This eliminates metric drift and ensures that every user, no matter what tool they prefer, sees the same trusted numbers.

__2. Govern: Apply Consistent Security and Access Controls__

With Cube Cloud, you can enforce data access controls and policies upstream from data consumers with features like role-based access control (RBAC), row-level security, attribute-based filtering, audit logging for compliance. These controls are applied centrally so you no longer have to configure and maintain access policies in every tool separately. That means stronger security with less overhead.

__3. Optimize: Deliver Fast, Scalable Performance__

Cube Cloud includes intelligent caching, query acceleration, and pre-aggregation capabilities that significantly reduce query times. Now you can have BI dashboards load in sub-seconds, high-concurrency apps don’t overload the warehouse, and faster answers for business users without resorting to spreadsheets. This allows you to scale insights—without scaling costs or frustration.

__4. Integrate: Ditch Direct Database Connections and Move to API-Based Access__

With an API-based approach, your unified data models and governed metrics can be delivered wherever it’s needed. This flexibility ensures that your organization can easily execute on its data strategy across the enterprise, maximizing the value of both modern OLAP and AI analytics without disrupting existing workflows.

## Increase the Value of Your Warehouse Investment
The modern data stack is maturing. Warehouses solved for storage and scale but not insight delivery in what people see, how fast they see it, and whether they trust it. That is the role of the universal semantic layer. Cube Cloud’s universal semantic layer doesn’t replace your warehouse. It makes your warehouse smarter, safer, and more valuable to every team in the business.

In part five of the series, we’ll explore how data leaders can build analytics ecosystems that deliver trustworthy, data-backed decisions with consistency, governance, and performance built in from the ground up. Want to take your warehouse from storage to strategy? [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=exec%20blog4) to see how Cube Cloud can help you get the most from your data stack.


Why Your Data Strategy Needs More Than a Warehouse for Confident Decisions


So far in parts [one](https://cube.dev/blog/consistent-data-confident-decisions-why-a-universal-semantic-layer-is) and [two](https://cube.dev/blog/the-confidence-gap-how-inconsistent-data-undermines-business-decisions), we’ve looked at why organizations need a universal semantic layer to ensure consistency in their analytics, and how the absence of one leads to the confidence gap where decision-makers no longer trust the data in front of them.

In part three, we’ll zoom in on the transformation from data chaos to data clarity. For most data leaders, chaos isn’t about lack of tools. It’s about a growing web of conflicting metrics, redundant logic, and tool-specific workarounds. The result is a system that technically “works” but functionally slows down decisions, undermines trust, and frustrates every user.

Let’s explore what that chaos looks like, how Cube Cloud clears the clutter, and what it means for the people who rely on your data every day.

## The Reality of Data Chaos
“Data chaos” is a common condition in modern organizations, especially as data stacks have grown more complex. It stems from having too many ungoverned ways to interact with it. Even within a single BI tool, duplicate content and data sources lead to more questions than answers. That chaos manifests in ways that hurt productivity and alignment. Common signs of data chaos include:

- Inconsistent definitions of key metrics like revenue, active users, or customer churn across teams.
- Redundant data modeling efforts in every BI tool or reporting layer.
- Manual data exports into spreadsheets, leading to version control problems and data silos.
- Slow queries that drive users away from governed platforms and into shadow workflows.
- Disjointed governance policies that can’t keep up with tool proliferation.

The cost? A stack of dashboards and reports that no one fully trusts, hours lost to rework, and decision-making that lags behind the speed of the business.

## The Shift to Clarity: What It Takes
Clarity starts with alignment on metrics, access, performance, and trust. It requires a new layer in your data architecture that can sit between the cloud data platform and the BI tools people use to ask questions, explore trends, and make decisions. 

That’s where Cube’s universal semantic layer comes in. Cube Cloud brings order to the modern data stack by introducing a semantic layer that standardizes logic, governs access, and accelerates performance across all analytics and AI tools. Here’s how it works:

__1. Centralize Business Logic Once, Use Everywhere__
Cube Cloud allows you to define your KPIs, dimensions, and aggregations in one centralized place. From there, every downstream tool, whether it’s Power BI, Tableau, Excel, or a custom-built embedded dashboard, uses that shared model to access data. No more metric drift between tools and no more building the same logic five times in five tools. Now you can have a consistent, unified layer for your data stack.

__2. Govern Access Across All Interfaces__
With Cube Cloud, you can enforce role-based access controls (RBAC), row-level security, and data masking consistently, regardless of which tool is being used. That means data access policies are no longer tied to individual tools, but applied at the semantic layer level. The result: stronger compliance, simplified auditing, and less manual effort.

__3. Optimize Performance With Smart Caching and Pre-Aggregation__
Cube Cloud includes built-in caching and query acceleration capabilities that reduce query load on your warehouse and speed up dashboards. Business users get sub-second response times, even for complex queries. Data teams don’t need to manually tune queries or build pre-aggregated tables in the warehouse. Everyone wins with faster performance and a better user experience.

## What Clarity Looks Like for Different Stakeholders
When data chaos is resolved, every person in the organization benefits:

- __For Executives__: No more questioning the numbers. Cube Cloud ensures that dashboards reflect consistent, trustworthy insights so that decisions are made with speed and confidence.
- __For Data Teams__: Time spent troubleshooting, reconciling metrics, and firefighting dashboards disappears. Instead, data teams can focus on building smarter models, enabling self-service, and scaling analytics across the org.
- __For Business Users__: Dashboards just work. Numbers make sense. Spreadsheets become a convenience, not a crutch. And the friction between asking a question and getting an answer virtually disappears.
- __For Application Development Teams__: Embedded analytics and AI features use the same governed metrics as internal dashboards, ensuring consistency between product and operations, and reducing the risk of customer confusion or misinterpretation.

## Why Clarity Matters Now More Than Ever
With AI, real-time analytics, and embedded data experiences becoming the norm, enterprises can’t afford the friction of chaotic data systems. The companies that win will be those that deliver consistency, clarity, and confidence, not just access to data.

A universal semantic layer like Cube Cloud isn’t a nice-to-have. It’s a strategic foundation for modern decision-making. It’s how you go from scattered insights to systemic intelligence that drives the business forward.

## Next Up in the Confident Decisions Series
Now that we’ve made the case for data clarity, we’re going to dig into a common misconception next time: that your cloud data warehouse is enough. In part four, we’ll explain why a warehouse alone won’t solve consistency, governance, or performance problems and why Cube Cloud is the missing piece to connect cloud data platforms and data consumers with consistency. Want to bring clarity to your data stack? [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=exec%20blog3) to see how Cube Cloud can eliminate chaos and make your data truly actionable.


From Data Chaos to Data Clarity: How Cube Cloud Empowers Decision-Makers with Trustworthy Insights


We know how important observability is for teams running a semantic layer at scale. Whether you're troubleshooting long-running queries, optimizing pre-aggregation usage, or building internal usage-based reporting, custom query-level insights are handy.

**Today, we’re announcing Query History export**, a new Cube Cloud feature that lets you export [Query History](https://cube.dev/docs/product/workspace/query-history) data to your existing monitoring and observability tools (one of many [supported ones](https://vector.dev/docs/reference/configuration/sinks/), including something as simple as an S3 bucket on Amazon).

With Query History export, you can:
- Create custom reports on query performance.
- Alert when queries fail or bypass configured pre-aggregations.
- Analyze your semantic layer usage by different security contexts and implement chargebacks to your own customers.
- Archive and retain your Query History data indefinitely.

Watch the Query History demo to see what is exported and what is unlocked:

<div><div style={{position: 'relative', paddingTop: '75%'}}><iframe src="https://www.youtube.com/embed/6Xf2ayeQZC8" style={{position: 'absolute', top: 0, left: 0, width: '100%', height: '100%'}} frameBorder="0" allowFullScreen></iframe></div></div>

Query History export is available on the **M tier of Monitoring Integrations**. You can read more about [Monitoring Integrations pricing](https://cube.dev/docs/product/deployment/cloud/pricing#monitoring-integrations-tiers) and get more details about [Query History export](https://cube.dev/docs/product/workspace/monitoring#query-history-export) in the documentation.

**Ready to get started?** Switch to the M tier of Monitoring Integrations and try Query History export today in Cube Cloud. If you'd like a solutions architect to guide your implementation, please [talk to us](https://cube.dev/contact).


Dmitriy Rusov

Introducing Query History export


For years, data governance, the combination of roles, policies, and processes that make data trusted and enable responsible use, was the cornerstone of enterprise data strategy. Every data leader knew the playbook: define ownership, enforce standards, establish lineage, and implement controls to ensure data is accurate, secure, and used appropriately. However, organizations still experience mixed results from many [lingering BI issues](https://cube.dev/blog/the-harsh-lessons-of-modern-bi-and-why-scaling-ai-will-be-even-harder).

Now, AI has entered the chat with the same underlying concerns, only amplified. While AI has an endless supply of answers, many questions remain. Who owns the model? Can you trust its outputs? Is the data used to train or query the model governed? Is it biased? Are decisions traceable? Organizations must now focus on [AI literacy](https://cube.dev/blog/ai-literacy-is-the-new-data-literacy-why-a-semantic-layer-is-the-missing) for their data teams to build the right foundation, while bringing people, process, and technology together.

The rise of generative and agentic AI has pushed governance from a back-office IT concern to a boardroom imperative. But here’s the truth: you can’t have AI governance without strong data governance. And even more importantly, you can’t scale AI governance unless it’s built into the systems AI relies on. That’s where Cube Cloud’s universal semantic layer plays a defining role. It centralizes business logic, ensures consistency, and enables AI to generate responses that are not just fast, but trusted, auditable, and aligned with enterprise standards.

## What Is AI Governance?
AI governance refers to the framework of policies, processes, and controls that guide the responsible use of AI technologies. It ensures AI operates within acceptable boundaries, ethically, legally, and strategically. But unlike traditional data governance, AI governance adds layers of complexity:

- Model behavior and interpretability
- Prompt input and response output control
- Bias mitigation in generated content
- Versioning and change management of semantic and model logic
- Auditability of AI-driven decisions
- Security and compliance for data used in AI training or querying

While the goals of accuracy, consistency, and security are similar to data governance, the scope is broader and the consequences of failure more public. A flawed dashboard might cause confusion. A flawed AI-generated report could trigger a legal investigation.

## Why AI Governance Fails Without Data Governance
It’s important to remember that AI doesn’t reason as humans do. It synthesizes patterns in the data it’s trained on and queried with. If that data isn’t governed—if metrics are inconsistent, definitions vary, or calculations aren’t understood—then no amount of prompt engineering or model fine-tuning will save you. The result is fast answers no one trusts. Data governance gives you the raw materials of trust. But raw materials aren’t enough. AI systems need to interpret and apply that governance consistently in real time. That’s where most organizations hit a wall.

## Where AI Governance Meets Business Logic
Cube Cloud is the AI- and BI-ready universal semantic layer that translates governed data into business-ready answers. It ensures that every AI system from copilots and chat interfaces to LLM-powered analytics agents accesses a consistent, auditable, and contextualized representation of your data. Here’s how Cube Cloud enables AI governance in practice:

__1. Centralize Business Definitions Across All AI Outputs__

With Cube Cloud, you define metrics like “Customer Churn,” “Gross Margin,” or “MRR” once in plain, auditable, version-controlled YAML, then expose them to every tool, including AI interfaces. This means when an AI tool answers a question about churn, it’s using the same business logic your CFO signed off on, instead of its own fuzzy interpretation of the word. AI governance starts with semantic consistency, and Cube enforces it.

__2. Trace Every Answer Back to Its Source__

A cornerstone of governance is auditability. You need to know where the data came from, what transformations were applied, and why a specific answer was generated. With Cube Cloud’s semantic layer, every AI-generated response can be traced back to the exact data model, metric definition, and data source. Whether the AI output appears in a Slack thread, an executive summary, or a web app, it’s backed by governed, inspectable lineage. This kind of visibility turns AI from a risky black box into a trustworthy system of record.

__3. Govern and Enforce Data Access Controls__

The problem with traditional governance is fragmentation with rules and definitions varying by BI tool, spreadsheet, or team. Cube solves this with a single source of truth that feeds every downstream data experience, including AI. Instead of building custom AI guardrails for every department or model, you define governance rules in Cube once and enforce them everywhere. This reduces risk, eliminates inconsistencies, and ensures compliance at scale. Whether AI is summarizing a dataset, generating a dashboard, or responding to a prompt, it’s doing so within the boundaries you’ve defined.

__4. Support Human-AI Collaboration, Not Confusion__

AI governance isn’t just technical. It’s cultural just like data governance. Employees need to understand what AI is doing, how it works, and why they can trust it. When AI confidently generates a financial summary, it needs to align with what the business actually reports. By embedding semantic understanding into AI interactions, Cube makes AI more predictable, interpretable, and aligned with human expectations. That’s essential for adoption and critical for compliance.

## AI Governance Is a Data Problem, Solved by Cube
Many companies are sprinting to define new AI governance frameworks, policies, and oversight committees. That’s necessary. But without a solid data foundation, those efforts are cosmetic at best.

The real opportunity lies in operationalizing data and AI governance through architecture. That’s exactly what Cube Cloud delivers. With a universal semantic layer at the center of your AI, data, and analytics strategies, you can ensure:

- Consistent answers across every AI interaction
- Trust in outputs, grounded in governed definitions
- Full transparency for audits, compliance, and internal review
- Scalable enforcement of business logic and access controls

## Govern Your Data, Govern Your AI
As generative and agentic AI take hold across the enterprise, data leaders must shift from enabling curiosity to enforcing confidence. Governance can no longer be a gatekeeper. It must be an enabler, but it can only do that if it lives inside the systems AI touches.

AI governance isn’t separate from data governance. It’s the next evolution of it. Cube Cloud is the bridge between the two, making sure every AI response is trustworthy and transparent for your business.

If you’re serious about scaling AI safely and confidently, start where trust begins: with your data, definitions, and semantic context. [Contact sales](https://cube.dev/contact) to learn more about how Cube Cloud centralizes logic, ensures consistency, and makes every answer traceable for the enterprise.


Artificial Intelligence

Application Development

Why AI Governance Starts with Data Governance 


In [part one](https://cube.dev/blog/consistent-data-confident-decisions-why-a-universal-semantic-layer-is) of the Confident Decisions blog series, we introduced the concept of the universal semantic layer and how it empowers consistent, trustworthy data across your stack. In part two, we’re zeroing in on the core problem it solves, the confidence gap.

The confidence gap is the disconnect between having data and being able to trust it. It’s that moment in a strategy meeting when two teams present different numbers for the same KPI. It’s the hesitation that creeps in when a dashboard looks “off.” It’s the countless hours data teams spend reconciling inconsistencies, while business leaders wait to make a call.

For modern organizations, this gap is more than an annoyance. It’s a liability. Let’s explore why it exists, how it manifests, and what you can do about it.

## When Everyone Has Data That No One Trusts
Most companies have no shortage of data. They’ve invested in cloud data platforms like Snowflake or Databricks. They’ve rolled out BI tools like Power BI, Tableau, and Looker. Now they’re exploring AI and maybe even a chatbot.

But they’ve often skipped the critical step of standardizing how data is defined, accessed, and interpreted. Without that, things fall apart quickly:
- One department defines “monthly active users” by logins, another by transactions.
- Sales metrics in Power BI differ from those in Excel.
- AI generates outputs based on different logic than the dashboards that present them.

This isn’t just a technical oversight. It’s a strategic problem. When teams can’t agree on the numbers, they delay action, debate decisions, and lose trust in the system that’s supposed to guide them.

## The Business Impact of the Confidence Gap
Let’s break down what this looks like in real life, from delayed decisions and redundant work to shadow workarounds and eroded trust.

|      |      |
| ---------- | ---------- |
| __Delayed Decisions__: Executives can’t act on misaligned reports. If Sales and Finance have different views of revenue, leadership has to pause and investigate, which often means yet another meeting to “get aligned.”       | __Redundant Work__: Data analysts spend hours reconciling conflicting reports and re-modeling data for each use case. They rewrite queries, compare spreadsheets, and try to figure out which version of the truth is closest to correct.       |
| __Shadow Workarounds__: Frustrated with slow dashboards or conflicting metrics, business users take matters into their own hands. They export to Excel, create local datasets, and bypass governance that open the door to errors and compliance risks.       | __Eroded Trust__: Once a dashboard has been wrong just once, executives are less likely to rely on it again. That one missed number creates a long-lasting ripple effect of doubt and disengagement promoting gut instincts over data-backed decisions.       |

## The Root Causes of Inconsistent Data
The confidence gap isn’t caused by bad intentions or poor tooling. It’s a byproduct of disconnected systems and duplicated logic. Here are the three biggest drivers:

- Metric Drift: Each BI tool has its own modeling layer. And each team defines metrics differently based on their immediate needs. Over time, those definitions drift apart until no one’s numbers match.
- Siloed Tools: Data may live in the same warehouse, but it’s consumed by different tools, such as AI, BI, spreadsheets, and embedded analytics. Without a universal semantic layer, each tool queries and interprets the data differently.
- Performance Issues: When dashboards are slow or queries time out, users seek workarounds. They extract data, create local reports, and rebuild logic manually, creating more inconsistencies and fragmenting governance.

## How Cube Cloud Closes the Confidence Gap
Cube Cloud’s universal semantic layer eliminates these root causes by acting as a central source of logic, governance, and performance optimization.

Once you centralize metric definitions for all of your business data, Cube Cloud lets data teams define KPIs and calculations once, then expose them consistently across every downstream tool. Whether it’s Power BI, Looker, Tableau, Excel, or AI, every data consumer sees the same numbers. The result? No more metric drift or “who owns this definition?”. 

Direct database connections in every data consumer leads to vendor lock-in. Cube Cloud makes data accessible via its SQL, REST, GraphQL, MDX, DAX, and AI APIs, so that any application can query it consistently. Whether you’re building a dashboard, querying data with an LLM, or developing an embedding application, you get governed, standardized AI- and BI-ready data every time.

No one likes degraded data performance with growing volumes. Cube Cloud intelligently caches and pre-aggregates queries, dramatically improving performance for large datasets and complex queries. This keeps dashboards snappy, reduces load on your warehouse, and eliminates the need for manual exports or spreadsheet workarounds.

Without consistent security, governance, and compliance, your data is at risk. With features like role-based access control, row-level security, and audit logging, Cube Cloud enforces your governance policies across every tool and every user. You can meet compliance requirements without sacrificing flexibility.

## Rebuild Trust In Your Data
As a data leader, your job isn’t only to deliver data. It also includes delivering confidence in the decisions that data supports. And that confidence comes from consistency, performance, and governance. These are three capabilities Cube Cloud is built to deliver.

If your organization is stuck in the cycle of second-guessing dashboards and reconciling metrics, it’s time to stop plugging holes and start solving the root problem. Cube Cloud provides the universal semantic layer your stack has been missing.

## Coming Up Next in the Confident Decisions Series
Next, we’ll explore how Cube Cloud helps organizations go from data chaos to clarity, empowering every user to explore, report, and act on trustworthy data, without fear or friction. Ready to close the confidence gap for good? [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=exec%20blog2) to see how Cube Cloud rebuilds trust in your data.


The Confidence Gap: How Inconsistent Data Undermines Business Decisions


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


Cube Core version 1.3 is the [latest release](https://github.com/cube-js/cube/releases/tag/v1.3.0) to date. It includes various improvements to [performance](#performance-optimizations), [data source support](#new-in-data-source-support), and a few [API endpoints](#new-in-apis).

__This release contains breaking changes.__ Before upgrading, please familiarize yourself with the following changes and make sure to adjust your data model and configuration if needed:
- [Non-strict date range matches in pre-aggregations](#breaking-non-strict-date-range-matches-in-pre-aggregations)
- [Removal of top-level `includes` and `excludes` in views](#breaking-removal-of-top-level-includes-and-excludes-in-views)
- [New API scope for the `/v1/sql` endpoint](#breaking-new-api-scope-for-the-v1sql-endpoint)
- [Updates to data source concurrency](#important-updates-to-data-source-concurrency)
- [Fixes to `extends`](#important-fixes-to-extends)

Also, we recommend testing major and minor releases on a staging environment before bringing them to your production environment.

## BREAKING: Non-strict date range matches in pre-aggregations

Previously, we've introduced the [`allow_non_strict_date_range_match` parameter](https://cube.dev/docs/reference/data-model/pre-aggregations#allow_non_strict_date_range_match) for pre-aggregations to enable them to match queries with date ranges that are not necessarily aligned with the start or the end of pre-aggregation partitions. This is particularly useful when connections Cube to BI tools such as Tableau or Apache Superset because they use such loose date ranges by default.

Now, this is the default behavior for all pre-aggregations, controlled via the [`CUBEJS_PRE_AGGREGATIONS_ALLOW_NON_STRICT_DATE_RANGE_MATCH` environment variable](https://cube.dev/docs/reference/configuration/environment-variables#cubejs_pre_aggregations_allow_non_strict_date_range_match). You can opt out for all pre-aggregations by using this environment variable or for individual pre-aggregations by using their `allow_non_strict_date_range_match` parameter.

We think that the convenience and performance gains of using pre-aggregations to accelerate queries generated by BI tools far outweights a tiny chance of data inaccuracy caused by non-strict date range matching.

## BREAKING: Removal of top-level `includes` and `excludes` in views

Previously, it was possible to define a view using top-level `includes` and `excludes` parameters, like in the following example. These parameters were [deprecated](https://github.com/cube-js/cube/blob/master/DEPRECATION.md#deprecated-features) in v0.34.34 and now they are finally removed.

```yaml
cubes:
  - name: my_cube
    sql: SELECT 123
    measures:
      - name: count
        type: count

views:
  - name: my_view
    # Don't do this!
    includes:
      - my_cube.count
```

Instead, [`cubes`](https://cube.dev/docs/reference/data-model/view#cubes) and [`join_path`](https://cube.dev/docs/reference/data-model/view#join_path) parameters should be always used so that you can explicitly control join paths.

## BREAKING: New API scope for the `/v1/sql` endpoint

Previously, the [`/v1/sql` endpoint](https://cube.dev/docs/product/apis-integrations/rest-api/reference#base_pathv1sql) of the REST API was part of the `data` [API scope](https://cube.dev/docs/product/apis-integrations/rest-api#api-scopes).

Now, this endpoint is moved to the new `sql` API scope, allowing for more granular access control. The `sql` scope is included into the list of default API scopes, configurable via the [`CUBEJS_DEFAULT_API_SCOPES` environment variable](https://cube.dev/docs/reference/configuration/environment-variables#cubejs_default_api_scopes). Unless you have explicitly configured that list, this change should not be breaking for you.

[Read more](#new-in-apis) about improvements to the `/v1/sql` API endpoint below. 

## IMPORTANT: Updates to data source concurrency

To ensure optimal querying performance, concurrency settings were [adjusted](https://github.com/cube-js/cube/commit/7ef628273905d47996b108862a52dde89b9525e3) for a few popular data sources such as Amazon Athena, Amazon Redshift, ClickHouse, Databricks, and Snowflake.

There's now a new [documentation page](https://cube.dev/docs/product/configuration/concurrency) that explains concurrency and lists [concurrency settings](https://cube.dev/docs/product/configuration/concurrency#data-source-concurrency) for popular data sources. It's recommended to use the default configuration unless you have performed your own testing to ensure that your data source can handle more concurrent queries.

Finally, it's now possible to configure refresh worker concurrency via the specific [`CUBEJS_REFRESH_WORKER_CONCURRENCY` environment variable](https://cube.dev/docs/reference/configuration/environment-variables#cubejs_refresh_worker_concurrency).

## IMPORTANT: Fixes to `extends`

Various bugs related to the [cube inheritance](https://cube.dev/docs/product/data-modeling/concepts/code-reusability-extending-cubes) and the [`extends` parameter](https://cube.dev/docs/reference/data-model/cube#extends) were fixed:

- [Joins](https://github.com/cube-js/cube/issues/7137), [pre-aggregations](https://github.com/cube-js/cube/issues/9269), and access policies are now correctly inherited.
- It is now [possible](https://github.com/cube-js/cube/issues/8519) to use the `sql` parameter in a parent cube and the `sql_table` parameter in a child cube and vice versa.

In case your data model relied on the faulty behavior when some of cube members were not correctly inherited, you can fall back to it by explicitly redefining inherited members:

```yaml
cubes:
  - name: other
    sql: SELECT 123 AS id
    dimensions:
      - name: id
        sql: id
        type: number
        primary_key: true
    measures:
      - name: count_other
        type: count

  - name: parent
    sql: SELECT 456 AS id
    dimensions:
      - name: id
        sql: id
        type: number
        primary_key: true
    joins:
      - name: other
        sql: 1 = 1
        relationship: one_to_one
    measures:
      - name: count
        type: count

  - name: child
    extends: parent
    # Now works!
    sql_table: child_table
    # Join to `other` is inherited from `parent`
```

## Performance optimizations

### Query orchestration speed-up with native code

We've implemented a number of performance optimizations, such as deserializing Cube Store result sets in native Rust code, that should have positive impact on query performance. We're rolling these changes out in this release by settings the [`CUBEJS_TESSERACT_ORCHESTRATOR` environment variable](https://cube.dev/docs/reference/configuration/environment-variables#cubejs_tesseract_orchestrator) to `true` by default.

### Compilation speed-up with worker threads

We've improved the data model compilation by moving critical parts of the code to worker threads. You can opt in and enable this optimization by setting the `CUBEJS_TRANSPILATION_WORKER_THREADS` environment variable to `true`.

If you encounter any issues or see any changes/improvements to your deployments, please [report on GitHub](https://github.com/cube-js/cube/issues/9285).

## New in data source support

Various fixes were applied to Amazon Redshift, ClickHouse, Databricks, DuckDB, Dremio, Snowflake drivers. Additionally, these improvements are included:

- [Added](https://github.com/cube-js/cube/pull/9341/files) an option to turn on client compression for [ClickHouse](https://cube.dev/docs/product/configuration/data-sources/clickhouse).
- [Added](https://github.com/cube-js/cube/commit/6f431388d0c207923ea990bab55c22c79d217e5b) `databasePath` and `motherDuckToken` configuration options for [DuckDB](https://cube.dev/docs/product/configuration/data-sources/duckdb).
- [Added](https://github.com/cube-js/cube/commit/df763cc9a375eb656d6ac4dc10adbd9a68082a0e) options to configure StarTree authentication and null handling for Pinot.
- [Migrated](https://github.com/cube-js/cube/commit/29fdd615f7eb70690f5fc85897e0c93a5a0cc29a) to the newest backwards-compatible [vendor-developed driver](https://docs.databricks.com/aws/en/integrations/jdbc/oss) for Databricks.

### Key-pair authentication for Snowflake

The support for _encrypted private keys_ was [added](https://github.com/cube-js/cube/commit/ab54e2817dc4e14f0e1ea3b1257b3a08072c954c) for [Snowflake](https://cube.dev/docs/product/configuration/data-sources/snowflake). You can now use the [`CUBEJS_DB_SNOWFLAKE_PRIVATE_KEY_PASS` environment variable](https://cube.dev/docs/reference/configuration/environment-variables#cubejs_db_snowflake_private_key_pass) to provide the encryption key.

This is particularly important since [Snowflake deprecates single-factor password sign-ins for service users](https://docs.snowflake.com/en/user-guide/security-mfa-rollout) and recommends using [key-pair authentication](https://docs.snowflake.com/en/user-guide/key-pair-auth).

### GCS export bucket for Databricks

You can now use [export buckets on Google Cloud Srorage](https://cube.dev/docs/product/configuration/data-sources/databricks-jdbc#google-cloud-storage) with [Databricks](https://cube.dev/docs/product/configuration/data-sources/databricks-jdbc). With this update, Databricks support for export buckets now includes all three major cloud platforms.

## New in APIs

### Support for rebuilding specific pre-aggregation partitions

The [`/v1/pre-aggregations/jobs` API endoint](https://cube.dev/docs/product/apis-integrations/rest-api/reference#base_pathv1pre-aggregationsjobs) allows to trigger pre-aggregation build jobs or retrieve their statuses. It supports targeting pre-aggregations by security contexts, time zones, data sources, cubes, and names.

Now it also supports targeting specific partitions of those pre-aggregations by specifyng a date range that those partitions intersect with by their build range. See the following example utilizing the new `dateRange` parameter:

```bash
curl \
  -d '{
    "action": "post",
    "selector": {
      "contexts": [{ "securityContext": { "tenantId": "tenant1" } }],
      "timezones": ["America/Los_Angeles"],
      "preAggregations": ["orders.main"],
      "dateRange": ["2020-01-01", "2020-02-01"]
    }
  }' \
  -H "Authorization: EXAMPLE-API-TOKEN" \
  -H "Content-Type: application/json" \
  -X POST \
  https://localhost:4000/cubejs-api/v1/pre-aggregations/jobs
```

### Support for SQL API queries in the `/v1/sql` endpoint

The [`/v1/sql` API endpoint](https://cube.dev/docs/product/apis-integrations/rest-api/reference#base_pathv1sql) takes an API query and returns the SQL query, generated by Cube, that can be executed against the data source. This is useful for debugging, understanding how Cube translates API queries into SQL queries, and providing transparency to SQL-savvy end users. Previously, only [REST API queries](https://cube.dev/docs/product/apis-integrations/rest-api/query-format) were supported.

Now, you can also pass a [SQL API query](https://cube.dev/docs/product/apis-integrations/sql-api/query-format) and get the generated query for it, if possible. See the following example utilizing the new `format` parameter:

```bash
curl \
  -H "Authorization: TOKEN" \
  -G \
  --data-urlencode 'query=SELECT COUNT(*) FROM orders' \
  --data-urlencode 'format=sql'  \  
  http://localhost:4000/cubejs-api/v1/sql
```

Response:

```json
{
  "sql": {
    "status": "ok",
    "sql": [
      "SELECT\n      count(\"base_orders\".id) \"count_uint8_1__\"\n    FROM\n      (SELECT * FROM 's3://cube-tutorial/orders.csv') AS \"base_orders\"  LIMIT 50000",
      []
    ],
    "query_type": "regular"
  }
}
```

## New in pre-aggregations

The support for specifying a subpath (folder) inside the storage bucket was introduced for the case when MinIO is used with Cube Store. It can be set via the new [`CUBESTORE_MINIO_SUB_PATH` environment variable](#cubestore_minio_sub_path). Community members who have tested it report better stability of MinIO in this setup.

## New in the documentation

A few highlights to the updates in the documentation:
- New recipe: [Implementing custom calendars](https://cube.dev/docs/guides/recipes/data-modeling/custom-calendar), e.g., 4-5-4 retail calendar.
- New recipe: [Calculating filtered aggregates](https://cube.dev/docs/guides/recipes/data-modeling/filtered-aggregates).
- API references have been moved to the [APIs & integrations](https://cube.dev/docs/product/apis-integrations) section. Example: [SQL API reference](https://cube.dev/docs/product/apis-integrations/sql-api/reference).

## Version upgrades

This release also upgrades Node.js, used internally by Cube, to v22. Node.js v20 is now deprecated, and the support for Node.js v18 has been [removed](https://github.com/cube-js/cube/blob/master/DEPRECATION.md#nodejs-18).

## What's next?

After checking these release notes, please upgrade and give this release a try. You can also do that for free in [Cube Cloud](https://cubecloud.dev/auth/signup).

We can't wait to hear your feedback and thoughts in the [Slack community](https://slack.cube.dev), both about the updates above and the features from the [Cube Core public roadmap](https://github.com/cube-js/cube/issues/8492).

Enjoy the new features and happy Cube-ing!


Cube Core v1.3 — Performance improvements and upgrades


Fine-grained access control is essential for delivering the correct data to the right people. Data teams must ensure that users only see what they're supposed to see without slowing down development cycles or duplicating logic across dashboards, APIs, and applications. That's where Cube Cloud's data access controls come in.

As the universal semantic layer platform, Cube Cloud delivers a unified, governed, and scalable way to enforce data security across every data experience, including AI, BI, spreadsheets, and embedded analytics. With query rewrite, Data Access Policies, LDAP integration, and Cube Cloud authentication, organizations can now centrally manage access at the row, column, and member level using flexible configuration in Cube's data model. In this blog, we'll explore different techniques to help you implement access control strategies that are secure, maintainable, and enterprise-ready.

## Implementing Data Access Controls
Imagine your company has a lot of information, some very private, like customer details or employee salaries. Data access policies are rules that decide who gets to see what information. Just like you wouldn't give everyone a key to your house, you don't want everyone in your company to see all the data. These policies help keep sensitive information safe and ensure it's only used by the right people for the right reasons. For example, a customer support agent might need to see a customer's order history to help them, but they shouldn't be able to see that customer's payment information. Data access policies allow you to set up these permissions, so everyone gets the data they need for their job, but nothing more.

Cube offers robust solutions for implementing granular security, including row-level, column-level, and member-level access control. Developers can dynamically restrict data visibility based on user attributes and roles by leveraging features like `queryRewrite`, `COMPILE_CONTEXT`, and Data Access Policies. This ensures that sensitive information is only accessible to authorized users, enhancing data security and compliance within applications powered by Cube.

1. __Row-Level Security:__ Implemented using `queryRewrite`, `COMPILE_CONTEXT` in data models, or access_policy with row_level parameters. These methods filter data based on user attributes, ensuring users only see authorized data.
2. __Column-Level Security:__ Implemented by invalidating queries in `queryRewrite`, conditionally including fields using `COMPILE_CONTEXT`, or using `member_level` parameters in access_policy. These methods restrict access to specific fields based on user roles or attributes.
3. __Member-Level Security:__ Controls the visibility of data model entities (cubes, views, members) using `queryRewrite`, `COMPILE_CONTEXT` to dynamically control entity public property, or member_level parameters in access_policy to define allowed or disallowed members. By default, all entities are public.

## Row-Level Security in Cube

In simple terms, row-level security is like having a special filter on your data. Imagine you have a big spreadsheet with lots of rows, each representing a customer's order. Row-level security ensures that when someone looks at that spreadsheet, they only see the rows they're allowed to see.

For example, a customer service agent might only be able to see the rows (orders) that belong to the customers for whom they are responsible. They wouldn't be able to see orders from other customers. It's like having personalized views of the same data, where each person only sees the information relevant to them. So, instead of everyone seeing all the data, row-level security ensures everyone just gets to see "their" rows.

Row Level Security (RLS) is a powerful feature in Cube that lets you restrict data access based on user attributes. The security context is the foundation of RLS in Cube. It contains user-specific information (like user ID, role, or organization) that Cube uses to determine what data a user can access.

There are three main approaches to implementing RLS in Cube:
### 1. Using [queryRewrite](https://cube.dev/docs/product/configuration/multitenancy#queryrewrite-vs-multitenant-compile-context) for Row-Level Security
The most common approach is using the queryRewrite function in your Cube configuration file:

*cube.py*
```python
from cube import config

@config('query_rewrite')
def query_rewrite(query: dict, ctx: dict) -> dict:
    """
    Dynamically add filters based on security context and queried cubes.

    """
    # Extract security context
    security_context = ctx.get('securityContext', {})

    # Example: Filter for orders cube
    if 'user_id' in security_context:
        query['filters'].append({
            'member': 'orders.user_id',
            'operator': 'equals',
            'values': [security_context['user_id']]
        })

    return query
```

This function intercepts every query, adds the necessary security filters, and ensures users can only see their data. A more realistic scenario would be injecting role-level security into views only. Assuming all views have a join path to a dimension that can be filtered by a user ID (e.g., email). You need to install [cube_utils](https://github.com/paco-valdez/cube-utils) to parse your query payload. You can install it by adding `cube_utils` to your `requirements.txt` file.

```python
from cube_utils.query_parser import extract_cubes
from cube import config

@config('query_rewrite')
def query_rewrite(query: dict, ctx: dict) -> dict:
    """
    Dynamically add filters based on security context and queried cubes.

    """
    # Extract user_id
    user_id = ctx.get('securityContext', {}).get('email', False)
    cubes = extract_cubes(query)
    views = set(['orders_view', 'line_items_view'])

    # Example: Filter for views if there's a view in the payload
    if user_id and views & set(cubes):
        query['filters'].append({
            'member': f'{cubes[0]}.user_email',
            'operator': 'equals',
            'values': [user_id]
        })

    return query
```

### 2. Using [COMPILE_CONTEXT](https://cube.dev/docs/reference/data-model/context-variables#compile_context) in Data Model
For more complex scenarios, you can embed security context directly in your data model:

```python
cubes:
  - name: orders
    sql: “SELECT * FROM orders o WHERE  o.user_created_by = {{ COMPILE_CONTEXT.securityContext.userId | safe }}”

    joins:
      - name: users
        relationship: many_to_one
        sql: "{CUBE}.user_id = {users}.id"
```

### 3. Using `row_level` [Data Access Policies](https://cube.dev/docs/reference/data-model/data-access-policies) 

You can use the `access_policy` parameter within cubes and views to configure [data access policies](https://cube.dev/docs/product/auth/data-access-policies) for them.

```python
cubes:
  - name: orders
    # ...

    access_policy:
      - role: "*"
        row_level:
          allow_all: false

      - role: manager
        row_level:
          filters:
            - member: state
              operator: equals
              values: [ "{ securityContext.state }" ]
```

## Column-Level Security in Cube
Think of your data as a big table with rows and columns. We already discussed row-level security, which lets you see only specific rows. Now, column-level security is about controlling which columns of that table you're allowed to see.

Imagine that same spreadsheet with customer orders. You might have columns like "Customer Name," "Order Date," "Items Ordered," and also "Credit Card Number." Column-level security lets you say, "Customer service reps can see the 'Customer Name', 'Order Date', and 'Items Ordered' columns, but they cannot see the 'Credit Card Number' column."

So, while row-level security decides which customers you can see data for, column-level security decides what details about those customers you're allowed to see. It's all about ensuring you only get access to the specific information you need to do your job, and nothing more.
In Cube, this can be implemented in several ways:

### 1. Using [queryRewrite](https://cube.dev/docs/product/configuration/multitenancy#queryrewrite-vs-multitenant-compile-context) for Column-Level Security
You can invalidate queries in query_rewrite if a user doesn’t have the necessary permissions. 

*cube.py*

```python
from cube_utils.query_parser import extract_members
from cube import config

@config('query_rewrite')
def query_rewrite(query: dict, ctx: dict) -> dict:
    """
    Dynamically add filters based on security context and queried cubes.

    """
    # Extract security context
    roles = ctx.get('securityContext', {}).get('roles', [])

    # Example: Invalidate query if email is not allowed
    if 'admin' not in roles and 'users.email' in extract_members(query):
        raise Exception(f'users.email not allowed for roles: {roles}')

    return query
```

2. Using [COMPILE_CONTEXT](https://cube.dev/docs/reference/data-model/context-variables#compile_context) to include fields conditionally

You can dynamically control field visibility based on the security context:

```python
cubes:
  - name: users
    sql_table: users

    dimensions:
      - name: id
        sql: id
        type: number
        primary_key: true

      - name: email
        sql: email
        type: string
        public: "{{ COMPILE_CONTEXT.securityContext.role == 'admin' }}"

      - name: phone
        sql: phone
        type: string
        public: "{{ COMPILE_CONTEXT.securityContext.role in ['admin', 'support'] }}"

      - name: salary
        sql: salary
        type: number
        public: "{{ COMPILE_CONTEXT.securityContext.department == 'finance' }}"
```

### 3. Using `member_level` [Data Access Policies](https://cube.dev/docs/reference/data-model/data-access-policies) 
The optional member_level parameter, when present, configures member-level access for a policy by specifying allowed or disallowed members.

You can either provide a list of allowed members with the includes parameter, or a list of disallowed members with the excludes parameter. 

```python
cubes:
  - name: orders
    # ...

    access_policy:
      - role: "*"
        member_level:
          # Includes nothing, i.e., excludes all members
          includes: []

      - role: manager
        member_level:
          # Includes all members except for `count`
          excludes:
            - count

      - role: observer
        member_level:
          # Includes all members except for `count` and `count_7d`
          excludes:
            - count
            - count_7d

      - role: guest
        # Includes only `count_30d`, excludes all other members
        member_level:
          includes:
            - count_30d
```

### Implementing Member-Level security in Cube
Let's talk about member-level security. Imagine you have different reports or dashboards in your company. Each report shows specific data, like "Sales Figures," "Customer Lists," or "Employee Salaries."

Member-level security is about controlling who can see all of those reports or specific parts within those reports.

The data model serves as a facade of your data. With member-level security, you can define whether [data model entities](https://cube.dev/docs/product/data-modeling/concepts) (cubes, views, and their members) are exposed to end users and can be queried via [APIs & integrations](https://cube.dev/docs/product/apis-integrations).

By default, all cubes, views, and their members are public, meaning that any user can access them, and they are also visible during data model introspection.

### 1. Using [queryRewrite](https://cube.dev/docs/product/configuration/multitenancy#queryrewrite-vs-multitenant-compile-context) for Member-Level Security
You can invalidate queries in query_rewrite if a user doesn’t have the necessary permissions. You need to install [cube_utils](https://github.com/paco-valdez/cube-utils) to parse your query payload.

*cube.py*

```python
from cube_utils.query_parser import extract_cubes
from cube import config

@config('query_rewrite')
def query_rewrite(query: dict, ctx: dict) -> dict:
    """
    Dynamically add filters based on security context and queried cubes.

    """
    # Extract security context
    roles = ctx.get('securityContext', {}).get('roles', [])

    # Example: Invalidate query if users cube is not allowed
    if 'admin' not in roles and 'users' in extract_cubes(query):
        raise Exception(f'users not allowed for roles: {roles}')

    return query
```

### 2. Using [COMPILE_CONTEXT](https://cube.dev/docs/reference/data-model/context-variables#compile_context) to include make entities public conditionally

You can also control whether a data model entity should be public or private dynamically.

In the example below, the `customers` view would only be visible to a subset of tenants that have the team property set to marketing in the security context:

```python
model/views/customers.yml
views:
  - name: customers
    public: "{{ is_accessible_by_team('marketing', COMPILE_CONTEXT) }}"

model/globals.py
from cube import TemplateContext

template = TemplateContext()

@template.function('is_accessible_by_team')
def is_accessible_by_team(team: str, ctx: dict) -> bool:
  return team == ctx['securityContext'].setdefault('team', 'default')
```

### 3. Using `member_level` [Data Access Policies](https://cube.dev/docs/reference/data-model/data-access-policies) 
The optional member_level parameter, when present, configures member-level access for a policy by specifying allowed or disallowed members.

You can either provide a shorthand for both parameters: includes: `"*", excludes: "*"`.

```python
cubes:
  - name: orders
    # ...

    access_policy:

      - role: manager
        member_level:
          # Includes all members
          includes:
            - "*"

      - role: observer
        member_level:
          # Excludes all members
          excludes:
            - "*"
```

## Example Scenario:
Imagine an e-commerce platform using Cube Cloud for analytics. This platform collects PII, including customer names, email addresses, phone numbers, and order history.

### Row-Level Security for PII:
- Using `queryRewrite` or `COMPILE_CONTEXT`, access can be restricted so that a customer service representative can only see the order history and PII of customers they are assigned to.
- For example, a query might only return orders where `orders.customer_email` matches the `email` within the `securityContext` of the logged-in representative. This prevents them from seeing other customers' data.
- Data Access Policies with `row_level` parameters can further enforce this, ensuring that even if a query tries to access all orders, the policy will filter the results based on the user's role or attributes.

### Column-Level Security for PII:
- Specific sensitive PII columns, like `users.phone` or `users.salary`, can be restricted to specific roles.
- Using `COMPILE_CONTEXT`, the `public` property of a dimension like users.email can be dynamically set based on the user's role. Only users with the "admin" role might see the `email` column, while others would not.
- `queryRewrite` can also invalidate queries that attempt to access restricted columns if the user's role does not have permission.
- Data Access Policies with `member_level` parameters can exclude sensitive members (columns) for specific roles.

### Member-Level Security for PII:
- Entire views or cubes related to highly sensitive PII could be restricted. For example, a "Full Customer Details" view might only be accessible to executives or compliance officers.
- `queryRewrite` can invalidate queries that try to access the "Full Customer Details" view if the user's role lacks the necessary permissions.
- `COMPILE_CONTEXT` can control the `public` property of views, making them visible only to specific teams or roles.
- Data Access Policies can exclude access to specific data model entities (cubes, views) for specific roles.

In all these cases, the securityContext plays a vital role. It carries information about the logged-in user, such as their `user_id`, `email`, `role`, or `department`. Cube Cloud uses this context to dynamically enforce access controls, ensuring that PII data is protected and only accessible to authorized individuals.

Therefore, these data access controls in Cube Cloud are highly relevant and essential for protecting PII data by limiting who can see what data, based on their role and permissions.

## Conclusion
Whether securing internal dashboards or powering analytics for thousands of external users, Cube Cloud gives you the tools to confidently control who sees what, without compromising on performance or developer velocity. With support for query rewriting, `COMPILE_CONTEXT`, and declarative Data Access Policies, Cube lets you enforce access rules close to the data model, so governance is baked into the analytics layer.

Now, with Cube Cloud authentication and LDAP integration, enterprises can bring their existing identity and permissions frameworks directly into Cube, enabling consistent and compliant access control at scale. As your organization grows in data complexity, Cube's approach ensures your access controls scale securely and seamlessly. [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=data%20governance%20blog) to learn more about how Cube can help you deliver trusted and governed data across AI, BI, spreadsheets, and embedded analytics.


Deep Dives

Ensuring Data Governance with Cube Cloud: Implementing Fine-Grained Access Controls


Today, every business needs consistent, trustworthy insights to fuel confident decision-making. While most companies have invested in modern cloud data platforms, BI tools, spreadsheets, and emerging AI solutions, they often find themselves stuck in the same loop of conflicting reports, redundant data modeling, and never-ending debates over whose numbers are correct. 

If this sounds familiar, you’re not alone. The problem isn’t in the data. It’s in how it’s managed, modeled, and delivered across teams. Has inconsistent data become an accepted problem within your organization? It shouldn’t be. Inconsistent data is not normal, it’s not harmless, and it’s definitely not cheap.

To overcome this challenge, data leaders need a universal semantic layer for AI- and BI-ready data that unifies, governs, optimizes, and integrates delivery across every use case. In part one of The Confident Decisions Series, we’ll explore why organizations are making the universal semantic layer a foundational part of their modern data strategy and how Cube Cloud builds consistency and confidence into every decision.

## The Modern Data Stack Is Fragmented
Cloud data platforms like Snowflake, BigQuery, and Databricks have transformed the way data is stored and queried. While they provide scale and performance, they don’t address the bigger issues of how data is modeled, accessed, and interpreted across teams and tools. Here’s what often happens:

- Different teams define key metrics differently. For example, “active users” might include trial accounts in one team’s dashboard but not another’s.
- BI tools are siloed. Power BI, Tableau, Looker, and Excel have different modeling and calculation logic, creating inconsistent KPIs.
- Data modeling is repeated over and over. Every team rebuilds similar logic in their tool of choice, creating unnecessary complexity.
- Query performance varies wildly. Business users wait on dashboards, and engineers write custom SQL to get around bottlenecks.
- Data governance is patchy. Sensitive data is exposed or restricted inconsistently across tools, leading to compliance risks.

The end result? Confusion, wasted time, and decisions made on shaky ground.

## A Universal Semantic Layer Is the Single Source of Truth
A universal semantic layer sits between your data warehouse and the tools that consume data in AI, BI, spreadsheets, and embedded analytics. Think of it as the bridge that makes your data stack components actually work together. Cube Cloud’s universal semantic layer serves four core functions:

1. __Standardized Metrics Across Every Tool__: Cube Cloud centralizes business logic and KPI definitions in one place. Whether a user is in Power BI, Tableau, Excel, or an AI app, they’re accessing the same version of revenue, churn, or customer engagement, not a slightly tweaked copy. This eliminates metric drift and brings cross-functional alignment.

2. __Centralized Data Access Controls__: With role-based access controls and row-level security built in, Cube Cloud ensures sensitive data is only accessible to the right users. Data teams can define once and apply everywhere, simplifying compliance and reducing risk.

3. __Fast, Scalable Performance__: Cube Cloud accelerates analytics by intelligently caching queries, pre-aggregating data, and optimizing performance across large datasets. That means sub-second response times, even for complex dashboards or high-volume embedded analytics applications.

4. __Future-Ready Stack__: Cube Cloud is committed to interoperability, allowing you to integrate with your existing technology investments and adopt new platforms more easily. With an API-based approach, unified data models and governed metrics can be shared and reused across data consumers, making your data AI-and BI-ready.

## Make Confident, Aligned Data-Driven Decisions
When data is consistent, governed, and performant, everything changes:
- Executives trust the dashboards they see and can make faster, more informed decisions.
- Data teams reduce maintenance overhead, eliminating redundant connections, modeling, and tool-specific nuances.
- Analysts and business users can query data over a live connection in their tool of choice, including popular BI tools and spreadsheets, and start exploring data with confidence, instead of importing snapshots.
- Product teams build smarter applications that leverage real-time, governed analytics.

Most importantly, the entire organization operates from a single source of truth with the confidence to move quickly, strategically, and in sync.

## Turn Consistent Data into Your Competitive Edge
Cube Cloud is purpose-built to be the universal semantic layer for the modern data stack. It connects natively to your cloud data warehouse, exposes consistent data models via APIs, and integrates seamlessly with your AI, BI, spreadsheets, and embedded analytics.

With Cube Cloud, you can:
- Model data once, and deliver it anywhere.
- Govern centrally and simplify compliance.
- Optimize performance across tools, teams, and use cases.
- Accelerate insights with AI- and BI-ready, API-first architecture.

In the next post, we’ll dive into the “confidence gap”, covering the misalignment and hesitation that arises when teams can’t agree on the data. You’ll learn how to identify the gap in your organization and how Cube Cloud helps eliminate it with consistent, governed, and high-performance analytics. [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=exec%20blog1) to get started on rebuilding trust in data across your organization.


Consistent Data, Confident Decisions: Why a Universal Semantic Layer Is Essential


> The AI API has evolved into Cube D3, the trustworthy agentic analytics platform. Learn more about [Cube D3](https://cube.dev/product/cube-d3).

We're thrilled to announce a significant leap forward in our AI API capabilities, particularly for our valued users leveraging Snowflake. Last month, as part of the General Availability (GA) release of our powerful AI API, we proudly unveiled the "Bring Your Own Large Language Model" (BYOLLM) feature. This groundbreaking addition empowers organizations to seamlessly integrate their own compatible Large Language Models (LLMs) with our AI API, directly addressing critical concerns surrounding data security and cost optimization.

In today's data-driven landscape, organizations are increasingly seeking to leverage the immense potential of LLMs for various applications, from natural language processing to advanced analytics. However, with this increased adoption comes a heightened awareness of the need to protect sensitive data and manage costs effectively. This is where Cube's AI API with BYOLLM truly shines.

[Cube’s AI API](https://cube.dev/docs/product/apis-integrations/ai-api) allows Cube Cloud customers to use an LLM to interact with their data, via their trusted and governed universal semantic layer. Users can simply ask questions in natural language and the AI API will generate a Cube JSON Query to run or be run against our REST API, in order to answer their question. With BYOLLM an organization can choose to use a compatible LLM from their cloud provider and now from Snowflake the AI Data Cloud.

For organizations deeply invested in the robust Snowflake data cloud platform, maintaining LLM usage within the existing Snowflake security boundary and optimizing credit spend is of paramount importance. We recognize these priorities, which is why we're excited to highlight that you can now seamlessly utilize the cutting-edge Anthropic Claude 3.5+ Sonnet models offered on Snowflake Cortex directly with our AI API.

This powerful integration ensures that your highly sensitive data remains securely within your established Snowflake environment, where you have complete control over access and governance. At the same time, you can unlock the full potential of advanced AI capabilities, enabling you to derive deeper insights and drive innovation. Furthermore, this integration offers significant cost management benefits by consolidating your LLM usage within your existing Snowflake infrastructure and credit spend, eliminating the need for separate, potentially more expensive, AI services.

Getting started with this game-changing integration is remarkably straightforward. We've documented the process in our documentation, which you can access here. In essence, it simply involves enabling the BYOLLM feature on the AI API configuration page within Cube Cloud and securely saving your Snowflake Cortex credentials. This streamlined setup allows you to quickly and easily harness the power of Snowflake Cortex hosted LLMs with your Cube-powered applications.

We are acutely aware that a large and growing number of organizations are actively using open-source Cube or our fully managed Cube Cloud platform in conjunction with Snowflake. We deeply value this vibrant community and are particularly enthusiastic about collaborating with these organizations to facilitate their seamless adoption of the AI API using Snowflake Cortex hosted LLMs. We understand that each organization has unique needs and workflows, and we're committed to providing tailored support and guidance to ensure a smooth and successful integration.

We believe that the combination of Cube's AI API, BYOLLM, and Snowflake Cortex offers a powerful solution for organizations seeking to enhance their data security, optimize costs, and unlock the transformative potential of AI. By keeping your LLM usage within your Snowflake environment, you can maintain control over your data while leveraging cutting-edge AI models.

If you're interested in exploring this integration further and discovering how it can benefit your organization, please don't hesitate to reach out to us. Our team is readily available to answer your questions, provide technical guidance, and assist you in getting started. We are committed to helping you maximize the value of your Snowflake investment and unlock new possibilities with AI.

We're excited to embark on this journey with you and witness the innovative applications you'll build with Cube's AI API and Snowflake Cortex hosted LLMs. Let's work together to drive innovation, enhance security, and achieve new levels of efficiency. We look forward to hearing from you!


Bring your own Snowflake LLM


Over the last decade, enterprises have poured time, money, and headcount into data literacy programs. The goal was admirable: empower every employee to understand data, make informed decisions, and reduce over-reliance on central data teams. But reality painted a different picture. Most programs struggled to scale, failed to deliver measurable impact, or collapsed under the weight of misaligned tools, training, and expectations.

Now, AI is having its moment, only now there’s more urgency, higher stakes, and greater hype. Organizations are scrambling to deploy generative AI across every function, promising faster insights and better productivity. Beneath the surface, the same cracks are forming. AI may be more powerful than dashboards ever were, but it still relies on the same foundation of good data. Just like with BI, people using AI without understanding or trusting the data behind it are set up to fail.

If data literacy was about helping humans understand data, AI literacy is about helping humans understand the answers AI gives them. And if we’ve learned anything from the past, it’s that literacy can’t be taught in isolation. It must be built into the systems and workflows people already use.

## AI Literacy Starts with Trusted Data
AI literacy isn’t just about prompt engineering or understanding hallucinations. It’s about ensuring that every AI-generated answer is aligned with how your business defines success. It’s about making sure AI is pulling from the right sources, using the right terminology, and reflecting the right business logic. 

Without guardrails, even the best AI can confidently generate the wrong answer. This is where the universal semantic layer becomes essential. Cube Cloud sits between your data sources and your AI applications, providing a consistent, governed layer of business logic that AI can understand and apply. Just as it does for BI tools, spreadsheets, and embedded analytics, Cube ensures your AI is grounded in business context, not just raw data. Let’s break that down:

__1. Enrich Your Data with Business Context__

Raw data is rarely meaningful on its own. A column labeled rev_qtrly_adj might mean something to a data engineer but not to an AI model or a business stakeholder trying to interpret AI-generated output. This is where semantic modeling come in.

Cube Cloud lets teams define dimensions, metrics, relationships, and hierarchies in plain business terms. For example, instead of exposing a sales rep or an AI model to messy SQL logic and table joins, you define a metric like “Net Revenue” once, using the exact business logic your finance team approved. Then, any AI agent can query that metric through Cube, no interpretation or translation needed.

This semantic model becomes the shared language between your data, your AI, and your users. It transforms your data from a black box into understandable, usable knowledge. And most importantly, it eliminates the risk of AI making assumptions that don’t match your business logic.

__2. Generate Responses Aligned with Vocabulary and Intent__

Generative AI is only as useful as the quality of the prompts and the clarity of the data it interacts with. But in the real world, prompts are vague, messy, and inconsistent, just like human-to-human communication. A sales leader might ask, “What’s our top-line growth in APAC last quarter?” while a product manager asks, “Are signups trending up?” Without shared context, these prompts can lead AI to produce wildly different—or just plain wrong—answers.

Cube Cloud helps generative AI systems bridge the gap between intent and execution. By connecting AI tools to governed semantic models, Cube ensures that vague human language is translated into precise, context-aware queries. AI no longer has to guess what “top-line” means or how to filter “last quarter”. It uses the definitions, filters, and calculations your business already trusts.

With Cube, AI responses speak your business’s language—literally. Whether you’re using AI to build dashboards, write executive summaries, or answer ad hoc questions in natural language, every result aligns with how your business thinks and talks.

__3. Ensure Traceable, Auditable Outputs__

One of the biggest challenges in AI literacy is trust. Can you trust the answers AI gives? Where did the data come from? What logic was applied? Can you verify the numbers? Without transparency, AI becomes a black box that users either blindly follow or entirely ignore. Neither option is safe.

Cube Cloud makes AI output traceable by design. Every response generated via Cube is backed by governed, version-controlled models. You can trace the result from the data source to the exact metric definition and downstream data consumers. Need to know how AI calculated revenue growth? You can inspect the semantic model. Need to verify the filter applied for “APAC”? It’s documented and auditable.

This level of transparency doesn’t only boost trust; it makes AI literacy achievable. When users understand where answers come from and why they’re correct, they’re more likely to embrace AI as a reliable partner, not a risky shortcut.

## From AI Hype to AI Habit
The AI boom is a multi-year megatrend that shows no signs of slowing down. But for AI to truly transform how organizations work, it has to become part of daily decision-making. That means people have to trust it, understand it, and be confident using it. That’s what AI literacy is really about.

Just as we learned in the data literacy era, literacy is not about training alone. It’s about putting the right foundations in place, making understanding natural, usage easy, and governance automatic, bringing people, process, and technology together.

Cube Cloud is that foundation. By enriching your data with semantic context, aligning AI output with business intent, and ensuring every answer is traceable and governed, Cube makes AI literacy both possible and sustainable. AI doesn’t just need data access. It needs the right data, used the right way, understood by the right people.

## Build AI Literacy on a Trusted Foundation
If your organization has struggled with data literacy, you’re not alone. Now, you get a second chance. The rise of AI gives every business a new opportunity to get it right with tools that are built for scale, consistency, and context.

Cube Cloud brings structure to your AI initiatives by connecting them to the universal semantic layer your business trusts for consistent data and confident decisions. It’s not about more dashboards or better prompts. It’s about a universal understanding of your data, across every tool, team, and user. [Contact sales](https://cube.dev/contact) to learn more about how Cube Cloud can help you build AI literacy on a trusted foundation.


AI Literacy Is the New Data Literacy: Why a Semantic Layer Is the Missing Link


Migrating from a legacy OLAP platform like Microsoft SQL Server Analysis Services (SSAS) to a modern, cloud-native solution can seem like a daunting task. Organizations often worry about business continuity, compatibility, and ensuring a seamless transition for end users. However, with the right approach and the power of Cube Cloud’s universal semantic layer, businesses can migrate away from SSAS without disruption, while unlocking cost savings, scalability, and improved performance.

## Why Migrate from SSAS?
Before diving into how to migrate, it’s important to understand the key reasons businesses are moving away from SSAS:

- Cost Savings: Eliminate SSAS licensing and maintenance fees by consolidating data access in the cloud.
- Scalability: Modern cloud data platforms provide better performance and elasticity compared to on-premises OLAP systems.
- Unified Data Access: A single semantic layer can connect Excel, Power BI, other BI tools, and applications without silos.
- Future-Ready Stack: Cloud-native solutions support AI and advanced analytics that SSAS cannot.

## Step-by-Step Guide to Migrating from SSAS to Cube Cloud
### Step 1: Assess Your Current OLAP Environment
Start by evaluating your current SSAS deployment:
- Identify existing data models, KPIs, and reports.
- Assess Excel, Power BI, and other BI tool dependencies.
- Determine cloud readiness by reviewing your current data platform architecture.

Key Tip: Document the most frequently used queries and reports to prioritize their migration.

### Step 2: Plan Your Migration Strategy
Once you’ve assessed your environment, plan the transition with these considerations:
- Define phases for transitioning different workloads.
- Engage business users early to set expectations.
- Set up a test environment to validate results before full deployment.

Key Tip: Prioritize high-impact reports and dashboards for early migration to demonstrate quick wins.

### Step 3: Map Your SSAS Models to Cube Cloud
Cube Cloud’s flexible semantic modeling capabilities make it easy to transition from SSAS:
- Convert existing OLAP cubes to Cube’s universal semantic layer data models and metrics.
- Define measures, dimensions, and aggregations for optimal query performance.
- Apply data access controls to ensure consistent security across tools.

Key Tip: Leverage Cube’s caching capabilities to enhance performance during peak usage.

### Step 4: Validate and Optimize Performance
After migration, conduct thorough testing to compare results with SSAS:
- Validate data accuracy and consistency across reports.
- Optimize query performance using Cube Cloud’s built-in caching and optimization features.
- Train end-users to ensure a smooth adoption process.

Key Tip: Use A/B testing to compare query performance between SSAS and Cube Cloud.

### Step 5: Go Live and Monitor Adoption
Once validated, deploy Cube Cloud into production and actively monitor its adoption:
- Provide ongoing support for business users to address any transition challenges.
- Track performance metrics to ensure the new solution meets expectations.
- Collect feedback for continuous improvement.

Key Tip: Regularly communicate benefits to stakeholders to drive adoption and satisfaction.

## Benefits of Migrating to Cube Cloud
By migrating from SSAS to Cube Cloud, enterprise can realize:
- Cost savings by eliminating SSAS infrastructure and licensing.
- Faster query performance with intelligent caching and cloud-native scalability.
- Seamless Excel connectivity, allowing users to continue working in their preferred environment.
- Future-ready analytics, supporting AI and embedded applications.

## Conclusion
Migrating from SSAS doesn’t have to be complex or disruptive. With Cube Cloud, you can modernize your analytics stack while maintaining the familiar Power BI and Excel experiences and improving performance across your data ecosystem. Ready to start your migration journey? [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=ssas%20blog2) to schedule a free consultation today, and see how Cube Cloud can simplify your transition.

*Curious for more? [Register now](https://cube.registration.goldcast.io/webinar/5a8b7d50-6e20-4e64-9079-444987dfe52a?utm_source=cube&utm_medium=blog&utm_content=ssas-blog2) to join the fireside chat with the Cube executives.*


How to Ensure a Smooth Transition from SSAS to Cube Cloud


For decades, Microsoft SQL Server Analysis Services (SSAS) has been a cornerstone of enterprise Online Analytical Processing (OLAP), enabling businesses to perform complex multidimensional analysis and reporting. However, as organizations embrace cloud-first strategies and migrate to platforms like Snowflake, Databricks, Amazon Redshift, and Google BigQuery, SSAS struggles to keep up, becoming a roadblock to modernization.

In this blog, we’ll explore why SSAS no longer meets the needs of cloud-first organizations and how a modern universal semantic layer can bridge the gap between cloud data and business intelligence tools.

## The Challenges of SSAS in a Cloud-First World
Despite its legacy as a powerful OLAP solution, SSAS presents several challenges for organizations looking to modernize their data stack. SSAS lacks cloud-native scalability because it was designed for on-premises environments, making it difficult to scale with the elastic needs of cloud data platforms. Organizations relying on SSAS often struggle with performance bottlenecks and slow query response times, limiting their ability to analyze growing data volumes in real time.

Maintaining SSAS alongside cloud data platforms leads to increased infrastructure and licensing costs. Organizations often find themselves investing in both SSAS and cloud solutions, resulting in duplicate maintenance efforts and unnecessary expenses. Many companies continue to support SSAS solely to enable Excel workflows, adding complexity and creating data silos.

Users expect a seamless experience across BI tools and applications. SSAS, however, operates as an isolated OLAP engine that limits data accessibility across modern analytics platforms, creating inconsistencies in reporting and slowing down decision-making.

## Modernizing OLAP with Cube Cloud
Cube Cloud offers a modern, cloud-native alternative to SSAS, providing a universal semantic layer that enables organizations to transition to the cloud without losing key functionality with Excel and Power BI for multidimensional analysis.

With Cube Cloud, businesses can:
1. __Reduce Costs__: Eliminate SSAS licensing and infrastructure expenses by consolidating data access in a cloud-friendly architecture.
2. __Ensure Compatibility__: Provide native MDX and DAX support, enabling Excel and Power BI users to analyze live cloud data seamlessly.
3. __Unify and Govern Data Across Cloud Platforms__: Connect to Snowflake, Databricks, Redshift, and more while maintaining the universal semantic layer for all users and supporting tool preferences.
4. __Enhance Performance__: Leverage intelligent caching and query optimization to deliver faster insights.

## Conclusion
SSAS is no longer the best fit for businesses seeking agility, scalability, and cost-efficiency. Moving to Cube Cloud allows organizations to modernize their OLAP strategy and ensure seamless data access for all users, including both Excel and Power BI users. Ready to modernize your OLAP strategy? [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=ssas%20blog1) to explore how Cube can help you transition from SSAS.

Want to learn more? [Register now](https://cube.registration.goldcast.io/webinar/5a8b7d50-6e20-4e64-9079-444987dfe52a?utm_source=cube&utm_medium=blog&utm_content=ssas-blog1) for the fireside chat.


Why Microsoft SQL Server Analysis Services No Longer Meets the Needs of Cloud-First Organizations


For decades, Business Intelligence (BI) was hailed as the holy grail of data-driven decision-making. Companies invested heavily, pouring time, money, and talent into BI platforms, data warehouses, and analytics teams. The goal was simple: democratize data. Make it accessible so that everyone, from top executives to frontline employees, could make smarter, data-backed decisions.

But the reality is far less inspiring. Despite massive investments and technological leaps, BI adoption has stalled. Research shows that only 25-35% of employees actively use BI tools in their day-to-day work. Even in organizations that pride themselves on being data-driven, many employees still rely on outdated reports, gut feelings, or inconsistent spreadsheets to make critical decisions.

What went wrong? As companies now turn their eyes to Artificial Intelligence (AI) as the next big thing, there’s a risk of history repeating itself. If scaling BI was tough, scaling AI will be even harder because of its complexity, higher stakes, and stricter governance requirements. Let’s explore the lessons from BI’s struggles and why they should be a wake-up call for organizations looking to scale AI successfully.

## Lesson 1: Data Access Isn’t Enough—Context and Consistency Matter
BI promised self-service analytics with tools that allowed business users to explore data without constantly relying on IT or data teams. To some extent, it delivered. BI tools made data more accessible than ever before, but accessibility isn’t the real problem.

The deeper issue is a lack of context and consistency. Data in most organizations lives everywhere, from cloud data warehouses to SaaS apps and legacy systems. Each source has its own definitions, structures, and quirks. Sure, BI tools can connect to them, but they do not unify them. No common access point exists to ensure that everyone uses consistent, governed, and accurate data.

![](https://ucarecdn.com/b4fda624-f8f1-4021-9ff2-25c7ce78eeea/-/quality/smart/-/format/auto/)

Semantic definitions are fragmented. Different teams pull similar reports and end up with conflicting numbers, with each convinced they are right. Filters are applied differently. Joins don't match. Calculations vary. Trust becomes eroded, and once trust in data disappears, so does tool adoption.

With AI, this problem only intensifies. If AI accesses inconsistent or inaccurate data, the consequences can be catastrophic, such as flawed outputs and bad business decisions. Because AI often operates as a black box, these errors might not even be noticed until it’s too late.

The lesson here is simple but crucial: It’s not enough to make data accessible. Organizations need a trusted data foundation, built in a universal semantic layer to ensure consistent definitions, unified metrics, and the right context, whether it’s feeding a BI dashboard or used for AI outputs. 

## Lesson 2: Complexity Overwhelms Self-Service Initiatives
BI tools evolved to be more user-friendly over the years with drag-and-drop interfaces, sleek dashboards, and even natural language querying. But for many business users, all the bells and whistles still aren’t enough.

Data is just too complex: joining data from multiple tables, applying the right business logic, and building meaningful KPIs. These tasks often demand a level of technical know-how that most business users simply do not have. So, what happens next? They fall back on data teams, defeating the whole purpose of “self-service” BI.

![](https://ucarecdn.com/0f35fb28-0716-4e36-9e10-a05a16a82a40/-/quality/smart/-/format/auto/)

AI takes this complexity and cranks it up a notch. Successful AI models need more than proprietary data. They require cleaned, enriched, and transformed data that is engineered for the task at hand. Without a simplified, governed approach to managing this complexity, AI initiatives will end up like BI, bottlenecked, dependent on overburdened data teams, and inaccessible to the broader organization.

A universal semantic layer abstracts complexity, delivering clean, consistent, and context-rich data to both AI and BI. It frees data teams from endless wrangling and lets them focus on high-value tasks.

## Lesson 3: Trust Is Fragile—And AI Raises the Stakes
One of BI’s silent killers is a lack of trust. It starts small as a dashboard showing the wrong numbers or a report that pulls outdated data. But over time, these small inconsistencies chip away at user confidence. Eventually, users abandon BI tools altogether, opting for offline, ungoverned spreadsheets. Sound familiar?

Now, apply that same trust issue to AI and multiply the stakes. AI models aren’t just powering dashboards. They’re driving decisions in high-stakes areas like finance and healthcare. One flawed AI output can have real-world consequences. If stakeholders don’t trust that AI is using accurate, unbiased data, they won’t use it.

![](https://ucarecdn.com/daefe8e4-ccc2-4c24-8498-9614401462d5/-/quality/smart/-/format/auto/)

Explainability adds another layer to this challenge. In BI, you can usually trace how a dashboard was built or how a metric was calculated. But with AI, it’s often a black box. Understanding why the model generated a specific response can be difficult to untangle. 

Building trust in AI requires a multi-pronged approach:
- Consistent, high-quality data throughout the AI pipeline.
- Robust governance and monitoring to detect data drift, bias, or anomalies.
- Explainability tools that demystify complex models and help users understand the “why” behind AI-driven decisions.

Just like BI, AI will fail to gain meaningful adoption without trust. A universal semantic layer makes proprietary data AI-ready so that it can deliver trustworthy outputs across a wide range of requests.

## Lesson 4: People and Processes Lag Behind Technology
Here’s a truth many organizations learn the hard way: Technology alone doesn’t solve problems.

Plenty of BI failures can be traced back to this flawed thinking when companies invest heavily in tools but neglect the people and processes needed to make them successful. They didn’t train users properly or establish governance frameworks to foster a data-driven culture. As a result, tools sit unused. Data stays siloed. Gut feelings drive decisions, instead of facts.

![](https://ucarecdn.com/fd6d0be3-0664-4b60-9a1c-91d300a4a2ac/-/quality/smart/-/format/auto/)

Scaling AI requires even more attention to people and processes. AI initiatives demand cross-functional collaboration. Data scientists, engineers, domain experts, and business stakeholders must work together to prepare data, train models, validate results, deploy solutions, and continuously monitor quality and performance.

Organizations that neglect the people and processes behind BI will find themselves in even deeper trouble when trying to scale AI. The fix is a holistic approach that balances technology investments with the right people, training, and governance structures operationalized within a universal semantic layer.

## Lesson 5: Speed Without Strategy Leads to Waste
In the rush to become data-driven, many companies adopted BI tools without a clear strategy. The results were messy with duplicated dashboards, conflicting metrics, fragmented implementations, and wasted resources.

The same risk looms with AI, only bigger. AI projects often start as pilots or experiments. But without a clear roadmap, they can spiral into disjointed initiatives that don’t align with business goals. Most organizations are struggling to move from AI experimentation to execution. Siloed models, inconsistent data pipelines, and a lack of governance lead to wasted time and money.

![](https://ucarecdn.com/e5fc5df7-1255-4802-9afa-b242e4e45d93/-/quality/smart/-/format/auto/)

To avoid this pitfall, organizations need a strategic approach to AI adoption:
- Align AI initiatives with business objectives and KPIs.
- Establish a trusted data foundation to ensure consistency.
- Implement strong governance for data, models, and outputs.
- Foster collaboration between technical and business teams to bridge gaps.

A more pragmatic approach ensures that AI isn’t just another shiny tool. AI should be a driver of real business value, and at the center of these initiatives should be a universal semantic layer.

## The Path Forward: Build a Strong Data Foundation for AI Success
Although BI’s struggles have taught us some tough lessons, they provide us a roadmap for scaling AI the right way. Consistent, governed, and accessible data is non-negotiable for any successful data initiative, whether it’s AI or BI. The key to achieving  success is a universal semantic layer.

By unifying data from multiple sources, standardizing business logic, and providing governed access to both AI and BI, a universal semantic layer creates a trusted data foundation. It ensures that everyone, humans and machines alike, works from the same consistent, reliable information.

As AI adoption accelerates, organizations will need to ask themselves: Are we building on solid ground? Or are we about to repeat the mistakes of BI? Because if scaling BI was hard, scaling AI will be even harder, unless you get the data right. 

By solving for key barriers for scaling AI initiatives, you can avoid repeating the struggles of scaling BI initiatives, all from one trusted place. Consequently, you can also improve BI adoption across the organization with unified data. With a universal semantic layer, models and metrics can be reused across AI, BI, spreadsheets, and embedded analytics solutions. [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=post-gartner%20blog) to learn more about how Cube Cloud can help advance your AI and BI initiatives.


The Harsh Lessons of Modern BI and Why Scaling AI Will Be Even Harder


This year’s Gartner Data and Analytics Conference in Orlando delivered a powerful message: in today’s fast-paced AI landscape, enterprises must balance speed with governance, embracing a modular, open, and collaborative approach to data management. The Cube team returned with rich insights that resonate deeply with our mission to provide a universal semantic layer that unifies, democratizes, and secures data across organizations.

## Trustworthy Data and Robust Governance
A recurring theme at the keynote was the need for trustworthy data. In an era where data fuels AI journeys, establishing robust trust models and governance frameworks is more critical than ever. The session highlighted how contextualizing data through semantic layers not only enhances data trustworthiness but also drives consistency across analytics tools and AI agents.

At Cube, our universal semantic layer is designed with these exact challenges in mind. By serving as a single source of truth for [models and metrics](https://cube.dev/product/data-modeling), our solution empowers enterprises to set up robust governance while ensuring that data is both accessible and reliable. This alignment allows organizations to implement “guardrails” that enable innovation and experimentation—providing the freedom to fail safely and learn quickly.

## Balancing Governance with Speed
One of the standout messages from Gartner was the idea of “going slower to go faster.” In other words, investing time in solid data governance can accelerate long-term innovation. Enterprises are encouraged to build trust through carefully managed semantic layers, which ultimately speeds up decision-making and AI deployments. 

Cube’s approach reflects this philosophy. By moving [data access controls and policies](https://cube.dev/product/data-access-control) upstream into the universal semantic layer, we help companies achieve the delicate balance between control and agility, ensuring that even in a rapidly changing AI environment, every data-driven decision is backed by well-governed, high-quality data.

## Embracing Variety and Modularity in AI Platforms
The keynote also emphasized the value of variety in AI platforms—supporting a best-of-breed approach to rapidly evolving technology landscapes. In an environment that demands modular and open architectures, reusability becomes a significant competitive advantage. Data products, active metadata, and collaboration between IT, data analysts, and AI agents are not just buzzwords—they are essential building blocks for next-generation data platforms.

Cube’s universal semantic layer is inherently modular and designed for reuse. By enabling seamless integration across disparate systems and tools with [Data APIs](https://cube.dev/product/data-apis), our software supports a variety of use cases from data ops to fin ops, ensuring that all teams—from IT to business analysts—work with consistent, governed data. This flexibility is especially critical in a world where the CDAO role is evolving to meet the demands of AI, and cross-functional collaboration is key to unlocking the highest ROI on AI investments.

## Overcoming Cultural Roadblocks and Driving Collaboration
Despite all the technological advancements, a lack of data culture remains the number one roadblock for many organizations. The conference underscored the urgent need for leaders to foster an environment where data is seen as a collaborative asset. As companies invest AI dollars in platforms that democratize data access, the transformation of roles like the CDAO is both inevitable and necessary.

Cube is committed to helping organizations overcome these cultural hurdles. Our universal semantic layer not only standardizes data across the enterprise but also bridges the gap between data engineering and analytics teams. By allowing them to choose between code and [visual modeling](https://cube.dev/blog/announcing-visual-model-editor-in-cube-cloud), Cube Cloud provides a shared workspace for trusted data. This collaboration is crucial for creating an environment where data is not siloed but is a shared resource driving innovation and operational excellence. 

## Looking Ahead
The insights from Gartner’s keynote offer a clear roadmap for the future of data and analytics: invest in trustworthy data, balance governance with agility, and leverage modular, open architectures to drive AI success. At Cube, we’re proud to be part of this transformative journey, providing a universal semantic layer that underpins these best practices and empowers enterprises to harness the full potential of their data.

As we move forward, our commitment remains steadfast—to help organizations navigate the complexities of the modern data landscape with confidence, ensuring that every data initiative is both robust and agile enough to meet the challenges of tomorrow. [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=gartner%20bickell%20blog) to learn more about how Cube Cloud can advance your AI and BI initiatives with trusted data.


Gartner Data and Analytics Conference 2025: Building Trust and Agility in the AI Era


Data modeling is an essential part of building the semantic layer. We know that it isn't just for developers and data engineers; data analysts and business users are also involved in data model evolution.

At Cube, we've championed a code-first approach to building powerful data models. However, we recognize that not everyone works in code, and there's a need for a no-code, visual way to define the data model.

__Today, we’re excited to introduce Visual Model__, a no-code data modeling experience in Cube Cloud. Now generally available, Visual Model enables non-technical users to participate in data modeling without writing a single line of code. It also complements the code-first approach and helps code-savvy users save time with a convenient UI.

## Canvas for cubes and views

A few months ago, we [introduced](https://cube.dev/blog/introducing-cube-visual-modeler-empowering-everyone-to-build-with-data) Visual Model in preview, and have iterated on it ever since, refining the UI and adding support for recent data modeling features such as [hierarchies and folders](https://cube.dev/blog/introducing-hierarchies-and-folders-support).

See how Visual Model looks now:

![](https://ucarecdn.com/70896bfe-b7c5-42d4-a7b0-194d7872d34c/)

You can learn more about Visual Model features in the [documentation](https://cube.dev/docs/product/workspace/visual-model#data-graph).

## What’s next?

Visual Model is now generally available to all Cube Cloud customers on [Premium and above](https://cube.dev/pricing) tiers. If you’re ready to transform how your team collaborates on data modeling, start using Visual Model [today in Cube Cloud](https://cubecloud.dev/auth/signup), or [get in touch](https://cube.dev/contact) with us to learn more.


Andrew Yamanov

Announcing Visual Model editor in Cube Cloud


> The AI API has evolved into Cube D3, the trustworthy agentic analytics platform. Learn more about [Cube D3](https://cube.dev/product/cube-d3).

### New pricing for the AI API

The cost per token of using LLMs has fallen substantially since we initially launched the AI API. Our initial pricing of one request per CCU was necessary at the time, but now with much more efficient models like Claude 3.5 Sonnet and GPT-4o available, we can offer a much lower price of 5 requests per CCU.

As of December 2024, the AI API is available for all paying Cube Cloud customers, including those on starter plans. You do not need to reach out to your AE or intercom to get it enabled; it is already enabled.

Here is a link to our AI API docs on how to use it: [https://cube.dev/docs/product/apis-integrations/ai-api]

The AI API needs to be enabled in your deployment in order to use it. Toggle to enable in your configuration flags:

![](https://ucarecdn.com/fe4b7a81-09b2-4894-946b-6faec35b980d/)

## Cube's AI API with Value Search
Cube's AI API is already a powerful way to allow users to access your data with AI quickly, safely, and transparently. We've heard from customers that users often refer to values inside of a dimension instead of stating where the dimension equals a specific value. This usually means the request won't be successful, and the user won't get the data they're looking for.

We have released a feature called Value Search for use with the AI API, which addresses this problem. Value Search allows Cube Cloud customers to select specific dimensions to be indexed so their values can be referenced by a query. Our RAG system can then use relevant values to answer questions that contain these dimension values or similar terms. It will include the pair of the dimension name and the value to filter the dimension.

Here is an example of how you can make a dimension searchable in your Cube data model YAML:
```yaml
- name: order_status  
  sql: order_status  
  type: string  
  meta:  
    ai:  
      searchable: true 
```

Here is our documentation related to the feature: [https://cube.dev/docs/product/apis-integrations/ai-api#value-search](https://cube.dev/docs/product/apis-integrations/ai-api)

## BYOLLM
Committed Cube Cloud customers can now choose to bring their own LLM to use with the AI API and incur costs this way instead of paying one Cube Cloud CCU per 5 requests. The AI API is compatible with Claude 3.5 Sonnet, available from AWS Bedrock, GCP Vertex, Snowflake, and Anthropic, OR GPT4o, available from OpenAI or Microsoft Azure. This enables almost anyone to use the AI API with their own LLM, whether for cost, security, or both.

Here are [instructions](https://cube.dev/docs/product/apis-integrations/ai-api#other-llm-providers) on how you can change the LLM provider for AI API use.

![](https://ucarecdn.com/4e143148-8c55-44d3-afb7-7dc7af214d7c/)

We are also offering free workshops for customers looking to put AI API into production until the end of April.

## Launching new Slack app for Cube AI API
Many of our customers have requested this feature since we launched the AI API. They expressed interest in enabling their stakeholders to interact with their Cube semantic layer through Slack using AI, similar to our AI API. The AI API ensures that questions are answered rapidly, safely, and transparently.

![](https://ucarecdn.com/2ffadc11-9ba0-4a9c-9b7b-0de4a44de9ed/)

You can install the Cube AI API Slack application easily in the settings page for AI API:

![](https://ucarecdn.com/9070ccb3-3fa9-4e04-aa38-8c4474250bb4/)

Once installed, the Slack app will introduce itself to your workspace individually, starting a conversation with each user. Users can then direct message the application with their data questions, which will be turned into threads where follow-up questions can be asked and feedback can be given. You can choose to receive a log of all questions asked and answered in a separate private channel for your engineering team to observe and learn from.

Want to learn more? [Contact our sales team](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=2025%20api%20updates) today.


Make your AI Smarter - turbocharging Cube's AI API with value search; + BYOLLM and Slack app


Organizations rely on data to drive decisions, but the challenge lies in how that data is structured. Transactional systems are optimized for speed and reliability, not for analytics. This creates a fundamental disconnect: Raw operational data is too complex and slow for reporting, while traditional dimensional modeling approaches, like Kimball’s Star Schema, require extensive ETL and rigid data transformations. Let’s look at a practical example: 

In Online Transaction Processing (OLTP) systems, every order, every support call, every interaction, needs to be quickly and efficiently captured and stored. Think of an ATM withdrawal. Instantly, when you withdraw cash from the ATM, that transaction is updated in all connected financial systems, your updated balance, the amount withdrawn, any ATM fees, and the transaction’s timestamp.

In Online Analytics Processing (OLAP) systems, data is analyzed in aggregate to identify trends and spot outliers to make more informed business decisions. Revisiting our ATM example, which ATMs get used the most, when they are used, do any of them run out of funds, and which ones generate higher fees.

In today’s cloud-native data and analytics ecosystem, data teams need a more flexible approach. Cube Cloud’s universal semantic layer is next-generation OLAP, bridging the gap and delivering the benefits of dimensional modeling without depending on legacy OLAP platforms. 

## Handling Transactional Data
Transactional data is stored in Online Transaction Processing systems __(OLTP) systems__. 

OLTP database architecture prioritizes data write operations. It’s optimized for write-heavy workloads and can update high-frequency, high-volume transactional data without compromising data integrity.

![](https://ucarecdn.com/235e18a5-fdd5-492f-9ab5-e73851885f05/)

OLTP systems use a Third Normal Form (3NF) data schema. This schema is very efficient for capturing data, but the retrieval of data from these schemas, for analytical use, is very difficult. Imagine trying to write a query against the schema above. And it’s not just complexity that hinders analysis of OLTP data.

When trying to report directly against OLTP systems you run into several problems:
- Query performance is very poor
- There is extreme potential for reporting activities to affect the source application’s performance
- A single complex query can shut down an ERP system by consuming all the database server’s hardware resources

The first solution was to replicate the OLTP data.  That made sure your queries didn’t crash the operational system, but didn’t really help with the other issues.

## Supporting Analytical Requirements
To support the analytical requirements of data, the data is transformed into a schema more conducive to data retrieval with Online Analytics Processing (__OLAP__). OLAP database architecture prioritizes data read over data write operations. You can quickly and efficiently perform complex queries on large volumes of data.  This introduces a very important concept: Your data architecture choices directly affect the user experience.

Ralph Kimball, often called “The Father of the Dimension Model,”  introduced the concept of dimensional modeling, as a recommended way of transforming 3NF, OLTP data schemas, into consumable dimensional schemas for OLAP.

This transformation process requires an ETL (Extract Transform and Load) data pipeline process to move the data from the source OLTP schema, transform it and load it into the desired dimensional model.  This process is often referred to as denormalization (referencing the ‘normal’ from 3NF) or flattening. The model Kimball suggested is called a Star Schema:

![](https://ucarecdn.com/eebf2717-445e-4c54-92bf-5168ea8a7bd0/)

The complexity of the 3NF schema is converted into central fact tables and surrounding dimension tables. Just looking at the star, you can see how much easier it would be to query this schema for an analytical use case. The dimensions are conformed, meaning they will work with all of your fact tables.

To manage and plan the design of these OLAP dimensional models Kimball created a Bus Matrix to standardize development:

### Bus Matrix – Kimball’s Modeling Standard
![](https://ucarecdn.com/452271a9-530b-4487-a550-4a84e10c6fc4/)

The common belief is that the Kimball approach provides faster ROI, as data warehouses can be built incrementally, one Business Process at a time (the left axis).  The conformed dimensions (the top axis) would be built as needed and would join to the business process (Fact), where appropriate. Some of his key concepts include:

- Dimensionally Modeled DW
- Conformed Dimensions
- Data Warehouse by Business Process Iteration 
- Star Schema 
- Dimensional Denormalization (Flattening) 
- Surrogate Keys
- Easy Drill-Across (by Business Process)

## What is the right choice for your organization?
Before launching a dimensional modeling effort, your team needs to assess business needs, as well as the realities of the underlying source data. Not all use cases are the same. The four key decisions made during the design of a Kimball dimensional model include:
- Select the business process.
- Declare the grain.
- Identify the dimensions.
- Identify the facts. 

*[Courtesy of the Kimball Group](https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/grain/)*

Declaring the grain is the pivotal step in a dimensional design. The grain establishes exactly what a single fact table row represents. The grain declaration becomes a binding contract on the design. The grain must be declared before choosing dimensions or facts because every candidate dimension or fact must be consistent with the grain. This consistency enforces a uniformity on all dimensional designs that is critical to BI application performance and ease of use. 

Atomic grain refers to the lowest level at which data is captured by a given business process. We strongly encourage you to start by focusing on atomic-grained data because it withstands the assault of unpredictable user queries; rolled-up summary grains are important for performance tuning, but they pre-suppose the business’s common questions. Each proposed fact table grain results in a separate physical table; different grains must not be mixed in the same fact table. This data model approach provides several OLAP advantages.

- __Extensibility__: Dimensional models are resilient when data relationships change. Facts, dimensions, attributes and grain can be changed without altering any existing BI query or application, and without any change in query results.
- __Ease of use__: The simplicity of the schema makes it easier to query and involves fewer joins. Making it easier for developers and analysts to consume data from this model.
- __Performance__: The reduction of joins, and the use of surrogate keys, means this model provides much better query performance than an OLTP schema.
- __Shorter development timelines__: Because you can build incrementally, one business process (Finance, HR, Marketing, etc.), Kimball models are focused and can be built faster.

## Why doesn’t everyone use star schemas?  
Many organizations have taken other approaches to modeling their data. The benefits of a proper star schema model are likely worth the effort, but those benefits must be balanced against the cost and time it takes to build them. There are several drawbacks to using star schemas:

1. We are duplicating data.  OLTP systems eschew duplicating data, they are designed for quick and efficient capture and storage.  The Kimball approach does require creating copies of your data, in order to build those useful star schemas.
2. This process of transforming the data into a star, the ETL mentioned earlier, takes time, and technology. To build a proper star for just one business process could take weeks, and does require constant processing to keep loading the new records.
3. Building a proper star schema takes some expertise. Improperly built  Kimball models can lose some of the advantages mentioned above, and could produce incorrect results.

## How can Cube’s universal semantic layer help?
This is where a semantic layer can facilitate the shorter term requirements…”I need data now so I can run the business”, versus the longer term worry of… “If I keep taking short cuts with my data model, eventually it is going to start breaking down and produce inaccurate results or intolerable query performance.  Then I am going to have to throw it away and start all over’. 

Kimball star schemas provide an excellent base for Cube Cloud’s universal semantic layer. In addition, Cube can also sit on top of 3NF, or other non-OLAP data schemas. Cube logically maps the source data and presents the end use with an easy-to-understand interface to the data.  While this mapping exercise may take some time, we can provide useful access to data much more quickly because we don’t actually transform and physically move the data via an ETL process . Creating a logical star schema.

Which means we can meet the short term need and deliver quick access to data so we can analyze the business. We can also leverage Cube’s pre-aggregation capabilities to address performance and scalability.

If your strategy does mandate a data transformation process, like Kimball, Cube can ease the transition over time. Giving short term access with a logical model, and then as your data team rolls out proper Kimball stars, you simply repoint the Cube semantic layer to the new star.  No downstream analysts are negatively affected and the organization is on a sustainable long term data roadmap/strategy.

## The Future of Dimensional Modeling with Cube
Dimensional modeling has long been the foundation of analytical data architectures, but traditional approaches come with trade-offs—slow ETL pipelines, rigid transformations, and high maintenance costs. In today’s cloud-native, AI-driven world, businesses need agility. Cube’s universal semantic layer is next-generation OLAP, providing a modern alternative that enables organizations to map data logically, accelerate queries with pre-aggregations, and unify data access across OLTP and OLAP sources.

Whether your team is transitioning from legacy OLAP systems, optimizing a Kimball-style data warehouse, or working with real-time transactional data, Cube ensures a seamless and scalable analytics experience—without requiring extensive data movement or transformation. Instead of forcing your organization into a rigid model, Cube empowers you to deliver governed, high-performance data access—now and in the future.

Ready to modernize your approach to dimensional modeling? [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=dimentional%20modeling%20blog) to learn how Cube can help your team unify, govern, and optimize your data today.


John Korcak

Transactional Databases (OLTP)

Dimensional Modeling Design: Why Does It Matter?


This year, [Gartner’s Data & Analytics Summit](https://www.gartner.com/en/conferences/na/data-analytics-us) is focused on a pivotal theme: “From Inspiring Exploration to Leading Execution.” As AI, data, and analytics strategies continue to evolve, enterprise data leaders must move beyond experimentation to operational excellence, balancing opportunity and risk while delivering tangible value to their organizations.

At Cube, we understand that AI-readiness isn’t only about cutting-edge models and on-demand insights; it’s about having the right data foundation to drive meaningful organizational impact. Cube’s universal semantic layer unifies, governs, optimizes, and integrates enterprise data for both AI and analytics, ensuring a smooth transition from exploration to execution with reusable data models and metrics across all data consumers.

### Aligning AI, Data, and Analytics Strategies with Business Goals
Data leaders are well-aware of the challenges of adopting and scaling BI across their organizations. Now, they face increasing pressure to turn AI potential into business value, ensuring alignment with strategic goals while managing stakeholder expectations. However, many enterprises struggle to bridge the gap between strategy and execution, often hindered by siloed, inconsistent data across their organization. 

With Cube Cloud, data leaders can confidently drive AI adoption while maintaining alignment with organizational goals and delivering measurable business impact. Cube’s universal semantic layer unifies siloed data and ensures business users, analysts, and AI applications work from a single source of truth. As a result, your data teams will realize faster time-to-value, and every level of the organization will have access to consistent, governed data for informed decision-making.

### Making Data AI-Ready for Your Organization
Enterprises are quickly learning that most AI initiatives fail to scale due to data readiness issues rather than AI model limitations, as many struggle to shift from testing to production. Context is key to AI success. Without structured, contextualized, and governed data, AI outputs are prone to inaccuracies, bias, and operational inefficiencies. 

Cube Cloud ensures your AI initiatives can move beyond proof-of-concept and scale confidently across the enterprise, providing reliable and trustworthy results. With AI-ready data, you can ensure AI can interpret and act on business data accurately. Data can be aggregated and optimized for real-time AI inference, improving efficiency and reducing operational costs. With Cube’s commitment to interoperability, integration with AI frameworks and other platforms powers AI-driven analytics and automation.

### Delivering Trusted Insights Across the Enterprise
Enterprises must navigate an increasingly complex AI and analytics landscape, ensuring data is not only available but also accurate, consistent, and actionable. You must be able to share and reuse the same data models and metrics across data consumers. Without a unified semantic layer, inconsistent metrics and siloed data sources lead to unreliable AI outputs. 

Cube empowers enterprises to deliver trusted insights at scale, driving informed decision-making across all business functions. Cube Cloud provides centralized metrics management, which allows you to define KPIs once and ensure consistency across data consumers. Additionally, API-driven data access delivers data to any application, from cutting-edge AI to modern OLAP in spreadsheets. Finally, broad integration capabilities enable seamless analytics experiences across platforms like Power BI, Tableau, and custom embedded analytics applications.

### Unifying and Optimizing Enterprise Data
Effective data management is critical for scaling analytics and AI initiatives. However, enterprises often grapple with fragmented data definitions and performance issues across multiple cloud data platforms and data consumers. These discrepancies shift attention away from improving metrics and outcomes to explaining how the metric was calculated, while slow query responses degrade user experience.

Cube Cloud acts as the bridge that connects raw cloud data to meaningful business insights that accelerate data-driven innovation. Cube Cloud consolidates fragmented data definitions into a centralized, governed layer accessible by all data consumers. It also implements intelligent caching and pre-aggregation strategies to enhance query performance and reduce cloud costs. Cube Cloud empowers data teams with simplified access to governed, fast, AI-ready data.

### Ensuring Security, Governance, and Compliance
As enterprises scale their AI and analytics efforts, ensuring data governance, security, and compliance is a top priority. Inconsistent governance policies can lead to regulatory risks, data breaches, and reduced trust in AI-driven decisions, which is not easily recovered once it is lost. 

Cube provides enterprises with the flexible governance they need to scale AI and analytics with confidence and compliance. Using robust security controls, Cube Cloud implements role-based data access policies, user-dependent query rewrites, and data masking to ensure sensitive data is protected. For auditability and compliance, it provides automated data lineage from source to consumer. Cube Cloud enforces governance rules to ensure every AI and BI tool accesses the same, trusted data.

### Meet Cube at Gartner’s Data & Analytics Summit
As enterprises transition from AI exploration to execution, Cube Cloud stands ready to deliver unified, governed, AI-ready data. By solving for key barriers for scaling AI initiatives, you can also solve for the key barriers for scaling BI initiatives too, all from one trusted place.

Let Cube help you turn your AI, data, and analytics strategies into tangible business outcomes. See you at the Gartner Data & Analytics Summit!

- Visit Booth #931 to take the “Is Your Data AI-Ready?” assessment.
- Attend our theater session: "Cube: Scaling AI with a Universal Semantic Layer" [public link](https://www.gartner.com/en/conferences/na/data-analytics-us/sessions/detail/3859199-Cube-AI-Teammates-for-Data-Analytics-Teams) | [app link](https://nav.gartner.com/#/en/navigator/BI23/whoshere/exhibitors/3859199/sessiondetail/speakers-tab?profilematch=false&sortedby=exhibitorname) on Wednesday, March 5, 2025 at 1:05pm in Theater 3.
- Learn more at [Cube's Gartner Data & Analytics Summit Hub](https://learn.cube.dev/gartner-2025).


Go From AI Exploration to Execution with Cube Cloud


The primary role of a semantic layer is to present a dimensional view of a physical data model. A dimensional view is important because efficient consumption of data is at odds with efficient storage of data. Users consume data by domain, querying dimensions and metrics related to an invoice or user. Databases store data for a single domain across multiple tables to reduce the redundancy of updates and storage. Cube’s universal semantic layer bridges the gap between the logical model desired by consumers and the physical model imposed by the database.

Humans think about security from a domain perspective. If you have access to a system then it should follow that you have access to the minimum constituent pieces required to make the system function. Your car key provides access to the inside of your vehicle and grants you permission to start the engine. You don't need separate keys to the door, starter solenoid, and battery. Your bank card gives you access to your bank account. You don't need separate access to all of the infrastructure the payment system runs on. 

If the goal of a semantic layer is to reduce the complexity of consuming data shouldn’t it also reduce the complexity of securing data?

## Security Sprawl
Every new consumption point added to your data platform presents a new risk. How does it handle authentication and authorization, row-level security, column-masking, and caching? If you are using multiple BI tools without a universal semantic layer you likely have most of this security model built into your data warehouse. However, this approach has gaps:

__Q:__ How do you manage security for applications that utilize REST or GraphQL to fetch data? Do you have a plan to constrain access to data accessed by AI?

__A:__ One of the primary benefits of Cube Cloud’s data model is that it is built once and can be accessed by many different APIs. A security model built in Cube will apply to all downstream consumers.

__Q:__ If your security is handled in the data warehouse then how do you secure data extracted by BI tools? Do you have a separate security model for users accessing SSAS cubes from Excel?

__A:__ Cube’s pre-aggregations provide extract speeds and are governed by the same security model as the queries federated to your warehouse.

Cube’s universal semantic layer eliminates model chaos by centralizing your model. It can also eliminate duplicated security models that can cause leaks if they aren’t updated properly. Additionally, Cube’s code-first approach enables security models to be version controlled and approved via PR.

## How Security Works in Cube
Cube can integrate with external authentication and authorization systems using our [data access policies](https://cube.dev/blog/introducing-data-access-policies-in-cube-cloud) and or the [check_sql_auth](https://cube.dev/docs/reference/configuration/config#check_sql_auth) function.

![](https://ucarecdn.com/0f21ae52-3c42-4025-998d-2e2e8a53b6c1/-/quality/smart/-/format/auto/)

1. Consumer passes a query plus username or username and password to Cube’s SQL API
2. Cube [authenticates](https://cube.dev/docs/product/apis-integrations/sql-api/security) the user using an external service
3. Cube receives the user properties (such as role) required for authorization
4. Cube transpiles and [rewrites the query](https://cube.dev/docs/reference/configuration/config#query_rewrite) (for RLS and masking) according to the user properties received in step three
5. Cube [authenticates with the database](https://cube.dev/docs/reference/configuration/config#driver_factory) according to the user properties received in step three and queries the database with the query rewritten in step four
6. The database returns the data to Cube
7. Cube returns the data to the consumer

## Advantages of Building Security in Cube
### User-Centric Controls
In Cube, [Views](https://cube.dev/docs/product/data-modeling/concepts#views) are the endpoints presented to consumers. Views contain all of the semantics – metrics and conforming dimensions – relevant to a specific domain such as customer, invoice, or product. Views represent the final culmination of the logical model and often rely on a web of connections to underlying tables based on the physical model; the value of a semantic layer is to obfuscate the complex joins and business logic required to make sense of the data.

Consumers (users or applications) should have access to the views necessary to perform their role. Consumers don’t need access to individual tables in your database or even access to your database at all.

![](https://ucarecdn.com/ad3a6829-6804-4f92-aece-ec7b05d12489/-/quality/smart/-/format/auto/)

Each consumer role can be represented by a role, service principal, or service account that has access to the necessary physical objects in your database. The [driver_factory](https://cube.dev/docs/reference/configuration/config#driver_factory) function can be used to map a consumer to a specific set of authorizations in the database.

Column-based access, mandatory filters, and row-level security can also be [configured](https://cube.dev/docs/guides/recipes/access-control/column-based-access).

### Logging
Cube provides [logs, metrics](https://cube.dev/docs/product/workspace/monitoring), and [auditing](https://cube.dev/docs/product/workspace/audit-log) to ensure monitoring and alerting for security events. Additionally, you can use the [object representation of a query](https://cube.dev/docs/product/apis-integrations/rest-api/query-format) plus custom logging in [cube.py or cube.js](https://cube.dev/docs/reference/configuration/config) to track column-level access by individual users and more.

### Governance and Adaptability
A semantic layer is a representation of the physical layer with semantics applied. Providing access at this level of abstraction prevents consumers (or bad actors) from accessing the physical layer where sensitive data is stored and denies any possibility of CRUD actions being performed on the source of truth.

Building security in the semantic layer enables access to data derived from sensitive data such as masked data or access at specified levels of granularity.

The code-first approach in Cube means all updates in security must undergo a [PR approval](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) before being deployed into your production environment.

### Security for Extracted Data
Most BI tools have some extraction capabilities that analytics teams rely upon for speed and that data teams rely upon to reduce the load on their data warehouse: Tableau data extracts, PowerBI import mode, Metabase caching, etc. Once data is extracted from a database all security measures applied at the database level are useless.

Cube provides [pre-aggregations](https://cube.dev/docs/product/caching/using-pre-aggregations) as an improvement in speed, cost, and security of data extracted into individual BI systems.

When security is built into the semantic layer instead of the database, the Cube universal semantic layer can secure extracted data with the same rules that apply to data queried from your database.

## Rethinking Security with Semantics
The Cube universal semantic layer provides security by separating access to semantics for consumers from the physical layer of data, protection for extracted data without compromising performance, and organizing security in a logical way that matches user expectations.

The semantic sprawl, the repetition and lack of governance of business logic between tools, that leads to model chaos is caused by a plurality of analytic access points to your database; Cube is the solution for this problem.

Cube can also help secure and monitor data access across all consumers.


Michael Treadwell

A Logical Approach to Securing Data


Few companies have had the impact on analytics as a field that Microsoft has had. Microsoft Excel is by all measures the most successful, and enduring analytics tool of all-time. While Excel wasn’t the *first* spreadsheet software, it has become synonymous with the concept of spreadsheets and is by far and away the most recognizable spreadsheet software. At this point, much like SQL, it seems like spreadsheets are going to be with us forever. I’m ok with that. I love a good spreadsheet.

However, there’s another Microsoft analytics technology that in the preceding decade has quietly captured an enormous amount of the business intelligence market. I’m talking, of course, about Power BI. The overwhelming distribution power of Microsoft, via Office 365 and other bundling and packaging channels has made both Excel, and now, Power BI ubiquitous analytics tools. There’s also some technical lineage between the two tools to unpack with Excel using the multidimensional expression language (MDX) primarily to communicate with OLAP technologies like SQL Server Analysis Services (SSAS), or more modern variants such as Azure Analysis Services and Power BI building on this with the more recent Data Analysis Expressions (DAX) language.

Today it’s my pleasure to introduce two exciting new Cube Cloud features: our Cube Cloud for Excel Add-in and our DAX API for Power BI. Both of these new features continue to build on our commitment to support the Microsoft ecosystem and will provide large compatibility and accessibility improvements for users who integrate Cube Cloud with Excel and Power BI.

## Cube Cloud for Excel 
Last year, we added [MDX](https://cube.dev/blog/announcing-the-native-mdx-api-and-excel-integration-for-cube-cloud) to our roster of API endpoints, which is most commonly used in conjunction with Microsoft Excel. With MDX, Cube Cloud was the first cloud-native universal semantic layer to support Excel as a complete replacement to legacy OLAP engines frequently used by enterprise customers. Since its release this has been a popular API endpoint, and we have big plans ahead to continue improving it.

However, MDX unfortunately has a notable limitation - it’s only available to users who are using desktop versions of Microsoft Excel on Windows platforms. This left a whole group of users - such as Mac enthusiasts, mobile users, and users of browser-based versions of Excel out in the cold. This didn’t sit right with us, given our commitment to interoperability as a truly universal semantic layer. 

Today, we are launching the public preview of our [Cube Cloud for Excel Add-in](https://appsource.microsoft.com/en-us/product/office/WA200008486?tab=Overview) for, which is available for all Excel applications that support add-ins. This add-in provides a custom pivot table UI experience that allows users to drag and drop their metrics, columns, rows and filters to easily perform detailed analysis. For more information about the Cube Cloud for Excel, please take a look at our [feature blog](https://cube.dev/blog/introducing-multi-platform-microsoft-excel-add-in-for-cube-cloud?utm_source=cube&utm_medium=blog&utm_content=cube%20for%20microsoft%20enterprise%20blog).

![](https://ucarecdn.com/ddf707e6-168f-46b7-82e1-06b42e85e6b2/-/quality/smart/-/format/auto/)

## Cube Cloud DAX API for Power BI
Cube Cloud has supported Power BI as a visualization tool via our SQL API endpoint and our semantic layer sync capability. While this works, we always knew there was a better integration method far off in the distance, __DAX__. The Data Analysis Expressions (DAX) formula language provides the highest level of compatibility with Power BI, as it is the method by which it communicates with most native Microsoft analytic backend technologies that share lineage with Analysis Services, via the XMLA (XML for analysis) protocol. 

With the introduction of the Cube Cloud DAX API, users of Power BI can now connect to models in their Cube Cloud environment over the XMLA protocol. This provides improved feature compatibility and improved performance, while helping customers retire difficult to manage Analysis Services environments. It will also enable users of modern cloud data platforms such as Snowflake and Databricks to improve the user experience of these platforms with Power BI. Cube Cloud dynamically translates DAX over XMLA to the SQL dialects these platforms speak without the need for any import modes, or moving data out of these platforms. 

Bringing the DAX API online has been a major engineering undertaking at Cube and we are very proud of the results. We hope that you’ll take a look at this release if you’re using Power BI and struggling with performance or cost concerns with Analysis Services, or Fabric capacity SKUs. You can find more information about the public preview of the Cube Cloud DAX API in the [feature blog](https://cube.dev/blog/introducing-dax-api-for-native-microsoft-power-bi-connectivity?utm_source=cube&utm_medium=blog&utm_content=cube%20for%20microsoft%20enterprise%20blog).

![](https://ucarecdn.com/3566eb39-5098-450b-a163-2462286ba659/-/quality/smart/-/format/auto/)

## Conclusion

Cube Cloud has long supported Microsoft Azure as a public cloud infrastructure and we have many customers who run mission critical workloads there today. Additionally, we have long supported Microsoft databases as data sources. Customers who run Cube Cloud on Azure enjoy an excellent platform experience, including support for a powerful identity management platform in Microsoft Entra ID. Learn more about our integrations on the [Microsoft partnership page](https://cube.dev/partnerships/technology/microsoft/?utm_source=cube&utm_medium=blog&utm_content=cube%20for%20microsoft%20enterprise%20blog).

While today’s release is geared towards improving our support of the two most popular Microsoft technologies used by data analysts - __Excel__ and __Power BI__, we are nowhere near done with our work and will continue to expand support for the Microsoft ecosystem. 

If you have any questions about today’s release, or you’d like to learn more, or maybe take these public previews for a test spin please either reach out to your Cube account team, connect via the [contact form](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=microsoft%20launch%20announcement), or reach out to me directly.


Cube for the Microsoft Enterprise


Without a doubt, Microsoft Power BI is the most popular business intelligence and analytics software worldwide, second only to [Microsoft Excel](https://cube.dev/blog/introducing-multi-platform-microsoft-excel-add-in-for-cube-cloud). Despite all recent transformative waves in the data space, including the transition to cloud platforms such as Snowflake and Databricks, Power BI remains unrivaled and as strong as ever.

A year ago, we [introduced](https://cube.dev/blog/introducing-semantic-layer-sync-with-power-bi) support for Power BI in Cube Cloud. It was enabled by the [innovative SQL API](https://cube.dev/blog/query-push-down-in-cubes-semantic-layer) and [Semantic Layer Sync](https://cube.dev/docs/product/apis-integrations/semantic-layer-sync), the technology that bridges the gap with BI tools (such as Tableau or Preset) by populating datasets, synchronizing field descriptions, and streamlining live connectivity.

At the same time, Microsoft Power BI provides its own native mechanism for data access, based on the [XML for Analysis](https://learn.microsoft.com/en-us/analysis-services/xmla/xml-for-analysis-xmla-reference?view=asallproducts-allversions) (XMLA) protocol. So, it's only natural for Cube, as the leading universal semantic layer, to support this option.

__Today, we're thrilled to introduce the DAX API for native connectivity between Cube Cloud and Microsoft Power BI.__ Now you can connect Power BI to your semantic layer in the same way it connects to Azure Analysis Services or a regular SSAS instance. Just choose the <Btn>SQL Server Analysis Services database</Btn> option and enter the DAX API credentials provided by Cube Cloud:

![](https://ucarecdn.com/bab6835a-1ab8-492d-9d13-e1f332ddfb4a/)

Watch this end-to-end demo to gain insight into the experience:

<div><div style={{position: 'relative', paddingTop: '62.5%'}}><iframe src="https://www.youtube.com/embed/vgrFPOMuJJs" style={{position: 'absolute', top: 0, left: 0, width: '100%', height: '100%'}} frameBorder="0" allowFullScreen></iframe></div></div>

## Public preview of the DAX API

__We're currently launching the DAX API in public preview.__ However, we're confident that it already comes with capabilities that make it fit for production use cases:

* __All frequently used visualization types and filtering options are supported__. You can build complex dashboards with slicers that work across multiple charts.
* __Both [live connection and DirectQuery](https://learn.microsoft.com/en-us/power-bi/connect-data/service-live-connect-dq-datasets) methods are supported.__ With a _live connection_, you can access the semantic model in Cube Cloud and use it to build reports in Power BI. As the semantic model evolves, Cube Cloud will synchronize the updates to the model with Power BI. With _DirectQuery_, you can create a semantic model in Power BI from the semantic model in Cube Cloud and then use it to build reports. This way, you can write your own DAX queries instead of relying on Power BI to generate them. However, doing so requires you to manually synchronize the models as they evolve.
* __An essential subset of [DAX functions](https://learn.microsoft.com/en-us/dax/dax-function-reference) is already supported.__ We're working on further expanding the list of functions to support all popular calculations and use cases. Please refer to the [documentation](https://cube.dev/docs/product/apis-integrations/dax-api/reference) for reference.

![](https://ucarecdn.com/c361411e-cdce-494f-9b4d-bd83e6bc1ff2/)

## What's next?

__The DAX API is available to customers on Enterprise and above product tiers.__ It also requires the [deployment tier](https://cube.dev/docs/product/deployment/cloud/pricing#deployment-tiers) M to ensure a great querying experience and low-latency responses, even for complex dashboards.

We are inviting all Cube Cloud customers who use Power BI via the SQL API and Semantic Layer Sync to transition to the DAX API to get the best of the new capabilities.

If you're not a Cube Cloud user yet but would like to experience the new DAX API, please [get in touch](https://cube.dev/contact)—we'd be happy to guide you.


Alex Qyoun-ae

Introducing DAX API for native Microsoft Power BI connectivity


Among the [BI & data visualization tools](https://cube.dev/docs/product/configuration/visualization-tools) supported by Cube Cloud, spreadsheets remain among the most essential tools by user volume worldwide. Business users and data analysts rely on spreadsheets at least as much as standalone BI tools, if not more.

Last year, we introduced support for Microsoft Excel via the [MDX API in Cube Cloud](https://cube.dev/blog/announcing-the-native-mdx-api-and-excel-integration-for-cube-cloud). This option is unmatched because it enables you to use the native [PivotTable tool](https://support.microsoft.com/en-us/office/create-a-pivottable-to-analyze-worksheet-data-a9a84538-bfe9-40a9-a8e9-f99134456576) for analysis and reporting. However, connecting to an external data source via the MDX API is only possible when running Excel on Windows. Other operating systems (such as macOS) and other platforms (such as web and mobile), which still have many Excel users, are restricted by Microsoft from using the MDX API.

__Today, we're expanding Microsoft Excel support further with the official add-in, [Cube Cloud for Excel](https://appsource.microsoft.com/en-us/product/office/WA200008486?tab=Overview).__ We’re launching this add-in in public preview and inviting you to give it a try for your use cases in Excel. It can be particularly helpful if you'd like to use Excel for the web (part of Microsoft 365) or run Excel on your Mac laptop. Also, if you're adopting the [modern cloud OLAP](https://cube.dev/use-cases/modern-cloud-olap) approach and migrating from solutions like SSAS or SAP HANA, then Cube Cloud for Excel will naturally blend into your workflow.

![](https://ucarecdn.com/3dbe016f-bccd-4842-94e2-1d6a7ede3726/)

With this integration, you can build reports in Microsoft Excel using metrics from your Cube Cloud semantic layer. Whether you use Excel as your primary data reporting and analysis tool or alongside a BI platform such as [Microsoft Power BI](https://cube.dev/blog/introducing-dax-api-for-native-microsoft-power-bi-connectivity), this add-in will definitely streamline your workflow.

Watch the video below to see Cube Cloud for Excel in action:

<div><div style={{position: 'relative', paddingTop: '80%'}}><iframe src="https://www.youtube.com/embed/vG7iEdYTvIQ" style={{position: 'absolute', top: 0, left: 0, width: '100%', height: '100%'}} frameBorder="0" allowFullScreen></iframe></div></div>

We did our best to provide you with a pivot table UI that feels as native as possible. It enables effortless drag-and-drop analysis with metrics, columns, rows, and filters. Check out our [documentation](https://cube.dev/docs/product/apis-integrations/microsoft-excel) to learn more about its features.

![](https://ucarecdn.com/65c5dcbf-5f1c-47b7-b162-a14483f64972/)

__Cube Cloud for Excel is available for customers on Enterprise and above product tiers.__ Please contact your dedicated customer success manager to onboard you to this new feature. Later, when this add-in goes to general availability, you'll be able to install it directly from the Microsoft AppSource marketplace.

If you're not a Cube Cloud user yet but you'd like to experience the power of the semantic layer with Microsoft Excel, please [get in touch](https://cube.dev/contact), and we'd be happy to guide you.


Alex Vasilev

Introducing multi-platform Microsoft Excel add-in for Cube Cloud


Cube Core version 1.2 is the [latest release](https://github.com/cube-js/cube/releases/tag/v1.2.0) to date. It includes features such as:
* [Data access policies](#data-access-policies) for access control. 
* [Hierarchies and folders](#hierarchies-and-folders) in the data model.
* [New features in Playground](#new-in-playground).
* Apache Pinot and Vertica as [supported data sources](#new-in-data-source-support).
* [Performance optimizations](#performance-optimizations) in Cube Store and APIs.

__This release has no breaking changes.__ You should be able to upgrade without any changes to your existing data models or configurations.

## Data access policies

With data access policies, you can define member-level and row-level access control rules in data model files and assign them to user roles, allowing for an organized and maintainable approach to security.

Here is an example of how a data access policy is defined in a cube:

```yaml
views:
  - name: orders
    # ...

    access_policy:
      - role: manager
        conditions:
          - if: "{ securityContext.is_EMEA_based }"
        member_level:
          includes:
            - created_at
            - status
            - count
        row_level:
          filters:
            - member: country
              operator: equals
              values: [ "{ securityContext.country }" ]
```

Watch this demo to see data access policies in action:

<div><div style={{position: 'relative', paddingTop: '75%'}}><iframe src="https://www.youtube.com/embed/yJfnYB27wSQ" style={{position: 'absolute', top: 0, left: 0, width: '100%', height: '100%'}} frameBorder="0" allowFullScreen></iframe></div></div>

Read more in the [announcement](https://cube.dev/blog/introducing-data-access-policies-ga-and-ldap-integration-in-cube-cloud) and check out the [documentation](https://cube.dev/docs/product/auth/data-access-policies).

## Hierarchies and folders

With hierarchies, you can organize related dimensions and assign them to certain levels of granularity. With folders, you can group members of a view into logical folders to make it easier to navigate and understand the data model.

These entities can be leveraged by visualization tools that support them. Except for Playground, these are currently Cube Cloud-only integrations with Tableau, Microsoft Excel, and Microsoft Power BI.

Example hierarchy definition:

```yaml
cubes:
  - name: customers
    # ...

    dimensions:
      # Dimension definitions skipped for brevity

    hierarchies:
      - name: location
        title: Customer Location
        levels:
          - country
          - state
          - city
          - zip_code
```

Example folder definition:

```yaml
views:
  - name: employee_details

    cubes:
      - join_path: employees
        includes:
          # List of members skipped for brevity

    folders:
      - name: Personally Identifiable Information
        includes:
          - first_name
          - last_name
          - location
```

Once you've defined hierarchies and (or) folders in your data model, you can use Playground to explore them visually:

<div><div style={{position: 'relative', paddingTop: '75%'}}><iframe src="https://www.youtube.com/embed/Y5E6DmH_Hz4" style={{position: 'absolute', top: 0, left: 0, width: '100%', height: '100%'}} frameBorder="0" allowFullScreen></iframe></div></div>

Read more in the [announcement](https://cube.dev/blog/introducing-hierarchies-and-folders-support). Check the documentation: [hierarchies](https://cube.dev/docs/reference/data-model/hierarchies), [folders](https://cube.dev/docs/reference/data-model/view#folders).

## New in Playground

Except for the support for hierarchies and folders, Playground has got the support for [custom time dimension granularities](https://cube.dev/blog/introducing-custom-time-dimension-granularities), [boolean logical filters](https://cube.dev/docs/product/apis-integrations/rest-api/query-format#boolean-logical-operators) composition, and options to set limit/offset or request the count of all rows in the result set as if there's no limit.

Take a quick look at the improvements to Playground:

<div><div style={{position: 'relative', paddingTop: '75%'}}><iframe src="https://www.youtube.com/embed/4epojUSQvOU" style={{position: 'absolute', top: 0, left: 0, width: '100%', height: '100%'}} frameBorder="0" allowFullScreen></iframe></div></div>

Oh, and you can now close all tabs at once!

## New in data source support

Cube has got the support for a couple of new data sources: [Apache Pinot](https://cube.dev/docs/product/configuration/data-sources/pinot) and [Vertica](https://cube.dev/docs/product/configuration/data-sources/vertica), both contributed by members of the Cube community.

We have also transitioned [ClickHouse](https://cube.dev/docs/product/configuration/data-sources/clickhouse) support to the official `@clickhouse/client` package, which brought a number of improvements and optimizations.

Finally, [DuckDB](https://cube.dev/docs/product/configuration/data-sources/duckdb) users can now specify extensions to be loaded via the `CUBEJS_DB_DUCKDB_EXTENSIONS` environment variable.

## New in configuration

The [`scheduled_refresh_time_zones` configuration option](https://cube.dev/docs/reference/configuration/config#scheduled_refresh_time_zones) can now be implemented as a function that accepts a security context as an argument:

```python
from cube import config

@config('scheduled_refresh_time_zones')
def scheduled_refresh_time_zones(ctx: dict) -> list[str]:
  time_zones = {
    'tenant_1': ['America/New_York'],
    'tenant_2': ['America/Chicago'],
    'tenant_3': ['America/Los_Angeles']
  }
  default_time_zones = ['UTC']
  tenant_id = ctx['securityContext']['tenant_id']
  return time_zones.get(tenant_id, default_time_zones)
```

In multitenancy scenarios, this allows you to build pre-aggregations for different tenants in their respective time zones only. This can substantially reduce the number of pre-aggregation partitions that need to be built.

## New in CLI

The [`deploy` command](https://cube.dev/docs/reference/cli#deploy) of the CLI tool now supports the `--replace-env` flag. If you [deploy with CLI](https://cube.dev/docs/product/deployment/cloud/continuous-deployment#deploy-with-cli), you can use this flag to _upload and replace_ environment variables every time.

```bash
npx cubejs-cli deploy --replace-env --directory PATH --token TOKEN
```

## New in the client library

The JavaScript client library now supports the `fillWithValue` [pivot configuration](https://cube.dev/docs/reference/frontend/cubejs-client-core#pivotconfig) option. It will use the provided value to fill the measure values for missing dates in the result set.

## Performance optimizations

When Cube Store executes queries against pre-aggregations, the results need to be transformed into the format that the SQL API or the REST API expect. We have optimized this process by moving the transformation logic to the native code, written in Rust, and performing the transformation asynchronously, so that the Node.js event loop is not blocked.

This brings a tangible performance improvement to Cube deployments running heavy queries that include dozens of dimensions and measures. On average, this speeds up the transformation process by 40-50% or by hundreds of milliseconds per query (if it has from 50 to 100 members).

Before the optimization:

![](https://ucarecdn.com/aea8c399-7855-4d36-94e3-980dce5b7db9/)

After the optimization:

![](https://ucarecdn.com/9ae8b133-864f-4127-8d13-fda9596005ee/)

## What's next?

As this is a release without breaking changes, we encourage you to upgrade and give it a try. You can also do that for free in [Cube Cloud](https://cubecloud.dev/auth/signup).

We can't wait to hear your feedback and thoughts in the [Slack community](https://slack.cube.dev), both about the updates above and the features from the [Cube Core public roadmap](https://github.com/cube-js/cube/issues/8492).

Enjoy the new features and happy Cube-ing!


Cube Core v1.2 — Data access policies, hierarchies & folders, updates to Playground


An essential part of building a great data model is the ability to test and validate it. Within Cube, Playground is a powerful tool that allows you to interact with your data model, explore the data, and test queries. Ever since we've [shipped Playground 2.0](https://cube.dev/blog/introducing-playground-2) a while ago, we've been continuously iterating on your feedback and enhancing the experience.

**Today, we are happy to announce a new feature pack for Playground.** It brings the support for the latest features in the data modeling layer (i.e., hierarchies and folders, custom granularities), advanced filtering capabilities, and additional querying options.

See new Playground features in action in this video:

<div><div style={{position: 'relative', paddingTop: '75%'}}><iframe src="https://www.youtube.com/embed/4epojUSQvOU" style={{position: 'absolute', top: 0, left: 0, width: '100%', height: '100%'}} frameBorder="0" allowFullScreen></iframe></div></div>

These new features are available in Cube Core, starting from v1.2.0, and Cube Cloud. We recommend upgrading to the latest version to take advantage of them.

## Support for data modeling features

Yesterday, we've announced the support for [hierarchies and folders](https://cube.dev/blog/introducing-hierarchies-and-folders-support) in the data modeling layer. While they are designed to help you organize and structure your data model in a way that feels native in your BI tools, you can also preview and interact with them in Playground.

[Custom time dimension granularities](https://cube.dev/blog/introducing-custom-time-dimension-granularities) were introduced to Cube's data modeling layer a while ago so that you can define granularities such as a _fiscal year_ or a _week starting on Sunday_ for any time dimension. If you use them, you can validate your queries in Playground, too.

## Support for advanced filtering

Cube supports pretty complex filtering conditions that can include [boolean logical operators](https://cube.dev/docs/product/apis-integrations/rest-api/query-format#boolean-logical-operators). Now, you can build nested filtering conditions with unlimited depth in Playground, or load such queries there from [Query History](https://cube.dev/docs/product/workspace/query-history).

And when it comes to filters that accept values from your dataset, you can now look up the available values directly in Playground. It will run a query to fetch the distinct values for the selected member and display them in a dropdown:

![](https://ucarecdn.com/10cda28d-d57c-42ff-9073-0096a035191e/)

## Support for additional querying options

In the "Options" drop-down, you now set the [limit](https://cube.dev/docs/product/apis-integrations/queries#row-limit) and offset for your queries. You can also request that Playground runs an additional query to fetch the total count of rows that would have been returned as if the limit and offset were not applied. This is particularly useful if you're [implementing pagination](https://cube.dev/docs/guides/recipes/queries/pagination) in your application.

And there are also smaller improvements, such as the tab actions to let you quickly duplicate the current query or drop all queries at once and start from scratch.

## What's next?

Do you know what would make Playground even better? We'd love to hear your feedback and suggestions. Join the [community Slack](https://slack.cube.dev) and start a conversation there!

Also, don't hesitate to try Playground yourself. You can [sign up for Cube Cloud](https://cubecloud.dev/auth/signup) today (absolutely free), create a [demo deployment](https://cube.dev/docs/product/deployment/cloud/deployments#demo-deployments), and get started right away.


Bringing a new feature pack to Playground


Cube is known to be the only open-source semantic layer with legitimate adoption and, among other reasons, this is due to its great data modeling capabilities. Lately, we've been focusing on increasing the sophistication of the data modeling experience in Cube with [custom time dimension granularities](https://cube.dev/blog/introducing-custom-time-dimension-granularities) and [multi-stage calculations](https://cube.dev/blog/introducing-next-generation-data-modeling-engine).

__Today, we are excited to announce the release of hierarchies and folders support.__ Now, you can use hierarchies to organize dimensions in your cubes. Also, you can group members of a view into logical folders to make it easier to navigate and understand the data model. Cube will ensure that hierarchies and folders are correctly reflected in the BI tools that support them.

See hierarchies and folders in action in this video:

<div><div style={{position: 'relative', paddingTop: '75%'}}><iframe src="https://www.youtube.com/embed/Y5E6DmH_Hz4" style={{position: 'absolute', top: 0, left: 0, width: '100%', height: '100%'}} frameBorder="0" allowFullScreen></iframe></div></div>

## Hierarchies

Often, data model have numerous dimensions and some of them are crearly related to each other. Hierarchies can help organize such dimensions by grouping them together and assigning appropriate levels of granularity. For example, the `location` hierarchy can include `country`, `state`, `city`, and `zip_code` dimensions:

```yaml
cubes:
  - name: customers
    # ...

    dimensions:
      # Dimension definitions skipped for brevity

    hierarchies:
      - name: location
        title: Customer Location
        levels:
          - country
          - state
          - city
          - zip_code
```

Cube will only expose hierarchies defined in your data model to [BI tools](https://cube.dev/docs/product/configuration/visualization-tools#bi--data-exploration) that support them. Right now, you can use hierarchies in [Microsoft Excel](https://cube.dev/docs/product/configuration/visualization-tools/excel) and [Microsoft Power BI](https://cube.dev/docs/product/configuration/visualization-tools/powerbi). If you're building a custom embedded analytics solution, you can use hierarchies there as well: they are available via the [metadata API endpoint](https://cube.dev/docs/reference/rest-api#v1meta).

Finally, Playground can also visualize hierarchies and folders for you, both in Cube Cloud and self-hosted Cube:

![](https://ucarecdn.com/8a38093e-0e5e-41e5-8789-ceed91674e86/)

To learn more about hierarchies, check the [documentation](https://cube.dev/docs/reference/data-model/hierarchies).

## Folders

Folders are used to organize members of a view (e.g., dimensions, hierarchies, measures, etc.) into logical groups so you can easily navigate through them in your BI tool. For example, you can group all measures, dimensions, and hierarchies that constitute personally identifiable information (PII) into a `PII` folder:

```yaml
views:
  - name: employee_details

    cubes:
      - join_path: employees
        includes:
          # List of members skipped for brevity

    folders:
      - name: Personally Identifiable Information
        includes:
          # Dimensions
          - first_name
          - last_name
          - email
          - phone
          # Hierarchies
          - location
          - business_unit
          # Measures
          - avg_salary
          - yoy_salary_growth
```

Similarly to hierarchies, Cube will only expose folders to BI tools that support them. Right now, you can use folders in [Tableau](https://cube.dev/docs/product/configuration/visualization-tools/tableau) with [Semantic Layer Sync](https://cube.dev/docs/product/apis-integrations/semantic-layer-sync). Of course, you can build folders into your custom embedded analytics application, too.

To learn more about folders, check the [documentation](https://cube.dev/docs/reference/data-model/view#folders).

## What's next?

Hierarchies and folders support is available in Cube Core and Cube Cloud starting from v1.2.0. We recommend upgrading to the latest version to take advantage of these features.

If you have any questions or feedback, reach out to us on [Slack](https://slack.cube.dev). Also, don't hesitate to [request a demo](https://cube.dev/contact) or [sign-up for Cube Cloud](https://cubecloud.dev/auth/signup) to get started with Cube in minutes.


  Introducing hierarchies and folders support


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!


Online Analytical Processing (OLAP)

About Query Interfaces for OLAP Systems


Granular [access control](https://cube.dev/product/data-access-control) has always been a core pillar of Cube's universal semantic layer. A few months ago, we've [launched](https://cube.dev/blog/introducing-data-access-policies-in-cube-cloud) the private preview of the data access policies feature. Since then, we've iterated on the feedback from Cube Cloud customers and ensured that this feature meets the needs of both enterprise customers and open-source users.

__Today, we're announcing the general availability of [data access policies](#data-access-policies) in Cube Core and Cube Cloud.__ On top of that, we're announcing the all-new [LDAP integration](#ldap-integration) in Cube Cloud, which allows you to load user roles and permissions from your LDAP server and use them in your data access policies. Finally, we're also announcing the [Cube Cloud authentication integration](#cube-cloud-authentication-integration), which enhances Cube's authentication mechanisms with Cube Cloud-only features such as the LDAP integration.

## Data access policies

Since its inception, Cube has provided a way to manage [member-level](https://cube.dev/docs/product/auth/member-level-security) and [row-level](https://cube.dev/docs/product/auth/row-level-security) security of the data. Now, with data access policies, you can define all access control rules in data model files, allowing for an organized and maintainable approach to security.

As an example, here's an example policy that provides unrestricted access to users with the `leadership` role and exposes a subset of members to EMEA-based users with the `manager` role, ensuring that they can only access orders of users from their own country:

```yaml
views:
  - name: orders
    # ...

    access_policy:
      - role: leadership
        member_level:
          includes: "*"
        row_level:
          allow_all: true

      - role: manager
        conditions:
          - if: "{ securityContext.is_EMEA_based }"
        member_level:
          includes:
            - created_at
            - status
            - count
        row_level:
          filters:
            - member: country
              operator: equals
              values: [ "{ securityContext.country }" ]
```

Here's a quick demo of how data access policies, Cube Cloud authentication integration, and the LDAP integration work in Cube Cloud:

<div><div style={{position: 'relative', paddingTop: '75%'}}><iframe src="https://www.youtube.com/embed/yJfnYB27wSQ" style={{position: 'absolute', top: 0, left: 0, width: '100%', height: '100%'}} frameBorder="0" allowFullScreen></iframe></div></div>

You can also use the new Access Policies section in Cube Cloud to analyze data access policies defined in your data models:

![](https://ucarecdn.com/ab05c330-db28-4005-bb23-befca8e43910/)

Data access policies are available both in Cube Core, starting from [v1.2.0](https://github.com/cube-js/cube/releases), and Cube Cloud. We recommend upgrading to the latest version to try them out.

You can learn more about data access policies in the [documentation](https://cube.dev/docs/product/auth/data-access-policies).

## Cube Cloud authentication integration

This feature tighlty integrates features that are only possible or available in Cube Cloud with Cube's authentication mechanisms.

For example, with Cube Cloud authentication integration, you can authenticate connections to Cube's SQL API against the list of users in your Cube Cloud account. You can see this in action at [this step](https://youtu.be/yJfnYB27wSQ?si=Sw0unl4Bk8eZxwKi&t=192) in the demo video above. As a yet another example, you can let Cube Cloud load user roles and permissions from your LDAP server and use them in the data access policies defined in Cube's data model files.

In both cases, Cube Cloud authentication integration will read and (or) populate the security context of your request with the user's attributes. This way, you can use that information from the security context in your data access policies:

```json
{
  "cubeCloud": {
    "roles": [
      "leadership",
      "Developer"
    ],
    "username": "igor@cube.dev"
  }
}
```

You can enable Cube Cloud authentication integration in the settings of your Cube Cloud deployments. Also, you can learn more about this feature in the [documentation](https://cube.dev/docs/product/auth#authentication-integration).

## LDAP integration

LDAP integration in Cube Cloud allows you to load user roles and permissions from your LDAP server and use them in your data access policies. This feature is particularly useful for enterprise customers who already have an LDAP server, such as [Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/architecture/auth-ldap) or [Secure LDAP service](https://support.google.com/a/answer/9048516?hl=en) in Google Workspace.

When the LDAP integration is configured, Cube Cloud will automatically load user attributes from the LDAP server and populate the security context of your request with them. Then, this information can be further used in your data access policies:

```json
{
  "cubeCloud": {
    "meta": {
      "ldap": {
        "enabled": true
      }
    },
    "roles": [
      "leadership",
      "Developer"
    ],
    "userAttributes": {
      "email": "igor@cube.dev",
      "fullName": "Igor Lukanin"
    },
    "username": "igor@cube.dev"
  }
}
```

You can see how it works at [this step](https://youtu.be/yJfnYB27wSQ?si=J82jW9ousYcS6khk&t=357) in the demo video above.

You can enable LDAP integration in the Team & Security settings of your Cube Cloud account. Learn more about its configuration in the [documentation](https://cube.dev/docs/product/workspace/sso#ldap-integration).

## What's next?

We believe that this set of features will streamline managing access control in Cube and make Cube Cloud a natural choice for enterprise customers who need to manage access control to data at scale.

We're excited to see how you will use these features in your projects and are looking forward to your feedback. Please share it with the customer experience team in Cube Cloud via the in-product chat or reah out via the [community Slack](https://slack.cube.dev).

Still not a Cube Cloud user? [Contact us](https://cube.dev/contact) or [sign up](https://cubecloud.dev/auth/signup) for free today.


Maksim Leanovich

Introducing Data Access Policies (GA) and LDAP integration in Cube Cloud


When designing data pipelines in modern architectures, particularly in cloud-native ecosystems, teams face a challenging balancing act. Much like the [CAP theorem](https://en.wikipedia.org/wiki/CAP_theorem) in distributed systems, which posits that you can only optimize two out of three properties—Consistency, Availability, and Partition Tolerance—data pipelines are similarly constrained by three key factors:
1. __Data Latency__
2. __Cost__
3. __Query Speed__

This “trade-off triangle” can be tricky to navigate. Why is it so hard to optimize all three? How does a solution like Cube Cloud’s universal semantic layer fit into this puzzle? Let’s break it down.

## Data Latency: The Need for Speed
When it comes to data pipelines, latency refers to the delay between when data is generated and when it's available for querying. Low latency is crucial when you’re dealing with real-time analytics, operational decision-making, or when you're working with time-sensitive data like financial transactions, web traffic, or IoT sensors.

However, low-latency systems are resource-hungry, typically requiring more infrastructure to handle the constant flow of data, which drives up costs. As you try to achieve sub-second latency for real-time insights, the need for high-performing data storage, processing engines, and complex orchestration leads to significant resource consumption, and thus, higher expenses.

## Cost: The Most Limiting Factor
While cost is often the most limiting factor, it’s also the hardest to optimize without sacrificing performance. You could design a pipeline that performs reasonably well but comes with a hefty cloud bill or requires complex infrastructure management. For instance, maintaining large data warehouses with constant updates and high query frequencies may involve expensive storage and compute costs, especially in a cloud-native environment.

The cost implications come not just from infrastructure, but also from engineering overhead. The more complex the pipeline, the more time and resources are required for setup, maintenance, and scaling.

## Query Speed: Instant Insights at Scale
Fast query speeds are essential to quickly gain insights from your data. In traditional data analytics setups, this is typically achieved by aggregating and indexing data, often pre-computing certain aggregates for quick access. However, fast queries come at a price. In some cases, they require additional caching layers, denormalization of the data, or redundant computation, which can increase costs and add complexity to your pipeline.

The challenge here is that to achieve near-instantaneous responses on large-scale datasets, your data infrastructure needs to be tuned for performance, often leading to a compromise on other factors—like cost or latency. Fast query speed is essential to quickly gain insights from your data. In traditional data analytics setups, this is typically achieved by aggregating and indexing data, often pre-computing certain aggregates for quick access. Alternatively, using OLAP data stores can also significantly increase query speed by organizing data in a multidimensional format. However, fast queries come at a price. In some cases, they require additional caching layers, denormalization of the data, or redundant computation, which can increase costs and add complexity to your pipeline.

## The Trade-Off: You Can’t Optimize All Three
When designing a modern data pipeline, you can typically optimize for __two__ of these factors, but not all three simultaneously. Let’s look at the typical trade-offs:

1. __Low Latency + Fast Queries__: This combination is ideal for real-time analytics, but achieving both typically demands expensive infrastructure. You’ll need high-performance compute resources, sophisticated data storage solutions, and a lot of manual optimization to ensure both factors stay in check. The result is high costs, both in terms of cloud infrastructure and engineering time. If you're aiming to deliver real-time analytics with immediate query responses, prepare for the bill to skyrocket.
2. __Low Latency + Low Cost__: Achieving both low latency and low cost is nearly impossible in modern data architectures without sacrificing one of the other factors. If you try to save costs while delivering low-latency data, you might end up compromising query speed, as you won't have the necessary performance optimizations in place. For example, without the use of in-memory caches or pre-aggregated data, queries will slow down, defeating the purpose of low-latency data processing.
3. __Fast Queries + Low Cost__: While it’s feasible to optimize for cost and query speed, low-latency will likely be out of reach. Fast queries can be achieved through smart indexing, materialized views, and optimized storage engines—but keeping costs low means you won’t be able to afford the infrastructure needed for low-latency data feeds. Pre-aggregating data or relying on batch processing may keep costs under control, but you’ll lose real-time data availability.

## Cube: The Flexible Solution
Cube brings consistency, context, and trust to the next generation of data experiences by balancing these trade-offs in a way that gives you more freedom over your architecture. Cube Cloud is a leading, Al-powered universal semantic layer platform, helping companies of any size to manage and deliver trusted data with a single source of truth. Any data source can be unified, governed, optimized, and integrated with any data application: Al, BI, spreadsheets, and embedded analytics.

Cube is designed to be flexible, so you can choose which of the two properties—query speed or cost—you want to optimize for, based on the needs of your specific use case. By default, Cube helps you optimize for both speed and savings, which means:

- Query speed is accelerated using advanced caching, pre-aggregated data, and efficient indexing mechanisms, while
- Cost savings is kept under control because Cube intelligently manages data storage, compute, and aggregation at scale.

This balance allows you to deliver fast analytics without a massive cost spike, making it a perfect fit for business teams that need to get insights quickly, but don’t want to bankrupt themselves in the process.

Cube can also help with cost optimization by supporting the implementation of a lambda architecture, which combines real-time streaming data with batch-processed historical data. This approach allows you to optimize costs by using batch processing for less time-sensitive data, while still providing real-time insights for critical applications.

Additionally, Cube offers fine-grained control so that you can choose to optimize different parts of your pipeline for different needs. For example, you could optimize for low latency and query speed for real-time dashboards and shift to low cost and query speed for batch processing or historical analytics.

## Choose Your Trade-Offs Wisely
The trade-offs between data latency, cost, and query speed are unavoidable when designing modern data pipelines. At best, you can only optimize for two of the three. That said, with Cube Cloud’s universal semantic layer, you can navigate this balancing act more effectively by giving you the flexibility to choose which optimizations best fit your use case.

Whether you're building real-time analytics applications, cost-sensitive reporting systems, or high-performance dashboards, Cube enables you to focus on the optimization that matters most to your business while keeping the others in check. Understanding these trade-offs and using the right platform to balance them effectively is key to building an efficient and scalable modern data stack.

[Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=trade-offs%20optimizing%20data%20pipelines%20blog) to learn how Cube can help you optimize your data pipelines.


The Trade-Offs of Optimizing Data Pipelines: Data Latency, Cost and Query Speed 


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


Customer expectations have never been higher. Speed, accuracy, and personalization are no longer optional. They’re the baseline for great service. Yet, most customer service and support teams are stuck working with fragmented, inconsistent data across multiple platforms, including CRM, help desks, chat logs, phone call records, and email interactions. 

Without a unified source of truth, customer service agents waste time searching for information, struggle with inconsistent responses, and fail to resolve issues efficiently. The result? Frustrated customers, lower retention rates, and rising service costs.

The solution? A universal semantic layer that unifies, standardizes, and optimizes customer data, ensuring every interaction is accurate, timely, and personalized, leading to higher satisfaction and operational efficiency.

## The Pain of Poor First Contact Resolution (FCR)
Customers expect their issues to be resolved immediately, not after multiple follow-ups, transfers, or escalations. But when data is scattered across different platforms, support agents lack a complete customer history, forcing them to ask repetitive questions and delay solutions.

With Cube’s universal semantic layer, customer data from every interaction channel from phone and chat to email and social media can be consolidated into a trusted, single source of truth. This empowers agents with real-time insights into past interactions, purchase history, and issue context, allowing them to resolve problems on the first contact more often. Higher First Contact Resolution (FCR) rates mean happier customers and lower operational costs.

## The Urgency of Delivering Consistently High-Quality Service
Customers expect accurate, consistent answers, whether they reach out via phone, chat, or email. But without a single, trusted dataset, service representatives often provide conflicting information, damaging trust and brand reputation.

Cube ensures that all service representatives work from the same, up-to-date knowledge base and customer records, eliminating data discrepancies and inconsistencies. This leads to higher Customer Satisfaction (CSAT) scores and improved Net Promoter Scores (NPS), both essential indicators of customer loyalty and business success.

## The High Cost of Inefficient Service Operations
Every inefficient support process adds to operational costs. When agents spend too much time searching for information, manually entering data, or switching between platforms, it leads to longer wait times, higher service costs, and frustrated employees.

Cube’s universal semantic layer provides unified data from customer service platforms, reducing manual effort and eliminating redundant processes. By streamlining service workflows, businesses can lower their Cost per Contact, increase agent productivity, and deliver faster, more efficient service.

## The Risk of Reactive, Not Proactive, Customer Engagement
Most support teams operate reactively, responding to issues only after customers reach out. But what if problems could be solved before they escalate? Without real-time data insights, service teams miss opportunities to identify trends, anticipate customer concerns, and proactively engage with solutions.

Cube’s universal semantic layer enables advanced analytics by unifying customer behavior data. This allows businesses to detect early warning signs of dissatisfaction, preemptively resolve recurring issues, and enhance customer retention efforts. Proactive engagement leads to higher retention rates, shorter Complaint Resolution Times, and a more positive brand experience.

## Cube Cloud for Customer Service & Support Departments 
When your data engineering team implements Cube Cloud, it transforms how the Customer Service & Support departments interact with data. By standardizing metrics and enhancing accessibility, Cube Cloud unlocks the full potential of your customer service and support data assets, improving collaboration and data-driven decisions.
Benefits for Customer Service & Support Departments
1. __Standardized Customer Interaction Metrics and Definitions__: Cube Cloud ensures uniform definitions for key terms such as “first response time,” “resolution rate,” or “customer satisfaction score.” This standardization eliminates discrepancies, ensuring that all reports and analyses are based on consistent criteria, fostering alignment within customer service and support teams and across the enterprise.
2. __Enhanced Data Accessibility__: Customer service professionals can access data through their preferred BI tools and spreadsheets without the underlying complexities of data structures and relationships. Cube Cloud integrates with various BI platforms, enabling seamless data retrieval and analysis, thus democratizing data access.
3. __Improved Decision-Making__: With consistent and accessible data, customer service and support teams can make faster, more informed decisions from a single source of truth. This leads to increased agility and a competitive edge in the market.
4. __Reduced Dependence on Technical Teams__: While deploying and managing Cube Cloud requires technical expertise, once established, customer service professionals can interact with data without constant IT intervention. Less technical users can even contribute to the data modeling process with visual tools to turn clicks into code. This empowerment leads to increased productivity and efficiency.
5. __Scalability and Flexibility__: As organizations grow, Cube Cloud scales to accommodate new data sources, new data consumers, and evolving business needs, ensuring sustained consistency and reliability with AI- and BI-ready data.

## Unify, Govern, Optimize: The Future of Trusted Analytics
The best customer service teams don’t just react to issues; they anticipate and prevent them. To achieve this, they need a data infrastructure that provides accurate, real-time customer insights. Cube’s universal semantic layer empowers service organizations to:
- Unify all customer service data into a single, trusted source of truth.
- Govern data to ensure consistency, accuracy, and reliability across all touchpoints.
- Optimize service operations, agent efficiency, and proactive customer engagement with real-time insights.

The result? A high-performing customer service team that operates with speed, precision, and confidence, delivering superior experiences that drive retention, loyalty, and business growth.

Now is the time to modernize customer service with Cube. Don’t let data silos hold your support team back. Unlock the full potential of your customer experience today. [Contact sales](https://cube.dev/contact?utm_source=cube&utm_medium=blog&utm_content=customer%20service%20blog) to learn more about how Cube Cloud improves customer service and support analytics.
