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 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.

Brian Bickell

All Things Cube

Improving Cube Cloud support for Microsoft Excel and Power BI

Cube for the Microsoft Enterprise

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.__ 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.

Igor Lukanin

News

Preview of a yet another Cube Cloud integration with Microsoft Excel

Introducing multi-platform Microsoft Excel add-in for Cube Cloud

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.

Preview of the most powerful Cube Cloud integration with Microsoft Power BI

Introducing DAX API for native Microsoft Power BI connectivity

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!


Artyom Keydunov

Online Analytical Processing (OLAP)

About Query Interfaces for OLAP Systems

The shift to cloud data storage has been a transformative move for enterprises, promising scalability, security, and accessibility, but the journey is not without obstacles. One common and critical challenge that many organizations face post-migration is the disruption of live queries from spreadsheets—a staple in business operations. For technical decision-makers, this presents a significant hurdle. 

Fortunately, Cube Cloud’s universal semantic layer not only enables but also enhances the spreadsheet experience. In this blog, learn why Cube Cloud and spreadsheets are a powerful combination to enable live queries in Microsoft Excel and Google Sheets.

## Losing Live Query Capabilities in Spreadsheets
Despite advancements in modern BI and data visualization platforms, spreadsheets remain an indispensable part of the business productivity suite. Their flexibility, ease of use, and ubiquity make them an irreplaceable tool for many users. From finance departments running complex calculations to sales teams tracking targets, spreadsheets are deeply ingrained in daily workflows in multiple lines of business.

While the migration to cloud data platforms like Databricks, Snowflake, BigQuery, or Redshift is a strategic move towards a more modern, scalable infrastructure, an unintended consequence is the inability to live query cloud data from spreadsheets. This issue arises because traditional spreadsheet tools like Microsoft Excel and Google Sheets aren’t natively designed to interact seamlessly with most cloud data platforms. 

## Why Cube Cloud and Spreadsheets Are Better Together
Instead of forcing users to export data manually, which is time-consuming and error-prone, there is a better way forward with Cube Cloud. It offers an enhanced solution to the spreadsheet dilemma with the universal semantic layer. 

Cube Cloud seamlessly integrates with your existing cloud data infrastructure, improving your data and analytics workflows. The platform supports a wide range of data sources, BI tools, and spreadsheets, making it a versatile addition to your data stack. It’s the ideal choice for enterprises seeking to bridge the gap between their cloud data platforms and spreadsheets.

### Unify Data Models and Metrics
Cube Cloud acts as an intermediary between your cloud data platform and spreadsheets. It provides a unified access point that standardizes queries and ensures consistent data definitions across all tools. This means that whether a user is working in Microsoft Excel, Google Sheets, or a modern BI platform, they’re accessing the same, consistent data.

### Centralize Governance and Security
One of the major concerns with data exports is the potential for data breaches and loss of data integrity from manual manipulations. Cube Cloud addresses this by centralizing data governance and security. With the universal semantic layer, you can enforce access controls and permissions, ensuring that only authorized users can access sensitive information. This mitigates the risk associated with data sprawl and unauthorized data exports.

### Optimize Performance
Live querying from spreadsheets to cloud data platforms can be costly, resource-intensive, and slow if not managed properly. Cube Cloud optimizes query performance through pre-aggregation caching. This ensures that your users can run complex queries directly from their spreadsheets without experiencing significant lag or performance issues.

## How Cube Cloud Enhances Spreadsheet Analytics
By integrating Cube Cloud, you can restore the ability for direct data interactions within spreadsheets. Users can refresh their data, apply filters, and run analyses on the latest information without needing to export and re-import data. This real-time capability is crucial for making informed business decisions quickly and accurately.

You can extend the benefits of the universal semantic layer by allowing anyone to connect, analyze, and reuse trusted data assets with Microsoft Excel and Google Sheets using a live connection, without exports or snapshots. This integration eliminates the need for pre-processing, ensures real-time data access, and streamlines complex data transformations, allowing analysts to focus on deriving insights and storytelling.

### Modern Cloud OLAP in Microsoft Excel
The native MDX API in Cube Cloud leverages Excel’s native Analysis Services connection. It integrates the universal semantic layer with Excel so that users can perform multidimensional analysis and leverage Excel's powerful data analysis features while maintaining a connection to Cube Cloud. Now, you can leave legacy systems behind, and step into the future to support [Modern Cloud OLAP](https://cube.dev/use-cases/modern-cloud-olap).

By migrating from legacy OLAP platforms, organizations can stop supporting the older systems, providing license and maintenance savings and replacing them with more powerful, modern cloud data platforms. With the MDX API, Excel directly queries large datasets through the universal semantic layer. The MDX queries are translated into optimized SQL, processed by Cube, and the results are returned to Excel. 

![](https://ucarecdn.com/0b221539-69c7-4ffa-b201-5f2755f0b5ee/-/quality/smart/-/format/auto/)

### Perform Live Queries in Google Sheets
Cube Cloud for Sheets is a Google Sheets Add-on. It can be found in the [Google Workspace Marketplace](https://workspace.google.com/marketplace) and installed via the browser, or added from Google Sheets directly from Extensions > Add-ons. Once installed, you can access a Cube Cloud sidebar. With Cube Cloud for Sheets, customers can search data assets and create pivot tables from modeled data in Cube. 

Cube Cloud for Sheets integrates the universal semantic layer with Google Sheets so that users can perform live queries on governed data with Google Sheets, while maintaining a connection to Cube. With the add-on, Google Sheets can directly query and aggregate any data modeled in Cube Cloud through the universal semantic layer, opening up data access beyond BigQuery and Looker, the default connection options.

![](https://ucarecdn.com/dcbce8da-e711-41ab-93e1-f87adc243f2c/-/quality/smart/-/format/auto/)

## Enable Live Query Capabilities with Spreadsheets and Cube Cloud
The future of enterprise data is in the cloud, but that doesn’t mean we should leave behind the tools that have proven their worth over decades. Spreadsheets are here to stay, and with Cube Cloud’s universal semantic layer, you can ensure they remain powerful and governed tools for everyone in your organization. 

By restoring live query capabilities, enhancing data governance, and optimizing performance, Cube Cloud bridges the gap between your cloud data warehouse and the familiar spreadsheet environment, empowering your teams to work smarter and more efficiently.

Embrace the best of both worlds—modern cloud infrastructure and the timeless utility of spreadsheets—with Cube Cloud. [Contact sales](https://cube.dev/contact) to learn more about live queries in Microsoft Excel and Google Sheets.

Michael Hetrick

Deep Dives

How Cube Improves Spreadsheet Analytics

At Cube, we deeply care about the experience that data professionals have when building and maintaining semantic layers. Earlier this year, we launched [Playground 2.0 in Cube Cloud](https://cube.dev/blog/introducing-playground-2) and promised to bring it to Cube Core as well so that everyone in the Cube community can benefit from using it.

**Today, we're happy to announce that Playground 2.0 has been released in Cube Core.** Starting from v0.36, you can now use Playground 2.0 to build and validate your data model by executing queries and previewing their results in a BI-like interface. You can view the data model entities or search for them, compose a query from scratch or paste an existing query, view results, check a generated query, or copy equivalent queries for data APIs.

**Moreover, we're also releasing Chart Prototyping in Cube Core as well.** Previously [available only in Cube Cloud](https://cube.dev/blog/embedded-analytics-with-chart-prototyping), Chart Prototyping can help you go from zero to a minimal yet complete front-end application that queries Cube via its REST API and visualizes data on charts. You can generate the code in an instant and then download it to customize on your machine.

## What has changed

Now, when you start Cube Core in the [development mode](https://cube.dev/docs/product/configuration#development-mode), just like you would expect, Playground 2.0 will be available at `http://localhost:4000`. The previous version of Playground has been removed from the Cube Core distribution. 

Here's how Playground 2.0 and Chart Prototyping work:

<div><div style={{position: 'relative', paddingTop: '56.25%'}}><iframe src="https://www.youtube.com/embed/5T7RfG_S7FY" style={{position: 'absolute', top: 0, left: 0, width: '100%', height: '100%'}} frameBorder="0" allowFullScreen></iframe></div></div>

As a friendly reminder, we'd like to point out that Playground is designed to help _you_ build and validate data models. If you'd like to provide your end-users with a BI experience, it is recommended to connect one of many [supported data visualization tools](https://cube.dev/docs/product/configuration/visualization-tools) to Cube.

## What's next?

Playground 2.0 and Chart Prototyping are available in Cube Core starting from v0.36. When upgrading to this version, please make sure to check the [release notes](https://github.com/cube-js/cube/releases/tag/v0.36.0) for breaking changes and deprecations.

Later, we will also publish the React components used in Playground 2.0 so that you can use them to build similar applications.

**The documentation has been updated.** Please feel free to check out the pages for [Playground](https://cube.dev/docs/product/workspace/playground) and [Chart Prototyping](https://cube.dev/docs/product/workspace/vizard) to familiarize yourself with the new interface and features.

**Once you've given the new Playground and Chart Prototyping a try, please share your feedback in the [Slack community](https://slack.cube.dev).** We'd like to learn more about your experience and how we can further improve it.

Powerful updates for data modeling and embedded analytics development

Introducing Playground 2.0 and Chart Prototyping in Cube Core

Among numerous [data visualization tools](https://cube.dev/docs/product/configuration/visualization-tools) supported by Cube Cloud, spreadsheets have always been regarded as one of the most important categories. Arguably, business users and data analysts use spreadsheets at least as much as standalone BI tools, if not more. In July, we announced the [native support of Microsoft Excel](https://cube.dev/blog/announcing-the-native-mdx-api-and-excel-integration-for-cube-cloud) via the MDX API, and it's only natural to see the supoort for spreadsheets expanding.

**Today, we're happy to present Cube Cloud for Sheets, the official Cube Cloud add-on for Google Sheets, the other most popular spreadsheet on the market.** Google Sheets integration comes in public preview and supports building reports in Google Sheets based on metrics defined in your semantic layer in Cube Cloud. Now you can use Google Sheets as your main data exploration tool or employ it alongside an existing BI tool to enrich the data experience of your business users.

Watch the following video to see Cube Cloud for Sheets in action:

<div><div style={{position: 'relative', paddingTop: '56.25%'}}><iframe src="https://www.youtube.com/embed/qPp9hroqd4g" style={{position: 'absolute', top: 0, left: 0, width: '100%', height: '100%'}} frameBorder="0" allowFullScreen></iframe></div></div>

We're excited to bring semantic layer connectivity to Google Sheets and even more excited to provide a familiar pivot table user interface where you can easily drag-and-drop metrics, columns, rows, and filters. See the [documentation](https://cube.dev/docs/product/apis-integrations/google-sheets) to learn more.

![](https://ucarecdn.com/0fd83ba8-5612-4634-ab13-34fcd7a660c5/)

**Google Sheets integration is available to Cube Cloud users on [Premium and above](https://cube.dev/pricing) plans.** First, install the Cube Cloud for Sheets add-on from the [Google Workspace Marketplace](https://workspace.google.com/marketplace/app/cube_cloud_for_sheets/641460343379 "Install the Google Sheets Add-on"). Then, proceed to connect it to your semantic layer in Cube Cloud.

Google Sheets integration currently comes in preview. We look forward to hearing your feedback and making Cube Cloud uniquely suited for solving your toughest data challenges.


Previewing the official Cube Cloud add-on for Google Sheets

How to connect Google Sheets to your metrics in Cube Cloud

Today, Cube is announcing the public preview of our latest API endpoint: MDX. MDX (MultiDimensional eXpression) is a query language designed to retrieve data from multidimensional OLAP cube technologies. MDX was pioneered by Microsoft in the 1990s and has proven to be a remarkably durable language, seeing broad adoption by OLAP cube vendors and downstream analytics applications. 

Conceptually, MDX is related to the SQL language in that they are both query languages, but they differ in their usage. Where SQL is oriented towards querying relational database management systems, MDX is oriented towards querying multidimensional cubes and retrieving aggregate measure values. 

A traditional spreadsheet view is an easy to understand example of a two-dimensional cube representation. In this case a measure is aggregated by dimensions as rows and columns. As a quick example, think about a SUM of Sales measure in each cell of a spreadsheet with region on the rows, and a time dimension, perhaps each month of a transaction date, along the columns.

Multidimensional cubes are interesting in that they can represent data in more dimensions than two. Imagine our prior example, but let us add an additional dimension for a product category. This becomes difficult to visualize, of course, but it is useful in many analytical contexts. 

![](https://ucarecdn.com/7b42b250-b9a1-4a12-b794-8e8fe6efacb3/-/quality/smart/-/format/auto/)

Multidimensional analysis is frequently seen in areas such as scenario planning, supply chain optimization, logistics and various financial processes. It is such a common need in finance departments, that cubes have become nearly synonymous with financial planning and analysis (FP&A) functions within enterprises. Excel is, by a wide margin, the most commonly used front-end application for users performing this type of analysis. The common pivot table within Excel is a great example of how many users experience multidimensional analysis.

## The challenge of migrating 

A major problem that we have observed here at Cube is that while these OLAP cube technologies provide a powerful analysis capability, they are tied to relational database technologies such as SQL Server, Oracle, or SAP HANA. The three most common cube technologies are tied directly to these relational databases as sources. The challenge arises when enterprises undertake migrating their data warehouse to modern cloud data warehouse or lakehouse platforms. Users then lose this baseline capability they had before to perform this type of analysis on modeled, secured, and well governed data because these modern data platforms don’t natively speak MDX as a language. Without this capability, Excel cannot perform this type of analysis in a direct connection, instead forcing users to deal with exported snapshots of data

![](https://ucarecdn.com/4341a025-c212-4db1-b0ae-20d59eda3afb/-/quality/smart/-/format/auto/)

## Ensuring direct connection to Excel

With the [new MDX endpoint](https://cube.dev/blog/how-to-directly-query-large-datasets-with-excel), Cube can effectively restore the direct connection to Excel capability that was lost, or impaired by customers who have migrated to more modern cloud data warehouse or lakehouse technologies. Cube will act as the OLAP engine in the place of technologies like SQL Server Analysis Services, Oracle Essbase, SAP HANA, and others that maintain multidimensional data models and aggregated measures. Users will simply point their MDX-speaking tools, such as Excel, at the new endpoint within Cube Cloud.

However, we are not simply replacing direct connectivity to Excel. We are also modernizing multidimensional analysis by improving it in several ways. With our pre-aggregation and caching capabilities in Cube Store we can meet and exceed the performance characteristics of older OLAP cube technologies. With our code based data modeling experience we can bring these multidimensional models into a modern data engineering work flow including version control and code review. With our advanced query rewrite capabilities, we enable Excel, and other applications that speak MDX, to query our long list of data sources live, if users choose to not use our pre-aggregations. 

We are also now the first technology to enable querying of the same data models transparently via REST, GraphQL, SQL and now MDX API endpoints. These APIs are all secured and governed in a unified security model, share a unified caching technology, and share unified performance profiling and query history capabilities. 

MDX as a supported language and API endpoint is a logical extension of Cube. In fact, we were so inspired by the concept of the multidimensional cube that it influenced the name of the open source project, and the company many years ago. We have been testing MDX heavily within Cube, and we have several customers who are using it and have provided invaluable feedback. If you would like to be a part of the public preview for this feature, please contact your Cube Cloud account team or [reach out to us via our contact form](https://cube.dev/contact?utm_source=blog&utm_content=MDX%20API%20Announcement). 

We look forward to hearing your feedback and continuing to work with you to solve your toughest analytics challenges.

Direct connectivity to Excel via a semantic layer modernizes legacy data stacks and improves data users capabilities 

Announcing the native MDX API and Excel integration for Cube Cloud

In my role at Cube I have the wonderful opportunity to interact with our technology partners every day and learn how they see the data analytics world. Most of the job is really working out how you can tell a story to yourself, the rest of your team, and the whole world about how you and your partners’ softwares are better together and how you can solve problems for customers. It’s helpful, of course, if you and your partner see the world in a similar way. The tough bit is when you don’t! In the case of working with Klipfolio, it’s quite easy actually, because we agree on an important item - the power of metrics in analytics.

We both believe that fundamentally, most end users of analytics want answers to questions, not to explore an unrestricted space and build a new dashboard from a blank page. Metrics are the answer to this problem. Metrics help us apply meaning to the data in our data warehouses, relational databases and other source systems by encapsulating verified business logic as well as dimensions that our users might filter or slice the data by. Governing metrics with a semantic layer is a powerful way for companies to guide users towards answering their questions without recreating business logic over and over.

Today, I’m happy to announce that Cube has a fully supported integration with <a href="https://www.klipfolio.com/powermetrics" target="_blank" rel="noopener">Klipfolio PowerMetrics</a>, a complementary metrics platform that works alongside existing BI and analytics tools to provide a solution designed for non-technical business users. The Klipfolio team have been pioneers of the metrics revolution in analytics for some time now. In many ways, Cube support within PowerMetrics is a natural fit. The combination of Cube and PowerMetrics allows users to unify, govern and optimize their metrics with all of the capabilities of the Cube semantic layer, but also to open the aperture of users who can self-serve and engage with analytics without requiring assistance from analytics engineers, or BI developers. 

![Klipfolio Power Metirc on Cube](https://ucarecdn.com/359eecac-2fc4-4d3c-9028-87ba20b5eb99/-/preview/934x999/)

When using both Cube and PowerMetrics, users can connect to all of the standard data sources within Cube and build their data models - including dimensions, measures and metrics as normal. Users can then browse the metrics catalog within PowerMetrics and interact and visualize the metrics from Cube, alongside other metrics defined in the other patterns supported by PowerMetrics. Metrics provided by Cube can be accelerated by our caching and optional query acceleration features to improve dashboard performance. PowerMetrics provides an intuitive, easy to navigate experience that any business user can quickly pick up and use to answer their questions about the metrics they are responsible for. Documentation for this integration has been provided in the usual [location.](https://cube.dev/docs/product/configuration/visualization-tools/klipfolio)

To learn more about our partnership with Klipfolio, and the integration between Cube and PowerMetrics, check out our [joint webinar](https://www.klipfolio.com/resources/webinars/metrics-ready) on June 18th here. You can also check out the blog posted by the Klipfolio team with more information [here](https://www.klipfolio.com/blog/data-warehouse-cube-integrations).

If you would like to take this integration for a spin, please [reach out](https://cube.dev/contact) to the Cube team and we will help get you started. 

Announcing Support for Klipfolio PowerMetrics 

Early in my career I spent a lot of time in a consultancy focusing on delivering business intelligence solutions for customers. This was a period with a lot of change in the BI market (early 2010s for those at home) and while tools were becoming much more capable and much easier for users to self-serve, not everything was great. 

These tools frequently made content discovery and reuse difficult, leading to proliferation of orphaned and unmaintained dashboards. They also tended to lock up business logic inside of proprietary file formats that couldn’t be subjected to normal version control systems. Running a quick diff to figure out what had changed between versions was impossible. Solving this sprawl of business logic, or semantics, between different versions of dashboards within a [Business Intelligence platform (BI)](https://cube.dev/blog/business-intelligence-with-universal-semantic-layer), multiplied by the fact that many organizations have several BI platforms is one of the main challenges Cube was built to solve.

But, what about the other part of this situation? How about the problem of BI dashboards with proprietary binary formats that can’t be version controlled? Well, for that you probably want a tool that operates with a 
BI-as-code model. It’d sure be great if it had excellent developer resources with guides on how to perform code reviews with integration of git-based workflows. Even better if it had support for a CLI and continuous integration patterns.

Forgive me taking forever to get to the point, but if you’ve encountered these challenges with BI tools, you should check out our newest technology integration - [Hashboard](https://hashboard.com/), for your business intelligence needs. As someone who came to BI all those years ago from a developer background, I am super excited about this partnership!

![Hashboard and Cube](https://ucarecdn.com/38ba20ed-5f04-4fae-8358-44863e03ec8c/-/preview/1000x341/)

Hashboard is now compatible with Cube Cloud as a data source and the two products integrate together well. Pairing a [semantic layer](https://cube.dev/use-cases/semantic-layer) with Hashboard is a natural fit. We share many common ideas about managing analytics at scale, such as the power of metrics and the importance of analytics objects being code that is easy to version control and reason about.

Hashboard is delivered as a cloud service with a generous free trial sign up. If you want to take it for a spin, create a free account and connect to Cube via the SQL-API. You can find detailed steps in our documentation. 

Teams can work together and define their key business metrics at an organizational level inside of Cube using our code-based data modeling, ensuring metric consistency across Hashboard and outside tools. These governed models and metrics are then easily explorable and understandable within Hashboards beautiful and smart visualization experience which provides sensible defaults and robust data profiling capabilities. These features help users more quickly orient themselves and get the answers they need. This also helps to prevent the dreaded “blank page” problem that users face in more overwhelming visualization interfaces. Hashboards' opinionated approach to dashboarding helps you get to answers faster, while keeping things looking great and adhering to visualization best practices.

![Hasboard and Cube integration](https://ucarecdn.com/a4bddb11-c192-4519-9f84-6a6df19a9206/-/preview/1000x693/)

If you want to learn more about how Hashboard and Cube join forces as a modern, developer-friendly analytics stack, check out our webinar featuring Carlos Aguilar of Hashboard: [Build an Explorable and Accessible Semantic Layer with Cube and Hashboard](https://cube.dev/events/build-an-explorable-and-accessible-semantic-layer-with-cube-and-hashboard). You can also reach out to me in any of the usual places, or contact your account executive at Cube.


BI & Data Exploration

Announcing Support for Hashboard in Cube

Modern Business Intelligence (BI) platforms have served as the backbone of data analytics for decades. Today, every organization strives to enable informed business decisions by making data available to more people. As data grows in volume and variety, these platforms and the teams who support and use them face significant hurdles to organize, manage, and access data consistently.

While modern platforms have been instrumental in data democratization by prioritizing self-service and ease-of-use, they often fall short of handling the complexity of today’s modern data stack. From cloud data warehouses and cloud-native enterprise applications to acquiring the right data and the joins, relationships, and calculations to correctly define a data model, there’s still too much guesswork for data analysts and business users who are seeking insights. 

In addition, people must navigate the proliferation of duplicate dashboards and datasets, fragmented business logic, and inconsistent calculation of key metrics—all eroding trust in the data. Perhaps, this is one of the reasons why BI penetration averages only 25-35% of the workforce according to various research statistics, despite their leadership’s goal of becoming more data-driven. 

## The Power of a Universal Semantic Layer
When surveyed in <a href="https://www.accenture.com/us-en/insights/technology/technology-trends-2023" target="_blank" rel="noopener">Accenture’s Technology Vision 2023</a> report, 95% of global executives agreed on the necessity of new data architectures and strategies to effectively manage significant changes in their organizations’ data environments. One of the technologies named in this report is a semantic layer.

At Cube, we believe the [universal semantic layer](https://cube.dev/use-cases/semantic-layer) is one of those pivotal changes that companies will need to make to address today’s challenges and leverage new opportunities of the rapidly evolving modern data stack. When your modern BI platforms connect to a universal semantic layer instead of a direct database connection, you are able to support each one with a common data model, including dimensions, measures, and calculations.

To level set, a universal semantic layer is an independent yet interoperable part of the modern data stack that sits between your data sources and data consumers. The universal semantic layer allows every data endpoint, whether it is [BI tools](https://cube.dev/use-cases/connected-bi), [embedded analytics](https://cube.dev/use-cases/embedded-analytics), or [AI agents](https://cube.dev/use-cases/llm-and-ai-semantic-layer) and chatbots, to work with the same semantics and underlying data, leading to consistent and trusted insights. 

## Taking Modern BI to the Next Level with Cube’s Universal Semantic Layer
Without a universal semantic layer, business logic and data models are scattered between the data source and the data consumer. There is business logic in your cloud data warehouse and your transformations. Data models are embedded in the content of every modern analytics platform. When an update to the data model is required, the only option is tedious searching, copying, and pasting of platform-specific formulas and business logic. Then, add to that a little bit of hope that you updated every occurrence.

![](https://ucarecdn.com/136f1efc-feca-41f9-b7b3-89313546ea03/-/quality/smart/-/format/auto/)

With a universal semantic layer, you can model your data once and deliver it anywhere. Regardless of the modern BI platform, people can connect to the same data and business definitions. This means that you could have <a href="https://www.microsoft.com/en-us/power-platform/products/power-bi" target="_blank" rel="noopener">Power BI</a> and <a href="http://tableau.com" target="_blank" rel="noopener">Tableau</a> (and even spreadsheets) connect to a single data model that translates queries to the underlying data, creating a new level of consistency without the need to update embedded logic within BI platforms or files. 

![](https://ucarecdn.com/eee2f7f0-c9b5-4c66-9d8f-197b3293f87b/-/quality/smart/-/format/auto/)

## Integrating Cube Cloud with Modern BI Platforms
As a fully-managed service, Cube takes care of infrastructure management, deployment, and scaling of Cube Cloud, allowing your team to focus on their core data engineering responsibilities. It’s easy to start and transition your models over time without a large upfront investment, while delivering trusted data to your organization with the universal semantic layer.

Begin by taking inventory of data connections within your modern analytics platforms and cloud data warehouse. Then, identify the most popular or slowest content and queries, depending on capabilities you want to test. 

Once you’ve identified the appropriate tables, [build the data model](https://cube.dev/docs/product/data-modeling/concepts) by making a connection to your cloud data warehouse. Cube Cloud can read your database schema, including primary and foreign keys, to generate cube files in YAML or JavaScript. Cubes serve as the building blocks for views that will be exposed to the modern BI platforms. 

Using the data model defined, you can now connect to Cube Cloud from your BI platform using the [SQL API](https://cube.dev/docs/product/apis-integrations/sql-api). The SQL API enables Cube to deliver trusted data over the <a href="https://www.postgresql.org/docs/current/protocol.html" target="_blank" rel="noopener">Postgres-compatible protocol</a>. With each interaction, Cube Cloud will translate the query from the client to the cloud data warehouse and return results. You might also add [security context](https://cube.dev/docs/product/auth/context) and query rewrite for [row-level](https://cube.dev/docs/product/apis-integrations/sql-api/security#security-context-row-level-security) or [column-level](https://cube.dev/docs/guides/recipes/access-control/column-based-access) security to centralize governance policies.

In both development and production, you’ll have [real-time performance insights](https://cube.dev/docs/product/workspace/performance) to inspect the query lifecycle, view resource utilization, and identify new optimization opportunities. These optimizations can include improved performance and more cost-efficient cloud resource utilization. Cube Cloud can reduce cloud data usage costs from redundant queries with in-memory caching, queue management, and configurable pre-aggregation caching in Cube Store.

Finally, setup [Semantic Layer Sync](https://cube.dev/blog/introducing-semantic-layer-sync) to push Cube Cloud data models out to the target systems. Semantic Layer Sync automatically synchronizes the data model from the universal semantic layer to Bl platforms, making Cube-specific entities, such as cubes and views, match BI-specific ones, such as datasets, tables, dimensions, and measures.

## Delivering More Trust and Value from Your Data with Cube Cloud
Cube Cloud’s compatibility with popular BI platforms will ensure a seamless transition to a better way of organizing and managing data used for analytics. By adding Cube Cloud’s universal semantic layer to your modern data stack, you can truly unlock the value of your data for more people:

- **Improved Data Availability**: Provide a single, unified interface for modeled data from your cloud data warehouse to every modern BI platform in your organization.
- **Consistent Business Definitions**: Define metrics and dimensions once and use them consistently across all modern BI platforms and spreadsheets, reducing errors and discrepancies.
- **Governed Data Access**: Streamline access to trusted data with centralized and enforced governance and security policies to promote more confident decisions. 
- **Faster, More Cost-Effective Performance**: Accelerate query performance through caching to ensure your analytics are as fast as they are accurate–often without querying the database directly.

For organizations looking to take their analytics programs to the next level, exploring Cube’s unified semantic layer is a step towards building context, consistency, and trust into every BI connection. By enhancing your modern BI platform with Cube, you can enable more informed decisions, faster and with greater confidence. Discover how Cube can transform your modern data stack by signing-up for a [free developer account](https://cubecloud.dev/auth/signup) today.


Rethinking Modern Business Intelligence with a Universal Semantic Layer

In order to [expand our support](https://cube.dev/blog/cube-supports-microsoft-data-and-analytics) for the Microsoft ecosystem of data and analytics tools, we focused on all aspects of integrations: from using Azure for hosting Cube Cloud deployments to Entra ID for identity management, Fabric for data warehousing upstream of Cube, and Power BI for data consumption by end users.

Regardless of how deep you're invested in the Microsoft ecosystem and [how many Azure services](https://cube.dev/docs/product/deployment/cloud/providers/azure) you use, Cube Cloud would blend right in to centralize the management and performance of your data analytics.

![Cube Cloud and Microsoft Ecosystem](https://ucarecdn.com/274466a0-3bb5-4b06-9f00-4027ccbb45b9/-/preview/1000x691/)

Among other integrations, Fabric and Power BI are the most impactful ones, enabling data engineers, data analysts, and business users to work with data in a way that is native to the Microsoft ecosystem of tools.

With dozens of existing integrations with [data sources](https://cube.dev/docs/product/configuration/data-sources) and [data exploration](https://cube.dev/docs/product/configuration/visualization-tools) applications, Cube arguably provides the best support for tools both upstream and downstream of its semantic layer. Now, if your data is processed in SQL Server or Synapse and/or if your users spend hours in Power BI or other applications, Cube will provide unified metrics definitions and access control for them.

**Most importantly, Power BI integration is enabled by Semantic Layer Sync,** which streamlines business intelligence tool connectivity beyond what is possible with [SQL, REST, and GraphQL APIs](https://cube.dev/docs/product/apis-integrations) that Cube provides. With Semantic Layer Sync, you can instantly take a PBIT file from Cube Cloud, import it in Power BI, and start building reports; no other configuration requred.

See how Semantic Layer Sync with Power BI works on this video:

<div><div style={{position: 'relative', paddingTop: '56.25%'}}><iframe src="https://www.youtube.com/embed/HKRlZXrTB4A" style={{position: 'absolute', top: 0, left: 0, width: '100%', height: '100%'}} frameBorder="0" allowFullScreen></iframe></div></div>

As you can see, Cube processes DirectQuery requests from Power BI and seamlessly translates them into SQL queries against upstream data sources, e.g., Microsoft Fabric, SQL Server or any other [supported data source](https://cube.dev/docs/product/configuration/data-sources), accounting for the data model definitions and access control rules in place:

```sql
SELECT
  TOP 1002 "pick_up_geography".City "trips__pick_up_city",
  ROUND(
    sum("trip".TipAmount) / NULLIF(sum("trip".TotalAmount), 0) * 100,
    1
  ) "trips__tip_percent"
FROM
  dbo.Trip AS "trip"
  LEFT JOIN dbo.Geography AS "pick_up_geography"
    ON "trip".PickupGeographyID = "pick_up_geography".GeographyID
WHERE
  ("pick_up_geography".Country = 'United States')
GROUP BY
  "pick_up_geography".City
HAVING
  (
    ROUND(
      sum("trip".TipAmount) / NULLIF(sum("trip".TotalAmount), 0) * 100,
      1
    ) IS NOT NULL
  )
ORDER BY
  2 DESC,
  1 ASC
```

**Semantic Layer Sync with Power BI is available in Cube Cloud on [Enterprise tier](https://cube.dev/pricing).** Please [get in touch](http://cube.dev/contact) if you'd like to see how it works for your use case.

You can also check the [documentation](https://cube.dev/docs/product/workspace/semantic-layer-sync/power-bi) to learn more about accessing and configuring this feature. Join our [Slack community](https://slack.cube.dev) to share your thoughts and opinions about this update.

Connect your semantic layer to the most popular BI, effortlessly

Introducing Semantic Layer Sync with Power BI

Here at Cube, we have been hard at work, deepening our support for the Microsoft ecosystem of data and analytics tools as part of our commitment to empowering developers to choose the tools they prefer on any platform they prefer. Microsoft offers an expansive set of tools that enterprises trust to power their operations, and Cube supports an ever-increasing list of these technologies. From cloud infrastructure in Microsoft Azure, to data warehousing capabilities in SQL Server and Synapse product lines, and finally, visualization with the popular Power BI product - [Cube supports Microsoft technologies](https://cube-docs-prod-lw3cf595y-cube-dev.vercel.app/product/deployment/cloud/providers/azure). However, there is always more that we can build, and today I am proud to highlight some of our recent work.

In speaking with our customers about how to better support their business intelligence initiatives, improved support for Microsoft Power BI is a common request. We have listened to your feedback and made wide-ranging improvements to our support for Power BI by improving our SQL-API. The Cube SQL-API is the heart of our ability to translate requests via SQL from most business intelligence tools into Cube’s internal query representation and then either answer those queries from cache, pre-aggregation, or proxy back to any of our data sources. We have dramatically expanded our coverage of possible types of queries that Power BI can issue to the SQL-API and will continue this work to ensure that [Power BI works as users would expect when connected to Cube data sources](https://cube.dev/docs/product/configuration/visualization-tools/powerbi). Power BI users can gain benefits of improved dashboard performance when connected to Cube accelerated sources. At the same time, data teams can reduce the complexity of managing data and improve consistency by defining data models once in a [Cube semantic layer](https://cube.dev/use-cases/semantic-layer) and reusing them across many Power BI dashboards and other visualization tools in mixed environments.

> “We constantly invest in new functionality that improves the customer experience. Cube has allowed us to do it quickly and at significant cost savings,” said Todd Vaccaro, Product Manager at SecurityScorecard. “We’re now extending our use of the Cube platform to internal users who want actionable information. As Power BI users, we appreciate Cube’s support of Microsoft tools so we can rely on Power BI for the visualization layer while holding Cube as the underlying unifying semantic layer to manage all our data experiences in one place.”

We are happy to announce that our [Semantic Layer Sync functionality for Power BI](https://cube.dev/use-cases/connected-bi) is available in Cube Cloud on the Enterprise tier; please [contact sales to get a demo and learn more](https://cube.dev/contact). We look forward to more user feedback. 

### Support for Microsoft Fabric

Fabric, the new flagship analytics platform from Microsoft, is now supported by Cube Cloud as a data source. With this integration, you can now create a data source connection to a Microsoft Fabric Data Warehouse or Lakehouse SQL Analytics endpoint and take advantage of all of the usual Cube Cloud functionality, such as our code-based data modeling and metrics definition experience, optional aggregate aware pre-aggregation and two-tiered caching, and our robust selection of API endpoints including SQL, GraphQL and REST. By combining Cube Cloud with Microsoft Fabric, users can easily connect this platform to any downstream visualization tool that supports Cube. To learn more, check out our [Cube and Microsoft Fabric documentation here](https://cube.dev/docs/product/configuration/data-sources/ms-fabric).

> “With Cube’s semantic layer, we were able to improve and streamline our analytics offering for customers in just two weeks,” said Dhyan Shah, Sr Product Manager at RamSoft. “Now, with Cube support for Microsoft Fabric, we are well equipped to support our users with greater flexibility. The Cube platform is customizable and comprehensive — and now, even more compatible with our existing data stack.”

_Cube Cloud seamlessly integrates with the Microsoft data and analytics ecosystem, providing a universal semantic layer to manage all your metrics, definitions, and access in one place._

![cube and microsoft](https://ucarecdn.com/274466a0-3bb5-4b06-9f00-4027ccbb45b9/-/preview/1000x691/)

### Support for Microsoft Entra ID
[Microsoft Entra ID](https://www.microsoft.com/en-us/security/business/identity-access/microsoft-entra-id), the cloud-based identity and access management solution formerly known as Azure Active Directory, is now supported by Cube Cloud. Enterprises using Cube Cloud can now offer their users a single sign-on experience utilizing their existing Entra ID identity provider, helping to streamline IT operations and improve roll-out times for semantic layer initiatives. Powerful, fine-grained access control schemes, including row-level and column-level security are made simple to implement with this integration. Enabling systems administrators to reuse existing security permissions from Microsoft Entra ID keeps things consistent and reduces the likelihood of misconfiguration.

Documentation for enabling SAML and [configuring Microsoft Entra ID as an IdP in Cube can be found here](https://cube.dev/docs/product/workspace/sso/microsoft-entra-id).

### Support for Microsoft VNet Peering and Azure PrivateLink
Additionally, Cube Cloud now supports an expanded set of virtual network connectivity capabilities on Microsoft Azure, including VNet Peering and Azure PrivateLink. These features will help our customers maintain the security and privacy of their data in the cloud. These features will help our customers maintain the security and privacy of their data in the cloud. Documentation is [available](https://cube.dev/docs/product/deployment/cloud/vpc/azure). 

### Cube Now Available on the Microsoft Azure Marketplace!
As a software-as-a-service offering, Cube Cloud has provided users the capability to deploy on Microsoft Azure for a while now and we have seen strong adoption of this choice. I’m pleased to announce that [Cube Cloud is now publicly available for purchase on the Microsoft Azure Marketplace](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/cubedevinc1695837022471.cube-cloud). The benefits to buyers of transacting via cloud marketplaces are well known, but in short, this will provide more flexibility to our customers and allow them to procure software in whichever way works the best for them. Cube Cloud, deployed on Microsoft Azure, can be purchased directly from Cube, or via the Azure Marketplace. Same great software, support and functionality, but more options for buyers.

### Support for Direct Query in Microsoft Excel 
With the [MDX API](https://cube.dev/docs/product/apis-integrations/mdx-api "MDX API docs") in Cube Cloud, users can directly query their data with Microsoft Excel. Cube Cloud can replace the traditional OLAP cube technologies that enterprises may have lost access to if they’ve migrated their relational database technologies such as SQL Server, Oracle, or SAP HANA to more modern cloud data platforms such as Snowflake, or Databricks. In many situations after a cloud migration, users lose this baseline capability they had before to perform [multidimensional analysis](https://cube.dev/use-cases/modern-cloud-olap "Modern Cloud OLAP Use Case") on modeled, secured, and well governed data because these modern data platforms don’t natively speak [MDX](https://learn.microsoft.com/en-us/analysis-services/multidimensional-models/mdx/querying-multidimensional-data-with-mdx?view=asallproducts-allversions "Querying Multidimensional Data with MDX ") as a language. Without this capability, Excel cannot perform this type of analysis in a direct connection, instead forcing users to deal with exported snapshots of data.

MDX allows Cube to act as the OLAP engine in the place of technologies like SQL Server Analysis Services, Oracle Essbase, SAP HANA, and others that maintain multidimensional data models and aggregated measures. Users point their Excel connection to Cube Cloud and enjoy all of the functionality they are used to.

However, we are not simply replacing direct connectivity to Excel. We are also modernizing multidimensional analysis by improving it in several ways. With our [pre-aggregation and caching](https://cube.dev/product/caching-and-data-performance "Caching and Data Performance") capabilities in Cube Store we can meet and exceed the performance characteristics of older OLAP cube technologies. With our code based [data modeling](https://cube.dev/product/data-modeling "Data Modeling") experience we can bring these multidimensional models into a modern data engineering work flow including version control and code review. With our advanced [data access controls](https://cube.dev/product/data-access-control "Data Access Controls"), such as query rewrite capabilities, we enable Excel to query our long list of data sources live, if users choose to not use our pre-aggregations.

We look forward to getting these new features in the hands of our customers and continuing our journey as a committed Microsoft technology partner. If you are interested in learning more about the features mentioned above, [please reach out](https://cube.dev/contact) and tell us how we can help you solve your data challenges.


Cube Now Supports Multiple Products Within the Microsoft Data and Analytics Ecosystem

Today I am excited to announce that Cube is partnering with [Push.ai](https://www.push.ai) to help teams deliver more automated, personalized analytics experiences using the metrics that drive their business. Using Push.ai’s Business Graph technology, companies can develop a complete model of their business, defining the metrics that matter, which teams are accountable to what results, and the goals that the business is working to achieve.  Push.ai then applies its AI and Machine Learning capabilities to help teams stay up-to-date with what’s happening, “why?” and proactively identify the actions that drive businesses towards their goals.

![push.ai and cube](https://ucarecdn.com/78070253-4f7d-45ad-8206-58b635f46350/-/quality/smart/-/format/auto/)

### Understand the relationships of metrics with automated AI insights

To use Push.ai and Cube together, a user simply defines their [data model](https://cube.dev/product/data-modeling) within Cube Cloud and connects it to Push.ai via our REST API, following this Cube [documentation](https://cube.dev/docs/product/configuration/visualization-tools/push-ai). Once connected, users will be able to see their dimensions, measures and metrics within Push.ai and connect to any of the myriad data sources that Cube supports. Push.ai users will be able to take advantage of all of the best-in-class [semantic layer](https://cube.dev/use-cases/semantic-layer) features that Cube provides, such as our code-based data modeling experience and our Cube Store caching.

Cube Cloud users who implement Push.ai will benefit from a next-generation solution to run their business. Rather than defining calculations in a business intelligence tool and building dashboards to produce insights, once configured, Push.ai will automatically keep teams up-to-date with the progress of tracked metrics vs goals and suggest opportunities that bridge the gap. These updates can be pushed directly to individuals and groups in Slack, Microsoft Teams, and Email destinations. And, teams can benefit from more personalized analytics experiences by allowing individuals to subscribe to the areas of the business that matter to them. 

![Proactive Analytics](https://ucarecdn.com/ad8503c5-c04a-48ff-ae9c-9c5494b415d2/-/quality/smart/-/format/auto/) 

Push.ai is a great solution for teams who want to keep focused on their most important metrics and deliver proactive intelligence right to the places where their teams already work - chat and email. This approach differs from standard business intelligence tools which depend more heavily on users understanding dashboarding tools, knowing which dashboards exist, and which ones to trust. Here at Cube we have enjoyed working with the Push.ai team to bring this integration to life and we look forward to seeing where this partnership takes us.

To learn more about Push.ai and their Business Graph technology, you can check them out at [https://www.push.ai/](https://www.push.ai/). You can also attend our [joint webinar](https://cube.dev/events/unlock-proactive-intelligence-using-cube-push-ai) with the Push.ai team on Wednesday, February 14th at 9am PST. 


The Cube x Push.ai Integration

Personalized and Proactive Analytics with Cube and Push.ai

At Cube, we deeply care about the experience that data professionals have when building and evolving semantic layers. We also enjoy taking the best of both worlds: with Cube being a [code-first](https://cube.dev/docs/product/introduction#code-first) semantic layer that manages its data model and configuration through code, we strive to provide UI-rich tooling in Cube Cloud.

**Today, we're excited to announce Playground 2.0,** which is the biggest update ever to the toolset for building and debugging data models in Cube Cloud. We have completely rebuilt Playground to provide data engineers with familiar BI-like experience, extended support for the data modeling workflow, and convenient UI.

Watch the following video to see Playground 2.0 in action:

<div><div style={{position: 'relative', paddingTop: '56.25%'}}><iframe src="https://www.youtube.com/embed/oxRa6btpml0" style={{position: 'absolute', top: 0, left: 0, width: '100%', height: '100%'}} frameBorder="0" allowFullScreen></iframe></div></div>

Also, read more for a complete breakdown of Playground 2.0 features.

## What's new in Playground 2.0

**BI-like experience.** Acknowledging countless hours that data practitioners have spent in our Playground over the last four years, we also admit that many Cube users have prior experience with data exploration tools and BI tools in particular. Taking inspiration from well-known and emerging tools, ranging from [Looker](https://cloud.google.com/looker/) to [Lightdash](https://www.lightdash.com), we've redesigned Playground from scratch to streamline your data modeling workflow.

![](https://ucarecdn.com/effe2bce-99e6-4ba0-9887-0f7ea5654e40/)

Now, when you enter the [development mode](https://cube.dev/docs/product/workspace/dev-mode) and introduce a new cube, view, measure, or dimension, you're just seconds away from locating them in the intuitively-placed side pane and using them in a query. Of course, you can also go to the command line and query the semantic layer via an API; however, unlike other semantic layer vendors, we don't limit you to command-line interface as the only option to test and verify your data modeling decisions. Playground 2.0 is here to help.

**Rich representation of the data model.** Playground 2.0 takes a step further in providing a detailed representation of the data model in your semantic layer. [Cubes](https://cube.dev/docs/reference/data-model/cube) and [views](https://cube.dev/docs/reference/data-model/view), forming separate layers in the data model, reside on separate top-level tabs. Dimensions and measures feature familiar data type icons as well as clear annotations for [primary key](https://cube.dev/docs/reference/data-model/dimensions#primary_key) dimensions, [non-public](https://cube.dev/docs/reference/data-model/cube#public) members, and members with custom [descriptions](https://cube.dev/docs/reference/data-model/dimensions#description) in the data model.

![](https://ucarecdn.com/6905c5ae-849c-4126-a1b5-55ff17611550/)

**Everything you liked and then some.** We've packed Playground 2.0 with new features like global data model search with highlighting, an option to paste a JSON query you've obtained elsewhere, or conveniently placed UI elements to help you apply filters to the result set. Of course, we've kept the rest of Playground features such as data visualization with various chart types and pivoting, Rollup Designer for adding pre-aggregations, and security context selector (now placed more logically at the very top).

![](https://ucarecdn.com/67b9fa16-7dce-4ca5-917f-ef530052e0b9/)

There's also a feature that is pending to be added to Playground 2.0. As part of our support for the [embedded analytics](https://cube.dev/use-cases/embedded-analytics) use case, we're currently working on the charting code generation feature that we'll add to Playground in the upcoming weeks. (For now, you can use a similar feature in Playground 1.0.)

## Try Playground 2.0 today

**Playground 2.0 is available to all Cube Cloud users on all plans.** Just log into your Cube Cloud account or [create a new one](https://cubecloud.dev/auth/signup) and proceed to Playground.

> Even if you aren't a Cube Cloud user or you're not yet ready to connect your production data source, you can get started in seconds by creating a [demo deployment](https://cube.dev/blog/introducing-demo-deployments-in-cube-cloud) that provides a pre-configured data model and a demo dataset.

We know that Playground is a very frequently used feature, so, for now, we're keeping both Playground 2.0 and 1.0 available in Cube Cloud; you can switch between them if that suits your workflow better. After a short transitional period, we'll be sunsetting Playground 1.0.

Please share your feedback and feature requests related to Playground via our [Slack community](https://slack.cube.dev), in-product chat, and your dedicated customer success managers. We'll make sure to turn it into further improvements to Playground.

**We also plan to move Playground 2.0 to Cube Core and make it open source** as soon as the transitional period in Cube Cloud ends. We take data modeling experience in Cure Core very seriously and we'd like everyone in the Cube community to have and use great tooling.

## What's next?

Please stay tuned for news on Cube Cloud and Cube Core; we have plenty of new features and updates in the making. As always, your feedback and questions are much appreciated; join our [Slack community](https://slack.cube.dev) today to share.

Powerful yet familiar UI for data modeling in the semantic layer

Introducing Playground 2.0 with BI-like experience

I am pleased to announce that integration between Cube and [Steep](https://steep.app/) is now available. 

Steep is a modern analytics platform, powered by metrics, that changes how companies use data together. Available as a desktop, web and native mobile application, Steep provides a beautiful interface for teams to explore, compare and understand the metrics that are important to their business. In Steep, users simply browse available metrics and begin their analysis rather than starting with a complicated dashboard development process.

![](https://ucarecdn.com/21d23967-89d9-4a74-bc63-ec3cd83e03eb/-/quality/smart_retina/-/format/auto/)

### Metrics-first business intelligence
At Cube we are excited to partner with Steep because of our shared belief in a better way forward for analytics users by defining metrics once and reusing them many times, in different contexts. In older business intelligence softwares, users are forced to think in the constructs of databases - tables, columns and queries. This can put a lot of burden on users without strong backgrounds in database fundamentals and can reduce adoption of analytics within organizations. With their focus on metrics as a first class entity Steep empowers more users to engage with analytics by preventing them from having to think about queries, or more likely, to wait to be served by specialist members of a data team. Defining metrics once, in a [semantic layer](https://cube.dev/use-cases/semantic-layer), keeps everyone on the same page and confident in the insights that are created. No more guessing if you’re using the same version of a dashboard as everyone else is!

### More than traditional BI
After a [semantic layer is defined](https://cube.dev/docs/product/configuration/visualization-tools/steep) in Cube, Steep connects via our REST API and all available metrics are immediately available to Steep users. Cube features like data modeling version control, two-tiered caching and pre-aggregation, and our long (and growing!) list of [data sources](https://cube.dev/docs/product/configuration/data-sources) are all available to Steep users. Cube users who add Steep to their data stack get a delightful self-service analytics experience that feels truly [made for](https://steep.app/semantic-layer) the semantic layer.

![](https://ucarecdn.com/da6c0977-210c-4ff8-a3b0-d45b853b1559/-/quality/smart_retina/-/format/auto/) 

We have a [webinar with the Steep team](https://cube.dev/events/a-new-way-to-do-bi-cube-steep) to walk through the integration and talk about the idea of [metrics-first BI](https://cube.dev/use-cases/connected-bi) on January 16th, at 8am PST. Working with the Steep team to bring this integration to the world has been a wonderful experience and I hope that you will take a look and let us know what you think.


The Cube x Steep Integration

Cube and Steep: Metrics-first business intelligence

Today, we're happy to support Looker users switching over to Cube and present `lkml2cube`, a tool for converting [LookML](https://cloud.google.com/looker/docs/reference/lookml-quick-reference) models into the Cube data model. With this tool, you can easily migrate your existing [Looker](https://cloud.google.com/looker/) projects to Cube.

## Benefits of using Cube

Cube is a code- and API-first semantic layer that enables data engineers and developers to make their data consistent, secure, performant, and accessible across every application. Cube is commonly used to implement a *semantic layer*: a middleware between your data source and your application that provides a unified view of your data, regardless of where it is stored or how it is formatted.

By migrating your LookML models to Cube, you can achieve the following:

- **Reduced development time.** Once you have migrated your LookML models to Cube, you can start using Cube's powerful features, such as its pre-built calculations, dimensions, and measures, to create your data applications. Using Cube can save you a significant amount of development time.
- **Improved data quality.** Cube's semantic layer can help you improve your data quality by performing data transformations, validations, and aggregations. Using Cube's version-controlled semantic layer definition can help you to ensure that your data is consistent, accurate, and reliable.
- **Enhanced performance.** Cube's in-memory data store can help improve your data applications' performance by caching frequently accessed data, thus providing faster user response times.
- **Increased accessibility.** Cube's API-first design easily integrates Cube into your existing data applications.

Initially, we’ve created `lkml2cube` to facilitate our work while supporting the migration of Looker users to [Cube Cloud](https://cube.dev/product/why-cube-cloud). Now, we’re happy to put it into [open source](https://github.com/cube-js/lkml2cube) to assist more Looker users in their migration over to Cube.

Given Cube’s current position as a [leader and fast-mover](https://cube.dev/blog/cube-recognized-as-a-leader-and-fast-mover-by-gigaom) among semantic layers, there’s no surprise we see more and more companies migrating to Cube from their legacy solutions:

[![](https://ucarecdn.com/d266a78b-3dcf-4355-a59d-17a15007afa1/)](https://cube.dev/gigaom-rates-cube-as-a-leader-for-semantic-layers)

Here’s how one of Cube Cloud users describe their experience:

> We recently transitioned from Looker to Cube in an effort to enhance the user experience on our data-intensive internal platform, both in terms of performance and user interface. Our aim was to seamlessly embed data and analytics into our team's workflows.
> 
> With the invaluable assistance and robust tools provided by the Cube team, we successfully migrated a significant portion of our LookML project, encompassing hundreds of views and explores, to Cube’s data modeling language in just a matter of weeks.
> 
> *Director, Data Products at an investment firm*

## Migration example

Cube’s data modeling language has a few similarities with LookML, however, it’s arguably more powerful, flexible, and fit as a data modeling language for a modern semantic layer.

* [Cubes](https://cube.dev/docs/reference/data-model/cube) represent tables of data in Cube and are roughly equivalent to [views](https://cloud.google.com/looker/docs/reference/param-view) in LookML. However, cubes are a bit more powerful since they can contain [join](https://cube.dev/docs/reference/data-model/joins) and [pre-aggregation](https://cube.dev/docs/reference/data-model/pre-aggregations) definitions—the latter are used to provide granular query acceleration configuration and inform Cube’s [aggregate awareness](https://cloud.google.com/looker/docs/aggregate_awareness).
* [Views](https://cube.dev/docs/reference/data-model/view) sit on top of the data graph of cubes and create a facade of your whole data model; they are roughly equivalent to [explores](https://cloud.google.com/looker/docs/reference/param-explore) in LookML. However, when referencing cubes, views allow to define an exact full join path and remove the ambiguity of searching the join path within the data graph. `lkml2cube` accounts for this quirk of LookML and performs a breadth-first search in the data graph to find the most suitable join relationship.

Consider a simple Looker project that is structured in the following way: 

```
.
├── my_explores.model.lkml
└── views
    ├── line_items.view.lkml
    ├── orders.view.lkml
    ├── product_categories.view.lkml
    ├── products.view.lkml
    ├── suppliers.view.lkml
    └── users.view.lkml
```

After applying `lkml2cube`, an equivalent Cube project would be structured similarly: 

```
.
└── model
    └── cubes
        ├── line_items.yml
        ├── orders.yml
        ├── product_categories.yml
        ├── products.yml
        ├── suppliers.yml
        └── users.yml
    └── views
        └── orders_view.yml
```

You can generate the Cube data model for your entire Looker project by executing a single command against the file with LookML explores. `lkml2cube` would inspect that file, follow the references in the `include`parameter, and generate necessary cubes and views:

```bash
lkml2cube views my_explores.model.lkml --outputdir model/
```

For example, the following `views/orders.view.lkml` file…

```javascript
view: orders {
  view_label: "Orders"

  sql_table_name: "public.orders" ;;

  dimension: unique_key {
    type: string
    primary_key: yes
    sql: ${TABLE}."id" ;;
  }

  dimension: status {
    type: string
    sql: ${TABLE}."status" ;;
  }

  dimension_group: created_at {
    type: time
    timeframes: [
      raw,
      time,
      date,
      week,
      month,
      quarter,
      year
    ]
    sql: ${TABLE}."created_at" ;;
  }

  measure: count {
    type: count ;;
  }

  measure: total_order_amount {
    type: sum
    sql: ${TABLE}."number" ;;
  }
```

...would be converted into the following `model/cubes/orders.yml` file:

```yaml
cubes:
  - name: orders
    sql_table: public.orders

    joins:
      - name: users
        sql: "{CUBE}.user_id = {users}.id"
        relationship: many_to_one

      - name: products
        sql: "{CUBE}.product_id = {products}.id"
        relationship: many_to_one

    dimensions:
      - name: id
        sql: "{CUBE}.id"
        type: number
        primary_key: true

      - name: status
        sql: "{CUBE}.status"
        type: string

      - name: created_at
        sql: "{CUBE}.created_at"
        type: time

    measures:
      - name: count
        type: count

      - name: total_order_amount
        sql: "{CUBE}.number"
        type: sum
```

Consequently, the following `my_explores.model.lkml` file...

```javascript
explore: orders {
  label: "Orders Summary"

  join: users {
    relationship: many_to_one
    sql_on: ${orders}.user_id = ${users}.id ;;
    type:  left_outer
  }

  join: products {
    relationship: many_to_one
    sql_on: ${orders}.product_id = ${products}.id ;;
    type:  left_outer
  }

  join: line_items {
    relationship: one_to_many
    sql_on: ${orders}.id = ${line_items}.order_id ;;
    type: left_outer
  }

  join: product_categories {
    relationship: many_to_one
    sql_on: ${products}.product_category_id = ${product_categories}.id ;;
    type: left_outer
  }

  join: suppliers {
    relationship: many_to_one
    sql_on: ${products}.supplier_id =${suppliers}.id ;;
    type: left_outer
  }
}

```

...would be converted into the following `model/views/orders_view.yml` file:

```yaml
views:
  - name: orders_view

    cubes:
      - join_path: orders
        includes: "*"

      - join_path: orders.users
        prefix: true
        includes: "*"

      - join_path: orders.products
        prefix: true
        includes: "*"

      - join_path: orders.line_items
        prefix: true
        includes: "*"

      - join_path: orders.products.product_categories
        prefix: true
        includes: "*"

      - join_path: orders.products.suppliers
        prefix: true
        includes: "*"
```

Note unambiguous join paths like `orders.products.product_categories` and `orders.products.suppliers` in the example above that `lkml2cube` was able to detect and express in the Cube data model. Over time, it would save hours, if not days, of work when building and debugging complex data models.

## Conclusion

`lkml2cube` is a powerful tool that can help you convert LookML models into Cube’s data modeling language and assist your migration from Looker to Cube. In case this tool is relevant to your data stack, please feel free to [check the documentation](https://cube.dev/docs/reference/python/lkml2cube) and give it a try.

Lastly, you're always very welcome to join our [Slack community](http://slack.cube.dev/) of more that 9,000 data practitioners and share your feedback on this update.

Paco Valdez

Looker

Supporting the transition to Cube's semantic layer from legacy solutions

Introducing a tool for Looker to Cube migration

Three months ago, we've introduced [Semantic Layer Sync](https://cube.dev/blog/introducing-semantic-layer-sync) to completely bridge the gap between the semantic layer and BI tools and enable instantaneous, zero-friction self-serve analytics. We've launched with several [supported BI tools](https://cube.dev/docs/product/workspace/semantic-layer-sync#supported-tools) and promised to gradually expand the spectrum of BI tools that work with Semantic Layer Sync.

**Today, we're delivering on that promise and introducing the Tableau support in Semantic Layer Sync.** Now you can author the data model in Cube Cloud and have it seamlessly synchronized with [Tableau Cloud](https://www.tableau.com/products/cloud-bi) or [Tableau Desktop](https://www.tableau.com/products/desktop) where you can access the data from the semantic layer to build workbooks and dashboards.

In the following demo video, you can see that it takes seconds to configure Semantic Layer Sync and surface a [view](https://cube.dev/docs/product/data-modeling/reference/view) from Cube's data model to a workbook both in Tableau Cloud and Tableau Desktop:

<video width="100%" controls><source src="https://ucarecdn.com/16a984fa-b3a2-411d-872d-184bc476f46a/video.mp4" type="video/mp4"/></video>

Over the last months, Semantic Layer Sync has proven itself as a feature that saves a lot of time for data engineers who define metrics in the semantic layer and enable self-serve analytics for their end users in BI tools. Now, it's time to integrate Semantic Layer Sync in your Tableau workflow.

**Semantic Layer Sync with Tableau is available in Cube Cloud on [Enterprise and above tiers](https://cube.dev/pricing), and [you can try it today](https://cubecloud.dev/auth/signup).** Please check the [documentation](https://cube.dev/docs/product/workspace/semantic-layer-sync#tableau) to learn more about accessing and configuring this feature. Join our Slack community at [slack.cube.dev](https://slack.cube.dev) to share your thoughts and opinions about this update.

If you'd like to see Semantic Layer Sync in action, you can also watch the recordings of recent webinars where we demonstrated and discussed how Semantic layer Sync works with [Preset](https://event.on24.com/wcc/r/4243489/38E64F4551ABDA2967D79B9FFEAE8D3D) and [Metabase](https://event.on24.com/wcc/r/4321808/0C4A58D931932D9BBDD35D7FADB71776), other popular BI tools.


Tableau

Access data from the semantic layer to build workbooks and dashboards

Introducing Semantic Layer Sync with Tableau

The Cube and [Explo](https://www.explo.co/) [integration](https://cube.dev/blog/cube-and-explo-easy-customer-facing-analytics-with-the-universal-semantic) is exciting for data teams and application developers working to ensure fast and rich dashboards are in the hands of customers. Data teams can build beautiful, feature-rich customer-facing dashboards on data from any of the [large list of data sources that Cube supports](https://www.explo.co/integrations/cube). 

On the one hand, Cube’s [pre-aggregations and caching](https://cube.dev/product/caching-and-data-performance) ensure that performance will always be snappy. On the other, Explo provides incredible customization options that guarantee you’ll be able to make your dashboards fit right into the rest of your application. 

And [with both Cube and Explo](https://www.explo.co/partners/explo-cube), users will feel right at home. 

## The story that has Cube and Explo working together:

At Cube, we’re building a universal semantic layer to power every data application. 

We work to help users model all of their data with our sophisticated and flexible data modeling capabilities and manage access to that data with our powerful access control tools. Our unique [Cube Store](https://cube.dev/docs/product/deployment#cube-store) technology provides [fast in-memory caching and optional pre-aggregations](https://cube.dev/product/caching-and-data-performance) to provide the fastest response times for data applications. Finally, we provide [a comprehensive suite of API endpoints](https://cube.dev/product/data-apis) that enable developers to connect to Cube however they see fit.

One of the most frequent ways our customers take advantage of these functionalities is in customer facing scenarios. Customer facing analytics takes everything that’s hard about traditional BI and ups the stakes: you’re still connecting to data, dealing with data modeling, and building dashboards—but now you’re doing it with expectations for usability and performance that are more aligned with website expectations. Even if your internal stakeholders are ok with their dashboards taking ten or more seconds to load, your customers will very much *not* be ok with that.

Picture this: you’re hard at work developing your application and building features for your users. When you’re so deep into building the best UX possible, you probably don’t want to have to think about complicated data access patterns, performance and scaling concerns, and security when adding customer facing dashboards. That’s where Cube comes in. Let us deal with the hard work on the data side.

But what if you also don’t want to build your own customer facing dashboards with a front-end framework? Maybe you don’t want to deal with the maintenance, development costs, and time-to-value?  

## Cube and Explo: The Best of Both Worlds

Well—Cube has recently partnered with [Explo](https://www.explo.co/) to allow users to build beautiful, customer facing dashboards with their easy-to-use dashboard designer and then embed them into their applications easily. 

The Cube and Explo integration ([docs](https://docs.explo.co/data-sources/connecting-to-data-sources/data-source-types/cube)) empowers you to get the best of both worlds—for truly native, performant customer facing analytics with incredible time-to-value development. 

The Explo team has written [a fantastic guide](https://www.explo.co/blog/empowering-nosql-datasource-connectivity-unveiling-the-explo-and-cube-collaboration) detailing how to get started with Explo and Cube, featuring our ability to connect to NoSQL databases like MongoDB. Check it out to learn more about how our products work together and how we can help you delight your customers with powerful, fast dashboards.

Embedded Analytics

The Cube x Explo Integration

Cube and Explo: Easy Customer Facing Analytics with the Universal Semantic Layer

Any semantic layer is only useful if it delivers consistent metrics to data consumers, preferably more than just a single BI tool or data application.

![Semantic Layer in the data stack](https://ucarecdn.com/8434d52e-27a6-494e-acc4-7ffa7920f90e/)

Many aspects matter here:

- __Technical feasibility.__ Is there an API or integrations with existing BI tools?
- __Usability.__ How easy is it to query data for a data engineer or an end user?
- __Learning curve.__ How much ramp-up time is needed to become productive?

At Cube, we know for sure that there’s a design decision that checks all the boxes above and makes our semantic layer unmatched. Cube’s connectivity to BI tools is powered by the [SQL API](https://cube.dev/docs/backend/sql) that implements a Postgres-compatible protocol. That is, if your BI tool connects to Postgres, it will work with Cube.

Consequently, the learning curve is flat because you don’t need to study a new language or syntax to work with Cube. Good ol’ ANSI SQL works perfectly, and BI tools will generate SQL for your end users just fine.

```sql
SELECT
  DATE_TRUNC('DAY', timestamp) AS day,
  MEASURE(weekly_active)
FROM active_users
WHERE timestamp >= '2023-01-01'
GROUP BY 1
```

We always thought about ways to improve the experience with the SQL API and take using Cube with BI tools to the next level. Let's take a closer look at them.

Every BI tool has a [relatively thin data model](https://preset.io/blog/understanding-superset-semantic-layer/) inside with datasets, tables, columns, etc. However, keeping your semantic layer data model (i.e., cubes, views, measures, and dimensions exposed as tables and columns through the SQL API) in sync with your BI data model is a thankless job. Of course, every BI tool would inspect your data source and generate initial datasets upon first connection, and there’s a “Scan again” button somewhere in the settings. But do you, as a data engineer, wake up in the morning wishing to click that button every time you add a new measure, dimension, cube, or view to the semantic layer?

__Today, we are introducing [Semantic Layer Sync](https://cube.dev/docs/semantic-layer-sync), which completely bridges the gap between semantic layers and BI tools and enables instantaneous, zero-friction self-serve analytics.__ With Semantic Layer Sync, you can develop the data model and surface metrics from Cube to one or many BI tools in seconds while still having the benefit of never, ever breaking dashboards in a BI tool by untested changes.

## Semantic Layer Sync

Semantic layer Sync automatically synchronizes the data model from the semantic layer to Bl tools, making Cube-specific entities (e.g., cubes, views, measures, dimensions) match Bi-specific ones (e.g., datasets, tables, columns).

![SLS](https://ucarecdn.com/f598f41c-36ec-4ed9-960f-7c902a77ed74/)

An updated data model will automatically propagate to configured BI tools within seconds. In case you’re actively working on the data model in the [development mode](https://cube.dev/docs/cloud/workspace/development-api), you can manually trigger a sync to a separate, private dataset that would keep your production intact while allowing you to test your changes in a BI tool in addition to testing them in [Playground](https://cube.dev/docs/dev-tools/dev-playground).

See Semantic Layer Sync in action:

<video width="100%" controls><source src="https://ucarecdn.com/bb1ed393-c546-449d-a47a-ddcc20ad9f56/video.mp4" type="video/mp4"/></video>

Here’s some advice from [Tony Kau](https://www.linkedin.com/in/tonykau/), Partner Solutions Architect at Cube:

<Quote authorName="Tony Kau" authorAvatar="https://ca.slack-edge.com/T0FJ7RYAJ-U055M2SG8AZ-7548f748819c-512" authorRole="Partner Solutions Architect at Cube">

Cube insulates your BI tools from breaking upstream changes, but with great power of Semantic Layer Sync comes great responsibility.

  It is best practice to default to additive-only or versioned changes to the data model and be careful not to wreak havoc in downstream applications.

</Quote>

## Next steps

We’re releasing Semantic Layer Sync in preview. Currently, you can set up synchronization with [Apache Superset](https://superset.apache.org) (self-hosted), [Preset](https://preset.io) (managed), and [Metabase](https://www.metabase.com) (self-hosted and managed). We’re working with design partners on synchronization with Power BI, Tableau, and other BI tools. If you’d like to use Semantic Layer Sync with any BI tool, please [let us know](https://cube.dev/contact).

Here’s what [Juan Muñoz](https://www.linkedin.com/in/juanmmunoz/), Data Strategy and Innovation Lead at Breakthrough and an early adopter of Semantic Layer Sync, thinks:

<Quote authorName="Juan Muñoz" authorAvatar="https://ucarecdn.com/e2a25ca7-1f38-4e8a-90ad-ff69f400abe9/" authorRole="Data Strategy and Innovation Lead at Breakthrough">

We are just in the initial phase of testing Semantic Layer Sync. So far, having the ability to sync our dimensions and our measures to Preset is going to save us a bunch of time and eliminate any errors in trying to keep them in sync.

The semantic sync adds a lot of value for use cases like ours, where we need an analytical API that is consumed by an application as well as a BI tool.

</Quote>

__Next week, we’re [hosting a webinar](https://cube.dev/events/introducing-semantic-layer-sync-with-preset) on Semantic Layer Sync with Preset.__ Please join this webinar to see how Cube and Preset work together and hear from [Evan Rusackas](https://www.linkedin.com/in/rusackas/) (PMC member of Apache Superset), Tony Kau, and me.

__Semantic Layer Sync is available in Cube Cloud on [all tiers](https://cube.dev/pricing), and [you can try it today](https://cubecloud.dev/auth/signup).__ Join our Slack community at [slack.cube.dev](https://slack.cube.dev) to share your thoughts and opinions about this update.


Bridging the gap between the semantic layer and BI tools

Introducing Semantic Layer Sync

With [Metabase](https://www.metabase.com/) as the business intelligence platform, your team doesn’t need to speak SQL. It’s the easy, open-source way to help everyone in your company work with data like an analyst. Pairing it with [Cube](https://cube.dev/), the headless BI platform, will provide a consistent data model making it easy to build self-service analytics, shared across multiple teams.

Here’s what your Metabase dashboard will look like after we integrate it with Cube. If stuck, you can always refer to the [source code on GitHub](https://github.com/cube-js/cube.js/tree/master/examples/metabase).

![demo](https://ucarecdn.com/4d1d1527-a396-4b3a-8289-33c8812aaee6/)

> We've hosted a webinar on replacing Looker with Metabase and Cube. [Watch on-demand.](https://cube.dev/events/replacing-looker-with-cube-and-metabase)

## What is Metabase?

[Metabase](https://www.metabase.com/) is an [open-source](https://github.com/metabase/metabase) business intelligence platform with a low entry barrier, smooth visual interface, and generally pleasant user experience. It provides an easy way for everyone in your company to work with data like an analyst.

You can use Metabase to ask questions about your data, build self-service analytics, or even embed Metabase in your front-end data application to let your customers explore data on their own. You can save questions, group them into dashboards, and share both questions and dashboards with the your team.

Metabase enables three main scenarios:

* **Query and visualize your data.** Use the query builder to filter and summarize data. Choose between either the *Notebook editor* to ask sophisticated questions with joins, filters, and aggregations, or *Native queries* to compose questions in the database’s native query languages. Awesome if you're proficient with SQL!

* **Embed charts and share your results.** You can add questions to a dashboard and include filters and connect them to fields on questions to narrow the results. You can share the dashboard by sending the URL to your co-workers, or by embedding them using iframes. You can even embed the full Metabase app, which allows you to do things like delivering multi-tenant, self-service analytics.

* **Find things and stay organized.** Collections organize questions, models, dashboards, and other collections. They work like folders on a file system. Or, use the search bar to find data, metrics, segments, dashboards, models, and questions. But, [X-ray](https://www.metabase.com/docs/latest/exploration-and-organization/x-rays) is by far the most amazing feature in Metabase. X-raying a table will antomagically generate a bunch of questions that slice the table’s records in different ways and save it as a dashboard.

## What is Cube?

[Cube](https://cube.dev/) is the [headless BI](https://cube.dev/blog/headless-bi) platform for accessing data from [modern data stores](https://cube.dev/docs/config/databases), organizing it into consistent metrics definitions, and delivering them to downstream applications.

![headless BI](https://ucarecdn.com/dfb299b9-7e27-47f0-a362-0a14c643c740/)

Why would you want to have Cube in your data pipeline? **Data consistency.**

Cube will deliver consistent data to all teams using Metabase. Serving as a source of truth for the metrics definitions, access control rules, and caching settings, it solves the *many-to-many problem* many data teams have. Regardless of how many data sources (like Snowflake or Redshift) or data consumers (like Metabase) you have, Cube allows to get rid of siloed data pipelines.

![https://ucarecdn.com/728192a0-d30f-41c9-a8c9-f865361691e5/](https://ucarecdn.com/728192a0-d30f-41c9-a8c9-f865361691e5/)

Conceptually, Cube has four layers:

* **Data modeling.** With dozens of [supported data sources](https://cube.dev/docs/config/databases) and a [centralized data model](https://cube.dev/docs/schema/getting-started) for defining metrics definitions, you can make sure every team has access to exactly the same data, in Metabase and beyond.
* **Access control.** Cube’s [security configuration](https://cube.dev/docs/security) lets you manage who is able to access data and which data it is. As a part of that, Cube provides [row-level security](https://cube.dev/docs/security/context#security-context) and [multi-tenancy](https://cube.dev/docs/product/configuration/advanced/multitenancy) for Metabase users.
* **Performance.** Cube provides a [centralized caching layer](https://cube.dev/docs/caching) which ensures [consistent performance](https://cube.dev/docs/caching/pre-aggregations/getting-started) and data freshness across use cases or teams. As a result, your Metabase dashboards will load in under a second.
* **APIs**. Cube exposes three APIs: REST API, GraphQL API, and SQL API. Cube's [SQL API](https://cube.dev/docs/backend/sql) is fully Postgres-compliant, enabling connectivity to Metabase and, actually, any downstream tool that works with Postgres.

So, with Cube, you can use native, syntactically correct SQL queries, similar to how you’d query a data source directly:

```sql
SELECT
  DATE_TRUNC('day', createdAt) AS created_at_per_day,
  SUM(count) AS orders
FROM Orders
GROUP BY 1
ORDER BY 1 ASC
```

[Cube is open source](https://github.com/cube-js/cube.js), and you can self-host it in a cloud of your choice. Also, you can run Cube in [Cube Cloud](https://cube.dev/cloud) which provides fully managed experience with a [free tier](https://cube.dev/pricing).

## Integrate Metabase and Cube

Take a look a short video showcasing how Cube and Metabase work together:

<div style={{ position: 'relative', paddingBottom: '54.84375%', height: 0 }}><iframe src="https://www.loom.com/embed/38752bb23e5244d1a43675795c470a53" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen style={{ position: 'absolute', top: 0, left: 0, width: '100%', height: '100%' }}></iframe></div>

You can also follow more elaborate instruction below:

**Running Cube.** You can run Cube in two ways: either self-host it on your infrastructure or use the fully managed version in Cube Cloud.

For the sake of simplicity, we'll run [Cube Cloud](https://cube.dev/cloud). There’s a generous free tier for you to try. Go ahead, [sign up](https://cubecloud.dev/auth/signup) and follow the [instructions](https://cube.dev/docs/product/getting-started/core/create-a-project) on connecting to your data source and generating an initial data model.

Use these credentials to connect a sample e-commerce database to your Cube instance.

```bash
Hostname:  demo-db-examples.cube.dev
Port:      5432
Database:  ecom
Username:  cube
Password:  12345
```

This is what your deployment in Cube Cloud will look like:

![https://ucarecdn.com/4d1cf863-426c-4d40-829c-e3237a8e07d7/](https://ucarecdn.com/4d1cf863-426c-4d40-829c-e3237a8e07d7/)

Working with the data model. To see the data model you created above, navigate to the <Btn>Schema</Btn> tab. You will see files named `LineItems.js`, `Orders.js`, `Users.js`, etc. under the `schema` folder which defines the cubes in your data model.

![https://ucarecdn.com/b9d18c13-0d79-4487-9ed5-0a7c7c130db3/](https://ucarecdn.com/b9d18c13-0d79-4487-9ed5-0a7c7c130db3/)

Key ideas on what we’re seeing above:

- A cube is mapped to a table in your database to categorize measures (quantitative data) and dimensions (qualitative data) into [metrics definitions](https://cube.dev/docs/schema/reference/cube).
- This cube is mapped to the `public.orders` table.
- [Measures](https://cube.dev/docs/schema/reference/measures) are defined as aggregations (e.g. count, sum, etc.) over columns.
- [Dimensions](https://cube.dev/docs/schema/reference/dimensions) are mapped to columns.
- You can define complex measures and dimensions with custom SQL statements and references to other measures and dimensions.

**Customizing the data model.** You can add custom measures and dimensions, and edit them with filters or segments. In this example let’s update the schema by adding the `completedCount` measure to the `Orders` cube.

```javascript
completedCount: {
  type: `count`,
  filters: [{
    sql: `${CUBE}.status = 'completed'`
  }],
}
```

To do this, click the <Btn>Enter Development Mode</Btn> button in Cube Cloud to unlock the schema files for edits. This creates a development environment on a separate branch from your `main` branch. Here you can make changes to the data model before committing them to the main branch.

Here’s the `Orders.js` schema file, but with the added `completedOrders` measure. Paste this snippet into your `Orders.js` file.

```javascript
cube(`Orders`, {
  sql: `SELECT * FROM public.orders`,

  preAggregations: {
    // Pre-Aggregations definitions go here
    // Learn more here: https://cube.dev/docs/caching/pre-aggregations/getting-started  
  },

  joins: {
    Users: {
      sql: `${CUBE}.user_id = ${Users}.id`,
      relationship: `belongsTo`
    },

    Products: {
      sql: `${CUBE}.product_id = ${Products}.id`,
      relationship: `belongsTo`
    }
  },

  measures: {
    count: {
      type: `count`,
      drillMembers: [id, createdAt]
    },

    number: {
      sql: `number`,
      type: `sum`
    },

    completedCount: {
      type: `count`,
      filters: [{
        sql: `${CUBE}.status = 'completed'`
      }],
    }
  },

  dimensions: {
    id: {
      sql: `id`,
      type: `number`,
      primaryKey: true
    },

    status: {
      sql: `status`,
      type: `string`
    },

    createdAt: {
      sql: `created_at`,
      type: `time`
    },

    completedAt: {
      sql: `completed_at`,
      type: `time`
    }
  }
});
```

Once you commit and push this change, jump over to the Playground and run a query to get a response for the custom measure.

![https://ucarecdn.com/30dbcd19-a6c3-4d75-a532-5d4eeaea83f2/](https://ucarecdn.com/30dbcd19-a6c3-4d75-a532-5d4eeaea83f2/)

**Adding pre-aggregations.** Pre-aggregations are intermediate representation of the data, defined declaratively, computed in advance, persisted as tables, and used to accelerate queries. Cube has the ability to analyze queries against a defined set of pre-aggregations in order to serve the query from cache and not hit the data source directly.

Pre-aggregations physically reduce the size of the data. Fewer bytes to read, less time to return a response. This will dramatically improve query performance and provide a higher concurrency.

Let’s add a pre-aggregation definition to speed up the query above even more. Enter development mode once again, and edit the `Orders.js` file by pasting this piece of code in the pre-aggregations section.

```jsx
preAggregations: {
  completedOrdersByDay: {
    measures: [
      Orders.completedCount
    ],
    timeDimension: Orders.createdAt,
    granularity: `day`
  }
},
```

Here’s what the schema will look like.

![https://ucarecdn.com/3625d23f-91fc-4579-9f76-5d7638db32eb/](https://ucarecdn.com/3625d23f-91fc-4579-9f76-5d7638db32eb/)

Once you commit and push this change, jump over to the Playground and run the same query as you did above. This time you’ll see it return a response even faster:

![https://ucarecdn.com/b7e1d0ed-b9a9-4396-87fe-e335872382af/](https://ucarecdn.com/b7e1d0ed-b9a9-4396-87fe-e335872382af/)

**Integrating Metabase and building a dashboard.** You can run Metabase either in your infrastructure with the [open-source](https://github.com/metabase/metabase) version or use [Metabase Cloud](https://www.metabase.com/start/). For the sake of simplicity, let's [sign up](https://store.metabase.com/checkout/starter/login-details) for a Metabase free trial. Or, if you rather prefer using Docker, you can [run a Metabase instance yourself with Docker](https://www.metabase.com/docs/latest/installation-and-operation/running-metabase-on-docker).

Once you have signed in to your Metabase instance, go ahead and add a PostgreSQL data source. Cube’s SQL API speaks the PostgreSQL dialect of SQL which makes it compatible with all kinds of data tools, Metabase included. Copy the credentials from the SQL API section on the Overview page of Cube Cloud:

![https://ucarecdn.com/56fad92a-8a97-4e41-a602-4a36947be4e7/](https://ucarecdn.com/56fad92a-8a97-4e41-a602-4a36947be4e7/)

Or, you can use these sample credentials:

```bash
Host:      tan-ptarmigan.sql.gcp-us-central1.cubecloudapp.dev
Port:      5432
Database:  tan-ptarmigan
User:      cube
Password:  544056feb07f485e96913fc66b0404b4
```

Then, enter the credentials as a new PostgreSQL data source in Metabase.

![https://ucarecdn.com/3e4c319f-4708-493e-bd87-4a2a21d2f2ed/](https://ucarecdn.com/3e4c319f-4708-493e-bd87-4a2a21d2f2ed/)

Make sure to enable the "Use a secure connection (SSL)" toggle.

Now you can run queries to Cube from Metabase. By either using the Notebook editor to ask questions or Native queries, we can easily build a dashboard.

## Self-service analytics with Metabase

By far the most awesome feature in Metabase is the ability to X-ray a table and autogenerate a dashboard. Click the <Btn>⚡</Btn> icon to trigger the X-ray.

![https://ucarecdn.com/4db82cca-fae9-41ee-977e-261c5462a2fc/](https://ucarecdn.com/4db82cca-fae9-41ee-977e-261c5462a2fc/)

This will take you to an autogenerated dashboard. Here’s a [live preview](http://metabase.examplescube.dev/public/dashboard/947a9fa9-0c79-47e8-9cca-55cee7eafbcf) of what this dashboard looks like. 

![https://ucarecdn.com/e4b89682-d46a-460d-bcec-7e1a382a7446/](https://ucarecdn.com/e4b89682-d46a-460d-bcec-7e1a382a7446/)

Running an X-ray is an awesome way of hitting the ground running. But, let’s move on to more complex topics, building a custom dashboard.

Let's use the Notebook editor to ask a question. Select the `Orders` table. Summarize the `Sum of CompletedCount` by `CreatedAt: Day`.

![https://ucarecdn.com/0dd1a3d0-7e17-4e1f-85e4-374250e4a392/](https://ucarecdn.com/0dd1a3d0-7e17-4e1f-85e4-374250e4a392/)

This will visualize the same chart as we did before in the Cube Cloud Playground.

![https://ucarecdn.com/0f24c9ad-dbad-4508-8b79-054e1e5083d4/](https://ucarecdn.com/0f24c9ad-dbad-4508-8b79-054e1e5083d4/)

Using the Notebook editor is an awesome way of executing SQL without writing SQL. It’s great for team members that don’t speak SQL.

However, what about the ones that do? Let’s write a native SQL query next. Views in Cube can be queried the same way as cubes. This snippet below will return the same data as the Notebook query from above.

```sql
SELECT
  DATE_TRUNC('day', createdAt) AS created_at_per_day,
  SUM(completedCount) AS completed_orders
FROM Orders
GROUP BY 1
ORDER BY 1 ASC
LIMIT 10000
```

![https://ucarecdn.com/8d2a7839-e14a-40cf-879d-cb1aa56dce57/](https://ucarecdn.com/8d2a7839-e14a-40cf-879d-cb1aa56dce57/)

Once you’re happy with the questions, save them, and add them to a dashboard.

![https://ucarecdn.com/07c02752-3dc1-4a49-8fe3-204d1fa4a99c/](https://ucarecdn.com/07c02752-3dc1-4a49-8fe3-204d1fa4a99c/)

## Sharing and embedding Metabase dashboards

Metabase gives you multiple options to share dashboards. You can embed them by using iframes. You can share the dashboard by sending the URL to your co-workers. You can even embed the full Metabase app, which allows you to do things like delivering multi-tenant, self-service analytics.

In the Admin settings, click <Btn>Public Sharing</Btn> and toggle `Enable Public Sharing` to `Enabled`. This will allow you to create public URLs to share dashboards.

![https://ucarecdn.com/85d24d95-3eb8-4a67-b84c-eea5006a6319/](https://ucarecdn.com/85d24d95-3eb8-4a67-b84c-eea5006a6319/)

To embed dashboards jump below to the <Btn>Embedding</Btn> tab. Toggle it to <Btn>Enabled</Btn>, and you’re good to go.

![https://ucarecdn.com/3959935d-b3c0-4000-b40a-2076999f7885/](https://ucarecdn.com/3959935d-b3c0-4000-b40a-2076999f7885/)

To select a specific dashboard you want to share, go to the dashboard and click the <Btn>Sharing</Btn> button in the top right.

![https://ucarecdn.com/5fd254e2-566e-4bbe-be0e-0739541da643/](https://ucarecdn.com/5fd254e2-566e-4bbe-be0e-0739541da643/)

This will open up a prompt to select how to share the dashboard.

![https://ucarecdn.com/e84de9a9-680d-47bc-b147-ac6e7e960d72/](https://ucarecdn.com/e84de9a9-680d-47bc-b147-ac6e7e960d72/)

Check out the [Metabase docs](https://www.metabase.com/docs/latest/embedding/start) to learn more about embedding and sharing dashboards.

## Wrapping up

Using Metabase with Cube as a Headless BI layer will ensure data uniformity and consistent metrics definitions for your self-service analytics.

Would you like to explore more about Cube? [Check the docs](https://cube.dev/docs/) and create a free [Cube Cloud account](https://cubecloud.dev/auth/signup) today.

Also, please feel free to [join our community](https://slack.cube.dev/) of almost 7000 data practitioners on Slack, [drop us a line](https://cube.dev/contact), or give Cube a [star on GitHub](https://github.com/cube-js/cube.js). See you there!

Adnan Rahic

Metabase

Business intelligence for everyone, with consistency and without the SQL barrier. 

Self-service analytics with Metabase and Cube

When I was reading Pedram’s [deep dive on metrics layers](https://pedram.substack.com/p/what-is-the-metrics-layer) a few weeks ago, I couldn’t help but question the tool selection. One can obviously blame my employee-employer affiliation which is hard to deny. However, the real reason for that was this [summary statement](https://pedram.substack.com/p/what-is-the-metrics-layer):

> All three tools have different trade-offs, and their strengths and weaknesses tell of the challenges a metrics layer faces.
> 

While this is a true statement, it dismisses the fact that there’s an ergonomic, feature-complete, and accessible solution on the market that doesn’t suffer from highlighted pitfalls. With that, I’m putting Cube in the spotlight and kindly requesting your ~~blowback~~ [feedback on social media](https://twitter.com/thecubejs/status/1578049949811589123).

## In previous episodes

If you haven’t read the original [deep dive on semantic layers](https://pedram.substack.com/p/what-is-the-metrics-layer), please do. I promise it’s gonna be a rewarding experience.

There, Pedram mentions some prior thought leadership on the topic and introduces a challenge for three tools: Looker, dbt Metrics, and Lightdash. They have to model and provide access to the *Activation Metric*, a crucial characteristic of an imaginary B2B SaaS product with users and workspaces. A workspace is considered active if users perform some activation event, so we want to report on the activation rate daily, weekly, or monthly and how it changes over time. Later, Pedram shows how Looker, dbt Metrics, and Lightdash solve the data modeling and elaborates on their strengths and pitfalls.

Here’s the `workspace_details` table matching the imaginary dataset that was used by all tools to calculate the metrics. I’ve generated 20 million rows and put them into Postgres, so we have something to work with:

![dataset](https://ucarecdn.com/1f7f0a20-b331-4afa-9e63-7313a7e96c05/)

Now, let’s talk about Cube.

## Cube, the semantic layer

Cube is the [semantic layer](https://cube.dev) for building data applications, created to make data consistent and accessible. It solves the many-to-many problem many data teams have by serving as a source of truth for metrics definitions, access control rules, and caching settings.

![Cube in the pipeline](https://ucarecdn.com/dfb299b9-7e27-47f0-a362-0a14c643c740/)

Cube connects to numerous [data sources](https://cube.dev/docs/config/databases), from cloud data warehouses to [streaming platforms](https://cube.dev/blog/headless-bi-with-streaming-data), and delivers data to all kinds of [data consumers](https://cube.dev/docs/config/downstream) via multiple APIs, including the [SQL API](https://cube.dev/blog/expanded-bi-support). It is deliberately visualization-agnostic and delegates data presentation and visualization to BI tools, data notebooks, front-end apps, etc.

Cube is open source and there's also [Cube Cloud](https://cube.dev/cloud) that provides fully managed experience and additional tooling on Free, Standard, and Enterprise tiers (see [pricing](https://cube.dev/pricing)).

## Data modeling

In Cube, we define metrics in [data model](https://cube.dev/blog/open-source-data-modeling) files that seem to be heavily inspired by LookML.

At the top level, everything is grouped in “cubes” that are usually modeled over tables or views in the data warehouse but can also be modeled over pretty complex queries. Cubes include definitions for measures (quantitative features), dimensions (qualitative features), segments (reusable filters), and pre-aggregations (declarative definitions of rollups that drastically speed up queries, more on them later).

Here’s the data model for our activation metric:

```jsx
cube(`WorkspaceActivation`, {
  sql: `SELECT * FROM public.active_workspace_details`,

  measures: {
    count: {
      type: `count`
    },

    n_workspaces: {
      sql: `workspace_id`,
      type: `countDistinct`,
    },

    n_active_workspaces: {
      sql: `workspace_id`,
      type: `countDistinct`,
      filters: [ {
        sql: `${is_active_workspace} IS TRUE`
      } ],
    },

    activation_rate: {
      sql: `ROUND(100 * (1.0 * ${n_active_workspaces} / ${n_workspaces}), 2)`,
      type: `number`
    }
  },

  dimensions: {
    workspace_id: {
      sql: `workspace_id`,
      type: `number`,
      primaryKey: true
    },

    reporting_day: {
      sql: `reporting_day`,
      type: `time`
    },

    is_active_workspace: {
      sql: `is_active`,
      type: `boolean`
    }
  },
});
```

A few observations here:

- Similarly to Looker, we define measures as formulas, not as fully-formed SQL tables.
- While we can use “formatting” functions like `ROUND` in measure definitions, formatting options are deliberately limited. Cube puts the burden of data presentation on downstream tools.
- By default, we don’t have to specify how our reporting date should be broken down. We’ll be able to provide desired time granularity at query time.
- Needless to say, we can define other cubes and [joins](https://cube.dev/docs/schema/reference/joins#joins) between them.

## Query syntax

Cube provides a set of APIs to fetch data: [SQL API](https://cube.dev/docs/backend/sql) (mostly for BI tools and data notebooks), [REST API](https://cube.dev/docs/rest-api), and [GraphQL API](https://cube.dev/docs/backend/graphql) (mostly for front-end applications). A simple query to the SQL API:

```jsx
SELECT reporting_day, activation_rate
FROM WorkspaceActivation;
```

Of course, we can run a more complex query, too:

```jsx
SELECT
  DATE_TRUNC('WEEK', reporting_day) AS reporting_week,
  activation_rate
FROM WorkspaceActivation
ORDER BY 1 DESC;
```

Queries would turn into JSON when expressed in the REST API syntax. First one:

```json
{
  "measures": [
    "WorkspaceActivation.activation_rate"
  ],
  "timeDimensions": [ {
    "dimension": "WorkspaceActivation.reporting_day"
  } ]
}
```

Second one:

```json
{
  "measures": [
    "WorkspaceActivation.activation_rate"
  ],
  "timeDimensions": [ {
    "dimension": "WorkspaceActivation.reporting_day",
    "granularity": "week"
  } ],
  "order": {
    "WorkspaceActivation.reporting_day": "desc"
  }
}
```

Since we haven’t connected a downstream tool yet, we can run queries and explore the metrics in Cube’s [Playground](https://cube.dev/docs/dev-tools/dev-playground) with drop-down inputs for measures and dimensions:

![Playground](https://ucarecdn.com/0a0e01d2-cb3a-4cbe-8f2f-a87b257324bb/)

We can instantly get the JSON queries for the REST API here:

![JSON query](https://ucarecdn.com/51228e1d-33b6-46d7-8bf6-637e04261e2c/)

More conveniently, we can also look up the SQL statement that would be generated by Cube and run against the data warehouse when the query is executed. No surprise here: Cube uses the provided query and data model definitions to compose the final query: 

![Generated SQL query](https://ucarecdn.com/742514b5-ee4e-43dd-8c1b-d03b3284dbcc/)

## Query acceleration

Obviously, queries can be expensive: costly to run, too complex to wait for, or both.

In that case, we can define a pre-aggregation (actually, the recommendation is always to use pre-aggregations in production). Here’s what we need to append to the data model:

```jsx
  preAggregations: {
    main: {
      measures: [ activation_rate ],
      timeDimension: reporting_day,
      granularity: `week`,
      refreshKey: {
        every: `1 day`
      }
    }
  }
```

It instructs Cube to build a rollup and use it to serve queries that contain any subset of provided measures and dimensions (namely, `activation_rate` and `reporting_day` with weekly granularity). Usually, a single pre-aggregation speeds up multiple queries. We can also configure freshness: a pre-aggregation update can be triggered on schedule (e.g., every day) or when an arbitrary SQL statement yields a new result. 

Now, the last query would return the same result, but a completely different query would be executed against the data warehouse:

![Accelerated SQL query](https://ucarecdn.com/786f7cc1-791d-4122-b13a-b3660405f439/)

Truth be told, it wouldn’t be executed against the data warehouse at all. The `prod_pre_aggregations.workspace_activation_main` table is transparently created and maintained in [Cube Store](https://cube.dev/blog/introducing-cubestore), a custom-built massively distributed columnar storage for pre-aggregation data.

There’s an option to skip using Cube Store and store pre-aggregations in a data warehouse, but that’s not the most reasonable thing to do. With pre-aggregations in Cube Store, Cube can serve practically any query with sub-second latency (expect something between 50 ms and 500 ms) and allow for a decent concurrency (say, 100 QPS or maybe 1000 QPS).

Okay, but what would Cube do if we need to query for other granularity? Since it’s aware that queried measures are defined with distinct counts, it won’t be using the rollup and will transparently fall back to a query to the data warehouse (there’s an [option to disallow that](https://cube.dev/docs/caching/using-pre-aggregations#rollup-only-mode) at all times, if we need to).

![Non-accelerated SQL query](https://ucarecdn.com/a0d3bd13-889d-4a92-925d-984ee2dd9a4d/)

## Data consumers

Now, we’re ready to connect downstream tools. We can pick anything that supports Cube’s SQL API, and that’s practically any tool. Cube’s SQL API uses Postgres dialect and wire protocol, so if something works with Postgres as an upstream source, it works with Cube: 

![Supported data sources](https://ucarecdn.com/ba240ef2-11fc-477d-843d-39b0b9fe2649/)

We have numerous options here. Out of respect for the first tech company ever where the [first triple-name-tie is Claire](https://twitter.com/clairebcarroll/status/1570194384980971522), let’s connect Cube to [Hex](https://hex.tech):

![Connection to Hex](https://ucarecdn.com/7c89eb8a-d7dd-41b9-bcdb-c1889b70eba5/)

Indeed, [Hex works with Cube](https://cube.dev/blog/hex-integration-collaborative-data-notebooks):

![Hex notebook](https://ucarecdn.com/3761be9c-722c-461e-a1ba-7dcb01e1441b/)

In case we’re building a front-end app, we can directly `fetch` from the REST API endpoint or use the provided JavaScript client library:

```jsx
import cubejs from '@cubejs-client/core';

const cubejsApi = cubejs.CubejsApi(
  process.env.CUBE_TOKEN,
  { apiUrl: process.env.CUBE_API_URL }
);

const query = {
  measures: [ 'WorkspaceActivation.activation_rate' ],
  timeDimensions: [ {
    dimension: 'WorkspaceActivation.reporting_day',
    granularity: 'week'
  } ],
  order: {
    'WorkspaceActivation.reporting_day': 'desc'
  }
};

const resultSet = await cubejsApi.load(query);

console.log(resultSet.tablePivot());
```

Now you can plot the data with a [charting library](https://awesome.cube.dev/?tools=charts) of your choice:

![Data in the terminal](https://ucarecdn.com/dee1b9f9-74ff-4e06-8522-335922f2afd1/)

## Wrapping up

Hopefully, this write-up provides some insight into how Cube works and helps compare it to Looker, dbt Metrics, and Lightdash from the original [deep dive](https://pedram.substack.com/p/what-is-the-metrics-layer).

Also, if you’re using dbt Metrics, please keep in mind that you can leverage Cube’s [integration with dbt](https://cube.dev/blog/dbt-metrics-meet-cube) that transparently reads metrics definitions from dbt and automagically creates a data model from them.

Currently, Cube uses JSON-like markup for data model definitions and Looker-like metrics organization into cubes. Later in 2022, Cube is likely to [introduce YAML markup](https://forms.gle/4CZRRKK8nD4PvtxZA) for data models and an alternative approach to metrics.

With that, I do have an answer to the final question from Pedram’s article:

> Can a metrics layer be universal enough to gain applicability across the data stack yet still be designed in such a way to be relevant to BI tools?
> 

Yes. Try Cube.

The easiest way to get started with Cube is [Cube Cloud](https://cube.dev/cloud). It provides managed hosting and convenient tools for Cube, including the Playground, the data model editor with syntax highlighting, and—more importantly—the ability to instantly fork data models and query private versions of APIs while the production version stays intact and serves queries.

[Sign up for Cube Cloud](https://cubecloud.dev/auth/signup) on the free tier today and experience that yourself. Feel free to connect your production dataset or tinker with the Postgres instance used in this blog post:

```
Host:      demo-db-examples.cube.dev
Database:  ecom
User:      cube
Password:  12345
```

Cube in the spotlight alongside Looker, dbt Metrics, and Lightdash.

Deep dive: What the heck is the Semantic Layer

The ongoing story of the digital age is still about [taking products apart](https://hbr.org/2014/06/how-to-succeed-in-business-by-bundling-and-unbundling). The wave of [bundling](https://towardsdatascience.com/the-great-data-debate-unbundling-or-bundling-7d7721ee8514), [unbundling](https://blog.fal.ai/the-unbundling-of-airflow-2/), and [rebundling](https://dagster.io/blog/rebundling-the-data-platform) happening in the data space has subsided, but the point remains. Generations of tools in the modern data stack, whatever it is, succeed each other primarily for two reasons:

- Emerging tools provide more flexibility and a lower entry barrier for practitioners.
- Alternatively, teams escape into a safe harbor of a well-known integrated solution that promises big returns on even bigger investments. Indeed, has anyone ever got fired for buying Looker?

Today, we’re going to talk about Cube and Apache Superset—a bundle of tools representing a finer alternative to Looker in many use cases.

> We've had a webinar on replacing Looker with Cube and Superset. [Check the recording and slides.](https://cube.dev/events/replacing-looker-with-cube-and-superset)

## Free as in “open source”

[Cube](https://cube.dev) and [Superset](https://superset.apache.org) belong to different categories in the data stack. The former is the [headless business intelligence](https://cube.dev/blog/headless-bi) platform, and the latter serves as the data visualization and exploration platform. However, being open source and standing on the shoulders of giants are among many things that they have in common.

Both tools are licensed under Apache License 2.0 and actively developed on GitHub. Over the last 3 years, Cube’s [repository](https://github.com/cube-js/cube.js) has acquired almost 14,000 stars (an unmatched [leader in the category](https://twitter.com/sspaeti/status/1570044606338990081)). Written mostly in Rust, Cube’s data processing and storage are based on the [Arrow DataFusion](https://github.com/apache/arrow-datafusion) query execution framework which uses [Apache Arrow](https://arrow.apache.org/) as its in-memory format. Superset has a longer history (born at Airbnb in 2015 where it replaced Tableau, joined the Apache Incubator program in 2017), has a [repository](https://github.com/apache/superset) with 48,000 stars, and is powered by [Apache ECharts](https://echarts.apache.org/en/index.html), one of the most mature and popular charting libraries. 

![Cube and Superset](https://ucarecdn.com/5f3f2313-c055-4b9e-b345-56568c53aca2/)

You’re definitely free to take and use Cube and Superset at your own discretion, including self-hosting them in your private or public cloud. You’re also free to explore and get started with [Cube Cloud](https://cube.dev/cloud) and [Preset Cloud](https://preset.io/product/), fully managed platforms with freemium pricing models and plenty of quality of life features on top of open source products. Compare that to Looker’s “[request a demo](https://cloud.google.com/resources/looker-demo/?_ga=2.157282873.347220352.1663670208-344442256.1663670208)” paywall that would cost your team a few weeks of qualification calls on Google Meet before you start building.

## Simple as in “separation of concerns”

Cube is intentionally [headless](https://cube.dev/blog/headless-bi) and agnostic to the data presentation layer. However, it does a number of things and does them well:

- connects to a plethora of [data sources](https://cube.dev/docs/config/databases), from cloud data warehouses like BigQuery, Snowflake, and Redshift to streaming platforms like Kafka and Redpanda;
- provides a [data modeling](https://cube.dev/docs/schema/getting-started) layer as the centralized source of truth for metrics definitions;
- secures data with its [access control](https://cube.dev/docs/security) layer;
- makes sure any query runs well under a second with its [caching](https://cube.dev/docs/caching) layer;
- delivers data to any downstream tool, including BI tools like Superset, via its API layer that provides [SQL API, REST API, and GraphQL API](https://cube.dev/docs/config/downstream#ap-is-references).

Superset works by connecting to a data source and querying the data where it lives. The ideal way to use Superset is with a [dataset-centric approach](https://preset.io/blog/dataset-centric-visualization/) to modeling and visualization. 

A dataset-centric approach implies that a well-normalized dataset is used to “derive” richer datasets with extra semantics, making them valuable for analysis and visualization. By creating derived datasets that incorporate aggregate metric calculations earlier in the ETL/ELT process *before* surfacing for visualization, many of the issues with change management, maintenance, logic reuse within dashboards, etc. are significantly reduced for a better experience. 

Cube complements Superset in this way, and this allows for Superset-generated SQL queries to work with no issues when connected to a Cube environment (which is treated as a PostgreSQL database connection). 

![Looker vs Cube + Superset](https://ucarecdn.com/59031c52-890f-402f-9400-0d0d7034c887/)

You’re free to configure and fine-tune each tool and each layer within every tool when building with Cube and Superset. Want to build and schedule a report? Check Superset dashboards. Need to expose new metrics in that report? Cube’s data modeling layer is at your service.

## Compatible as in “no vendor lock-in”

Speaking of data modeling, Cube provides a [data modeling language](https://cube.dev/blog/open-source-data-modeling) that is not tied to any specific interface, visualization, or user experience. Unlike proprietary LookML definitions that require Looker IDE for syntax highlighting and linting, Cube’s data model is written in JavaScript (and [soon-to-be-written](https://forms.gle/4CZRRKK8nD4PvtxZA) in YAML) and feels native in your editor of choice. On top of that, you are able to generate a data model dynamically or even fetch it from a remote endpoint.

Consider an excerpt of Looker view from the recent [deep dive](https://pedram.substack.com/p/what-is-the-metrics-layer) by Pedram:

```yaml
view: workspace_activation {
  sql_table_name: "METRICS"."WORKSPACE_ACTIVATION" ;;

  dimension_group: date {
    type: time
    timeframes: [
      raw,
      time,
      date,
      week,
      month,
      quarter,
      year
    ]
    sql: ${TABLE}."REPORTING_DATE" ;;
  }

  dimension: is_active_workspace {
    type: yesno
    sql: ${TABLE}."IS_ACTIVE_WORKSPACE" ;;
  }

  dimension: workspace_id {
    type: string
    primary_key: yes
    sql: ${TABLE}."WORKSPACE_ID" ;;
  }

  measure: count_workspaces {
    type: count_distinct
    description: "# of Workspaces"
    sql: ${workspace_id} ;;
  }

  measure: count_active_workspaces {
    type: count_distinct
    description: "# of Unique Workspaces Active within 1 Day"
    sql: ${workspace_id} ;;
    filters: [is_active_workspace: "yes"]
  }

  measure: activation_rate {
    type: number
    sql: ${count_active_workspaces} / ${count_workspaces} ;;
    value_format_name: percent_1
  }
}
```

Compare with the equivalent Cube data model (way less of `;;`, to say the least):

```javascript
cube(`WorkspaceActivation`, {
  sql: `SELECT * FROM public.active_workspace_details`,

  measures: {
    count: {
      type: `count`
    },

    n_workspaces: {
      sql: `workspace_id`,
      type: `countDistinct`,
    },

    n_active_workspaces: {
      sql: `workspace_id`,
      type: `countDistinct`,
      filters: [ {
        sql: `${is_active_workspace} IS TRUE`
      } ],
    },

    activation_rate: {
      sql: `ROUND(100 * (1.0 * ${n_active_workspaces} / ${n_workspaces}), 2)`,
      type: `number`
    }
  },

  dimensions: {
    workspace_id: {
      sql: `workspace_id`,
      type: `number`,
      primaryKey: true
    },

    reporting_day: {
      sql: `reporting_day`,
      type: `time`
    },

    is_active_workspace: {
      sql: `is_active`,
      type: `boolean`
    }
  },

  preAggregations: {
    main: {
      measures: [ activation_rate ],
      timeDimension: reporting_day,
      granularity: `week`,
      refreshKey: {
        every: `1 day`
      }
    }
  }
});
```

In a similar fashion, Cube’s API layer is compatible with practically any data consumer. When the time comes, and you realize that, alongside business users using dashboards and reports in Superset, you’d like to have data analysts crunching numbers and seeking insights in data notebooks, Cube will be there to help liberate your data.

![Data consumers](https://ucarecdn.com/b35f44ef-12a5-42d7-a618-74637fc3e0cd/)

You can expect any SQL query generated by your data exploration tool like Superset to work with Cube’s SQL API. Needless to say, equivalent queries to Cube’s REST API and GraphQL API will yield the same data:

```sql
SELECT
  DATE_TRUNC('WEEK', reporting_day) AS reporting_week,
  activation_rate
FROM WorkspaceActivation
ORDER BY 1 DESC;
```

Let’s have a bird’s-eye view here.

The generation of BI tools like Looker encouraged end-users to invest heavily in building out tons of LookML models to populate the semantic layer. While this established Looker as a source of truth in an organization for business metrics, it also created an immense amount of lock-in in your BI tool. You couldn’t take your LookML models with you and use them with another tool if you decided to switch BI tools. Google’s acquisition of Looker accelerated organizations’ anxieties around this lock-in, to the point that Google was actually [forced to integrate LookML with Tableau](https://roundup.getdbt.com/p/look-ml-tableau-metrics-layer). This way, organizations could use LookML for transformation (Looker’s strength) and Tableau for visualization (Tableau’s strength).

The future however is looking to be very different from the past:

- Open-source headless BI platforms like Cube provide unified semantic layers to sit between the database and BI later, eliminating the need, or providing alternate implementations, for expensive solutions like Looker that lock you in.
- Open-source BI tools like Superset with an intentionally thin semantic layer complement Cube and enable *last-mile data transformation* for the explicit purpose of data visualization in your BI tool.

When the need for a complex yet flexible metrics/semantic layer arises, Cube and Superset is a winning open source-based combo!

## Ready-to-go as in “today”

Now, you’re very much welcome to try Cube and Superset today and see them in action. Please join the Slack communities of [Cube](https://slack.cube.dev) and [Superset](https://join.slack.com/t/apache-superset/shared_invite/zt-16jvzmoi8-sI7jKWp~xc2zYRe~NqiY9Q) to share your feedback.

Please tune in to the [webinar on October 4](https://cube.dev/events/replacing-looker-with-cube-and-superset) with [Shreesham Mukherjee](https://www.linkedin.com/in/shreesham/), Developer Relations Engineer at Preset, and [Igor Lukanin](https://www.linkedin.com/in/igorlukanin/), Head of Developer Relations at Cube. We’ll discuss Cube and Superset as an open source alternative to Looker in popular use cases, demo both tools, and take your questions.

See you!

Shreesham Mukherjee

Respectfully unbundling the elephant in the BI room.

Open source Looker alternative with Cube and Apache Superset

These days, customer-facing analytics are everywhere. 

We are, after all, in The Data Age—hence why you’re reading this blog and why we’re writing it. And because of the ubiquity of data, as consumers, we’ve become extraordinarily curious; we want to know everything about our businesses, investments, and lap times. 

Consumers are pining for insights—presented in fast-loading, beautifully customized dashboards. And so, many companies are turning to embedded analytics with [Tableau](https://www.tableau.com/). 

But as more consumers demand analytics, raising the standards of UI customization, interactivity, and speed, what if there were a more tailored, more performant way to give users the insights they need?

Well, there is: embedded analytics with Tableau and [Cube](https://cube.dev/). Let’s explain. 

## What is Embedded Analytics?

Simply put, [embedded analytics](https://cube.dev/blog/what-is-embedded-analytics) is the practice of integrating data analytics and visualization capabilities with a user’s natural workflow, such as their web portals, internal tools, or applications. 

For example: with embedded analytics, rather than needing to export sales data from their e-commerce platform and then conduct analysis separately in Excel, a seller could derive insights from dashboards and reports available to them directly within their commerce portal. 

Of course, embedded analytics __can be used in internal- and external-facing applications to provide real-time static and interactive reports, dashboards, and data visualizations__. 

There are many benefits of using embedded analytics. First, it can __save the user time and effort__ and add a lot of value. In turn, this saved time and gleaned insights __contribute to a user-centric UX that drives adoption__—even among those who aren’t as analytics-experienced. And higher adoption means a __better ROI on internal tooling__ and an __increase in revenue for external tooling__. 

## Embedded Analytics with Tableau

![](https://ucarecdn.com/1b6df403-1884-4e4d-83b1-b26788833ef4/)

So, why do so many companies turn to [embedded analytics with Tableau](https://www.tableau.com/products/embedded-analytics)?

Tableau is one of the leading platforms for data visualization and dashboarding. It's based on its own VizQL, which expresses data visually by translating drag-and-drop actions into data queries. 

This drag-and-drop capability makes data analytics and business intelligence accessible to a much wider pool of people—which is a great thing. Clearly, given its smashing success, Tableau met a hot demand for data democratization and did it well. 

*However*, things get a little more hinky when it comes to the [embedded analytics stack](https://cube.dev/blog/modern-embedded-analytics). This is because users not only use Tableau for analytics within Tableau itself but also use it to power embedded analytics within other applications. 

The problem is that __having your embedded analytics with Tableau sit directly on top of your data warehouse comes with a few shortcomings__, such as:

1. Difficulty with customizability and designing user-centric UIs

2. Duplicated effort and opportunities for inconsistency when creating multiple sets of data definitions and security contexts

3. Weaker analytics performance

### 1) Difficulty with customizability and designing user-centric UIs
Tableau has many visualization layer options, but it just doesn’t have one for every audience or use case. You can undoubtedly brand the Tableau visualizations embedded in your app; however, there are restrictions on what you can build with the visualization layers Tableau offers (e.g., extremely use-case-specific drill-downs).

And so, __Tableau’s visualization templates may work just fine for 80% of your applications, but those that truly need a highly tailored, custom UI will require you to build a custom presentation layer from scratch__. 

The problem is that using multiple different visualization layers together with Tableau—meaning, both custom-built and from Tableau—leads to…

### 2) Duplicated effort and opportunities for inconsistency

![](https://ucarecdn.com/78d63d2b-23b9-48f4-bb96-8bab43cc7ded/)

So you want to use Tableau and a separate charting library to build a custom presentation layer? That makes perfect sense when you want to combine the advantages of Tableau’s presentation layers with the flexibility of a custom UI. 

However, the challenge lies in consistently orchestrating data modeling, security, and caching across all of your presentation layers. 

__By connecting multiple presentation layers to your data warehouse, you’ll need to individually orchestrate your data models and access controls so they’re uniformly defined__. That’s a lot of duplicated effort—which opens the door to gaps and errors. 

### 3) Weaker analytics performance

Lastly, powering embedded analytics with Tableau without a BI layer between Tableau and the data warehouse can cause latency in your user-facing visualizations and dashboards.

Latency is a true user adoption killer: a Google study showed that [bounce likelihood increased by 32%](https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-new-industry-benchmarks/) when a page’s load time increased from one second to three, and by *90%* when page load time increased from one to five seconds. So, performance is essential.

__In a stack in which Tableau’s presentation layer sits directly on top of your data source, your users request data from the data source for every query__. At best, __this is redundant and costly__, as multiple users may be requesting the same information. 

At worst, however, building a stack like this __can result in latency and lower performance__. Request volume across users is unpredictable; you can’t control how many people simultaneously request data or consume visualizations. And so, if you have multiple presentation layers, each with duplicate data modeling, security, and caching layers, each making separate and redundant requests directly of the data source—that opens the door to latency.

Latency can be a problem even if you only use Tableau (don’t worry, we happen to have [a fix](https://cube.dev/cloud)). But, with multiple presentation layers, the chance of uneven performance across them is much higher. 

## The best of both worlds: embedded analytics with Tableau and Cube

Alright—let’s get to the solution. 

Tableau is a fantastic tool (in fact, here’s [how to use Tableau with Cube](https://cube.dev/blog/tableau-tutorial).) Combining it with custom presentation layers is a great way to get both efficient, out-of-the-box visualizations and user-centric UI for your embedded analytics. 

So how can you fix the issues above? With upstream, centralized data modeling, security, and caching orchestration. Hi, we’re [Cube](https://cube.dev/cloud). 

### Cube streamlines building embedded analytics with Tableau and custom presentation layers

![](https://ucarecdn.com/b52d016a-8ca8-4cdb-85aa-765669ff781c/)

Cube is a [headless BI](https://cube.dev/blog/headless-bi) platform that enables your data modeling, data access control, and caching layers to live upstream of every presentation layer and data application in your stack. 

So, rather than individually orchestrating r[ole-based access controls](https://cube.dev/docs/recipes/role-based-access#enforcing-role-based-access) or metrics definitions for each presentation layer, you’re centralizing and defining them once—removing duplicated effort and its inevitable inconsistencies.

### Cube ensures uniformly performant embedded analytics powered by Tableau and custom presentation layers

Cube’s robust caching layer manages the throughput of data requests and acts as a buffer between your data source and your data application. Its advanced [pre-aggregation capabilities](https://cube.dev/docs/caching#pre-aggregations), query queue, and [refresh keys](https://cube.dev/docs/caching#in-memory-cache-refresh-keys) protect your data warehouse from redundant, costly, and latency-causing queries. 

Designed to protect the data source from the possibility of even an unlimited number of concurrent requests, Cube can significantly speed up your embedded Tableau dashboards and visualizations. 

Cube also makes embedded analytics more performant even when built with a combination of Tableau and custom presentation layers. By allowing Cube to do the heavy lifting of data modeling, security, and caching orchestration, the presentation layers become very “thin”—essentially, not needing to process much. This enables them to become uniformly performant and allows the application’s embedded analytics to become more performant as a whole. 

## Learn More

Interest piqued? We thought it might be. 

Give your users a performant, data-rich embedded analytics experience with Tableau and Cube—especially since [Cube is free to use](https://cube.dev/cloud) and we already have a [tutorial for using Tableau with Cube](https://cube.dev/blog/tableau-tutorial).

Get in touch with us and the rest of the Cube community on [Slack](https://slack.cube.dev/) or [Github](https://github.com/cube-js/cube.js).

In the mood for some hands-on help with building a modern embedded analytics data stack? [Schedule a time to chat with us 1:1](https://cube.dev/contact).


Tamar Barlev

A “How-To” about how to make your embedded analytics flexible and performant. 

Embedded Analytics with Tableau and Cube

In case you missed it, we recently released [Cube’s SQL API][8], with expanded support for BI tools and data notebooks. 

That’s exciting (we’re *very* excited) because consistent, performant, and secure data is now accessible to any data consumer in your company—from app developers to general business users. Cube’s definitions are consistent across every application. 

Think of your favorite BI tools: if they can connect to a data store via SQL, they’ll work with Cube.

To illustrate the beautiful simplicity of connecting a BI application to Cube via our SQL API, we’re here with a quick tutorial using Tableau Online and Cube Cloud.

Let’s dive in. 

## Get started with Cube Cloud

This tutorial assumes you’re using Cube Cloud—and why wouldn’t you? Our managed service is both the fastest and most secure way to run Cube—and it’s free.

If you don’t have a Cube Cloud project already, [sign up for a free account here][12], then [follow these step-by-step instructions][11] to create a project. Don’t worry if you’d rather not connect your own database to Cube for this tutorial: we’ve got you covered with a sample database.

If you already have Cube Cloud set up, feel free to jump [here][95].

## Define measures and dimensions

When you create a project, you’ll notice that Cube automatically generates a basic data schema. But for this tutorial, let’s define at least one custom [measure][13] or [dimension][14] in Cube’s schema editor, too. You’ll use it in a few minutes.

In the left-hand navigation, select the schema editor and enter Development Mode.

In this example, in the cube `Orders`, we’ll define a new measure, `totalAmount`…

[![001-schema-define.png][1]][1]

…save our change, and Commit and Push it to production:

[![008-commit-and-save.jpg][15]][15]

The new definition is automatically added to Cube’s API, and you’re ready to…

## Grab SQL connection details

Navigate to the overview page and find the “SQL API” section. Click “How to connect your BI tool”.

[![002-sql-api.jpg][2]][2]

Here, you’ll find the details you need to connect Tableau Online to Cube:

[![003-grab-creds.jpg][3]][3]

You’ll need these when you…

## Configure Tableau

Let’s make a new Workbook using the menu at top right:

[![004-new.jpg][4]][4]

In the “Connect to Data” screen, select PostgreSQL.

[![009-connect-to-data.jpg][9]][9]

You’ll be prompted to add the connection details you opened in Cube. Copy, paste, and click “Sign In”.

<video width="100%" loop autoPlay muted playsInline poster="https://cubedev-blog-images.s3.us-east-2.amazonaws.com/37f7ace3-9b78-435d-9ff6-af329185d8f8.png"><source src="https://cubedev-blog-images.s3.us-east-2.amazonaws.com/b1b2ff0a-2863-4180-b312-bd730ece029b.mp4" type="video/mp4" /></video>

## Understand Tables and Fields

If all goes according to plan, you’ll now see a list of each of your [cubes][16] listed as _Tables_.

Drag one of them—we’ll use `Orders` again—into the Workbook editor to begin exploring.

<video width="100%" loop autoPlay muted playsInline poster="https://cubedev-blog-images.s3.us-east-2.amazonaws.com/58fc30aa-0531-4394-ac76-3eacf1ce5d6b.png"><source src="https://cubedev-blog-images.s3.us-east-2.amazonaws.com/89d4c3a1-604a-4af6-819b-5ca8cdc90d5d.mp4" type="video/mp4" /></video>

Et voila: now, every measure and dimension from Cube is available as a Tableau _Field_, including the custom measure we defined earlier, `totalAmount`.

[![006-tables-and-columns.jpg][6]][6]

## Build a worksheet

Now it’s time to try this out!

Build a simple chart in Tableau: drag a measure to “Rows” and a dimension to “Columns”:

<video width="100%" loop autoPlay muted playsInline poster="https://cubedev-blog-images.s3.us-east-2.amazonaws.com/c59a8e90-55ab-46c9-9ee0-11d3aaf3fcf1.png"><source src="https://cubedev-blog-images.s3.us-east-2.amazonaws.com/8c159a96-79b4-4674-a9d0-7ccf09cbf4e7.mp4" type="video/mp4" /></video>

Just like _that_: your first Cube-powered visualization in Tableau!

## Learn more

As you can see, connecting Tableau to Cube via Cube’s SQL API makes Cube definitions accessible to every data consumer—so the same data can flow to both business users and data application developers.

Interest piqued? Check out our [SQL API docs][93], and our [guide to working with other BI tools][94].

And, watch this space because the fun is just beginning: we’re continuing to test and improve connectors for more BI applications. Have a favorite? [Let us know][92].

[1]: https://cubedev-blog-images.s3.us-east-2.amazonaws.com/870c6c3e-42bc-4d0f-b978-807f5307906f.png
[2]: https://cubedev-blog-images.s3.us-east-2.amazonaws.com/0a7c2fd9-ae76-425b-906d-2f644ef77eff.png
[3]: https://cubedev-blog-images.s3.us-east-2.amazonaws.com/7831a318-a8f5-4d0c-9e7d-2d58671ab9fa.png
[4]: https://cubedev-blog-images.s3.us-east-2.amazonaws.com/64669cb0-78d2-4ad0-ab76-e1cdfae04453.png
[6]: https://cubedev-blog-images.s3.us-east-2.amazonaws.com/7057552d-01d6-4e2e-9bd0-c1936ff1e03a.jpg
[8]: https://cube.dev/blog/expanded-bi-support
[9]: https://cubedev-blog-images.s3.us-east-2.amazonaws.com/dd3de7cb-e553-41e4-afb4-129e0485124a.png
[11]: https://cube.dev/docs/product/getting-started/core/create-a-project
[12]: http://cubecloud.dev
[13]: https://cube.dev/docs/schema/reference/measures
[14]: https://cube.dev/docs/schema/reference/dimensions
[15]: https://cubedev-blog-images.s3.us-east-2.amazonaws.com/c264b798-c308-4e55-aedc-c8c62f414ed5.jpg
[16]: https://cube.dev/docs/schema/reference/cube
[92]: https://slack.cube.dev
[93]: https://cube.dev/docs/backend/sql
[94]: https://cube.dev/docs/config/downstream
[95]: #grab-sql-connection-details

Connecting Cube to Tableau tutorial

Apache Superset

Building dashboards over a semantic layer with Superset and Cube

In this tutorial, we'll learn how to build a metrics dashboard with Apache Superset, a modern and open-source data exploration and visualization platform. We'll also use Cube, an open-source metrics store, as the data source for Superset that will enable our dashboards to load in under a second — quite the opposite to what you'd usually expect from a BI tool, right?

Here's how the end result will look like:

![Screenshot 2021-11-24 at 05.04.36.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/11d780fa-b9b3-45d2-af61-e1f3ce270731.png)

Now we're all set. Let's see what's on the shelves of this metrics store 🏪

## What is Apache Superset?

[Apache Superset](https://superset.apache.org) is a data exploration and visualization platform or, in layman's terms, a tool that you can use to build dashboards with charts for internal users. Born at a hackathon at Airbnb back in 2015, with more than 41,000 stars on GitHub, now it's a leading open-source business intelligence tool.

Superset has connectors for numerous databases, from Amazon Athena to Databricks to Google BigQuery to Postgres. It provides a web-based SQL IDE and no-code tools for building charts and dashboards.

**Running Superset.** Now let's run Superset to explore these features. To keep things simple, we'll run a fully managed Superset in [Preset Cloud](https://preset.io), where you can use it forever for free on the Starter plan. (If you'd like to run Superset locally with Docker, please see [these instructions](https://github.com/cube-js/cube.js/blob/master/examples/superset/README.md#running-superset-locally).)

First, please proceed to the [sign up page](https://preset.io/registration/) and fill in your details. Note that Preset Cloud supports signing up with your Google account. Within a few seconds you will be taken to your account with a readily available workspace:

![Screenshot 2021-11-24 at 02.50.55.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/8cc1e93b-3cd2-4232-b723-8f3b99f42324.png)

Switching to that workspace will reveal a few example dashboards that you can review later.

![Screenshot 2021-11-24 at 02.54.51.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/91134cc7-13e7-46de-b924-75c606c9fbbd.png)

Now, let's navigate to `Data / Databases` via the top menu and... Oops! We need a metrics store to connect to. Let's see how Cube can help us build one.

## What is Cube?

[Cube](https://cube.dev/) is an open-source [metrics store](https://cube.dev/blog/introducing-cube-sql/) with nearly 12,000 stars on [GitHub](https://github.com/cube-js/cube.js) to date. It serves as a single source of truth for all metrics and provides APIs for powering BI tools and building data apps. You can configure Cube to connect to any database, define your metrics via a declarative data schema, and instantly get an API that you can use with Superset or many other BI tools.

**Running Cube.** Similarly to Superset, let's run a fully managed Cube in [Cube Cloud](https://cube.dev/product/why-cube-cloud) that has a free plan as well. (If you'd like to run Cube locally with Docker, please see [these instructions](https://github.com/cube-js/cube.js/blob/master/examples/superset/README.md#running-cube-locally).)

First, please proceed to the [sign up page](https://cubecloud.dev/auth/signup) and fill in your details. Note that Cube Cloud supports signing up with your GitHub account. Within a few seconds you will be taken to your account where you can create your first Cube deployment:

![Screenshot 2021-11-24 at 03.06.16.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/1ccba445-9cbf-4bb6-acfe-1e3c1d2fa325.png)

Proceed with providing a name for your deployment, selecting a cloud provider and a region:

![Screenshot 2021-11-24 at 03.21.33.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/28ad847d-10f6-47ed-8bf5-66a2b441eef3.png)

At the next step, choose `Create` to start a new Cube project from scratch. Then, pick `Postgres` to proceed to the screen where you can enter the following credentials:

```
Hostname:  demo-db-examples.cube.dev
Port:      5432
Database:  ecom
Username:  cube
Password:  12345
```

![Screenshot 2021-11-24 at 03.22.40.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/835c5600-7f79-44b3-81c1-3726a787c440.png)

Cube will connect to a publicly available Postgres database that I've already set up.

The last part of configuration is the [data schema](https://cube.dev/docs/schema/getting-started) which declaratively describes the metrics we'll be putting on the dashboard. Actually, Cube can generate it for us! Pick the top-level `public` database from the list:

![Screenshot 2021-11-24 at 03.22.55.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/c721028f-e20c-425c-900d-75b9f294a3bc.png)

In a while, your Cube deployment will be up and running:

![Screenshot 2021-11-24 at 03.24.31.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/5c39e57e-3311-4f40-9b89-8bc40d49df00.png)

**Defining metrics.** Please navigate to the "Schema" tab. You will see files like `LineItems.js`, `Orders.js`, `Users.js`, etc. under the "schema" folder.

![Screenshot 2021-11-24 at 03.25.51.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/8fb089b2-f33a-4795-9450-9f564dbd40d4.png)

Let's review `LineItems.js` which defines the metrics within the "LineItems" cube. This file is different from the one in Cube Cloud, but we'll take care of that later.

```jsx
cube(`LineItems`, {
  sql: `SELECT * FROM public.line_items`,

  measures: {
    count: {
      type: `count`
    },

    price: {
      sql: `price`,
      type: `sum`
    },

    quantity: {
      sql: `quantity`,
      type: `sum`
    },

    // A calculated measure that reference other measures.
    // See https://cube.dev/docs/schema/reference/measures#calculated-measures
    avgPrice: {
      sql: `${CUBE.price} / ${CUBE.quantity}`,
      type: `number`
    },

    // A rolling window measure.
    // See https://cube.dev/docs/schema/reference/measures#rolling-window
    revenue: {
      sql: `price`,
      type: `sum`,
      rollingWindow: {
        trailing: `unbounded`,
      },
    }
  },

  dimensions: {
    id: {
      sql: `id`,
      type: `number`,
      primaryKey: true
    },

    createdAt: {
      sql: `created_at`,
      type: `time`
    }
  },

  dataSource: `default`
});
```

Key learnings here:

- the cube is a logical entity that groups measures and dimensions together
- using the `sql` statement, this cube is defined over the entire `public.line_items` table; actually, cube can be defined over an arbitrary SQL statement that selects data
- measures (quantitative data) are defined as aggregations (e.g., `count`, `sum`, etc.) over columns in the dataset
- dimensions (qualitative data) are defined over textual, numeric, or temporal columns in the dataset
- you can define complex measures and dimensions with custom `sql` statements or references to other measures

**Development mode.** Now, let's update the schema file in Cube Cloud to match the contents above. First, click `Enter Development Mode` to unlock the schema files for editing. This essentially creates a "fork" of the Cube API that tracks your changes in the data schema.

Navigate to `LineItems.js` and replace its contents with the code above. Then, save your changes by clicking `Save All` to apply the changes to the development version of your API. You can apply as many changes as you wish, but we're done for now. Click `Commit & Push` to merge your changes back to the main branch:

![Screenshot 2021-11-24 at 03.33.47.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/85eeca4a-e85f-4109-8459-4dbde074d005.png)

On the "Overview" tab you will see your changes deployed:

![Screenshot 2021-11-24 at 03.37.57.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/5e7746a3-8839-47e3-bddc-a8b67460207a.png)

Now you can explore the metrics on the "Playground" tab:

![Screenshot 2021-11-24 at 03.41.38.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/df9a8062-4026-4476-8c65-b10e1360075e.png)

Good! We've built a metrics store that we can connect to Superset. How?

Please go back to the "Overview" tab and click `How to connect`. The "SQL API" tab will have a toggle that enables the API for Superset and other BI tools. Turning it on will provide you with all necessary credentials:

![Screenshot 2021-11-24 at 03.46.54.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/e2751eeb-c7bb-4f8d-9ff9-d6184097e9ce.png)

Now, let's build a dashboard!

## Building a dashboard in Superset

We'll need to go through a few steps:

- [connect Superset to Cube](https://cube.dev/docs/recipes/using-apache-superset-with-cube-sql)
- define the datasets
- create charts and add them to a dashboard

Let's go!

![Screenshot 2021-11-24 at 03.44.32.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/dee5d4cc-df2a-47a8-a812-9e54aef57e5d.png)

**Connect Superset to Cube.** Switch back to the workspace we've created earlier. Then, navigate to `Data / Databases` via the top menu, click `+ Database`, select `MySQL`, and fill in the credentials from your Cube Cloud instance — or use the credentials below:

- Host: `aquamarine-moth.sql.aws-us-east-2.cubecloudapp.dev`
- Port: `3306`
- Database name: `db`
- Username: `cube@aquamarine-moth`
- Password: `6300005f8da3ef74fa64a5bf9b1b6fcd`
- Display name: `Cube Cloud` (it's important)

![Screenshot 2021-11-24 at 03.53.07.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/42812095-82d4-4a65-a918-ab173c45689e.png)

You can press `Connect` now.

**Define the datasets.** Navigate to `Data / Datasets` via the top menu, click `+ Dataset`, and fill in the following credentials:

- Database: `Cube Cloud` (the one we've just created)
- Schema: `db`
- See table schema: `LineItems`

![Screenshot 2021-11-24 at 03.58.02.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/d8e50fc9-4df7-425b-b57b-f3904de984e0.png)

You can press `Add` now. Then, please repeat this for `Users` and `Orders`.

**Create charts and a dashboard.** We'll take a leap and create everything in a single step.

In Superset, you can export a dashboard with all charts as a JSON file and import it later. Navigate to `Dashboards` and click the link with an icon on the right:

![Screenshot 2021-11-24 at 04.01.31.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/e2ea0cbd-1cd0-439d-8c4d-a36d9e61b0c7.png)

Download [this file](https://raw.githubusercontent.com/cube-js/cube.js/master/examples/superset/acme-dashboard.json) to your machine, select it, and click `Import`:

![Screenshot 2021-11-24 at 04.02.38.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/5256114e-d4a4-4e4d-96b0-137aee522bcb.png)

Whoa! Now we have a complete dashboard for Acme, Inc. Click on it to view:

![Screenshot 2021-11-24 at 05.04.36.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/11d780fa-b9b3-45d2-af61-e1f3ce270731.png)

Looks nice, doesn't it? Let's explore what's under the hood and how you can build it on your own.

## Diving deep into Superset

**Anatomy of a dashboard.** You can see that charts on the dashboard are aligned by the grid. To rearrange them, click on the pencil icon in the top right corner. You can add tabs, headers, dividers, Markdown blocks, etc. Of course, you can also add charts.

![Screenshot 2021-11-24 at 05.06.41.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/f8905469-8f64-4e3d-85d0-e7ae283673f3.png)

**The simplest chart.** Navigate to `Charts` via the top menu and click on any chart with the `Big Number` visualization type, e.g., Customers. In my opinion, that's the simplest chart you can create in Superset. It contains a single metric, and I doubt a chart can get simpler than that.

![Screenshot 2021-11-24 at 05.07.29.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/afde957b-bdc9-4083-a704-11006c8805f1.png)

Let's dissect how a chart is defined:

- Visualization type: `Big Number` — that's where you can select or change the chart type
- Time column: `createdAt` — interestingly enough, any chart should have this time column defined even if the displayed data has no temporal components
- Metric: `COUNT(*)` — that's the most important part of any chart configuration; upon clicking on this metric, you'll see that you can either select a saved definition, "simply" select a column and an aggregation, or write a "custom SQL" expression

When all config options are set, press `Run` to fetch the data, then `Save` to persist a chart or add it on a dashboard (no need to do it now, it's already added).

**A less simple chart.** Navigate to `Charts` via the top menu and click on any chart with the `Big Number with Trendline` visualization type, e.g., Revenue. Still, it contains a single metric as well as a sketchy chart in the bottom.

![Screenshot 2021-11-24 at 05.08.31.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/103ea21b-ef9b-4e17-b9a9-580d24a271b1.png)

Let's dissect how this chart is defined (only new options):

- Time grain: `Month` — defines the temporal granularity for metrics calculations
- Time range: `Last year` — specifies the date range for this chart
- Metric: `revenue` — it's interesting; click on this metric to learn that it's defined using "custom SQL"; that's because the aggregation has already been performed by Cube, no need to aggregate aggregated values, right?

**Other charts.** Actually, now you know everything you need to explore and dissect other charts. Just keep in mind that Superset has plenty of customizations you can apply to charts — see the "Customize" tab for inspiration.

![Screenshot 2021-11-24 at 05.09.15.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/eec079db-5c09-42be-822e-5ab583ce016d.png)

**Viewing SQL.** For any chart, you can reveal the SQL query to Cube which is generated by Superset to fetch the data. Press the burger button (with triple horizontal lines) in the top right corner, then `View query`. Good ol' SQL, nice:

![Screenshot 2021-11-24 at 05.09.42.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/68e680a9-3826-4597-8e21-934f901779c3.png)

Also, if you wanna use the aforementioned SQL IDE, navigate to `SQL Lab / SQL Editor` via the top menu.

## Making business intelligence fast ⚡

There's only one thing left to explore, but it's a huge one.

Let's navigate back to the Acme, Inc. dashboard. It takes 2-3 seconds to load, and the infinity-shaped spinners are clearly visible. They are not annoying, but honestly — wouldn't you like this dashboard to load instantly? Yep, well under a second.

Cube provies an out-of-the-box [caching layer](https://cube.dev/docs/caching) that allows to pre-compute and materialize the data required to serve the queries. All you need to do is define which queries should be accelerated. It's done declaratively in the data schema files. (Please also note that Superset has its own lightweight [caching layer](https://superset.apache.org/docs/installation/cache) that might be handy in cases when you need to push your Cube + Superset to the limit.)

Please go back to your Cube Cloud instance, enter the development mode, switch to the "Schema" tab, and update your data schema files with small snippets as follows.

First, `LineItems.js` should look like this:

```jsx
cube(`LineItems`, {
  sql: `SELECT * FROM public.line_items`,

  // Copy me ↓
  preAggregations: {
    main: {
      measures: [ CUBE.count, CUBE.revenue, CUBE.price, CUBE.quantity ],
      timeDimension: CUBE.createdAt,
      granularity: 'day'
    }
  },
  // Copy me ↑

  measures: {
    count: {
      type: `count`
    },

  ...
```

Second, `Orders.js` should look like this:

```jsx
cube(`Orders`, {
  sql: `SELECT * FROM public.orders`,

  // Copy me ↓
  preAggregations: {
    main: {
      measures: [ CUBE.count ],
      dimensions: [ CUBE.status ],
      timeDimension: CUBE.createdAt,
      granularity: 'day'
    }
  },
  // Copy me ↑

  measures: {
    count: {
      type: `count`
    },

  ...
```

Lastly, `Users.js` should look like this:

```jsx
cube(`Users`, {
  sql: `SELECT * FROM public.users`,

  // Copy me ↓
  preAggregations: {
    main: {
      measures: [ CUBE.count ],
      dimensions: [ CUBE.city, CUBE.gender ]
    }
  },
  // Copy me ↑

  measures: {
    count: {
      type: `count`
    }

  ...
```

Don't forget to click `Save All`, then `Commit & Push`, and check that your changes were deployed at the "Overview" tab. In the background, Cube will build the necessary caches.

It's time to get back to your dashboard and refresh it. Now refresh it one more time. See? The dashboard loads in under a second. ⚡

Of course, you have plenty of options to fine-tune the caching behavior, e.g., specify the [cache rebuilding schedule](https://cube.dev/docs/caching/using-pre-aggregations#refresh-strategy).

## Wrapping up

Thanks for following this tutorial. I encourage you to spend some time [in the docs](https://superset.apache.org/docs/intro) and explore other features of Apache Superset. Also, please check out Preset docs that are packed with great content, e.g., on [creating charts](https://docs.preset.io/docs/create-a-chart).

**Also, thanks for learning more about building a metrics store with [Cube](https://cube.dev/). Indeed, it's a very convenient tool to serve as a [single source of truth for all metrics](https://cube.dev/blog/introducing-cube-sql/).**

Please don't hesitate to like and bookmark this post, write a comment, and give a star to [Cube](https://github.com/cube-js/cube.js) and [Superset](https://github.com/apache/superset) on GitHub. I hope these tools would be a part of your toolkit when you decide to build a metrics store and a business intelligence application on top of it.

Good luck and have fun!

Building a metrics dashboard with Superset and Cube

Today, Cube powers analytics features inside thousands of applications where developers have leveraged Cube’s data schema as a **metrics layer**—a consistent, single source of truth. By powering a single repository of metrics, Cube helps developers quickly and reliably ship embedded analytics features and other data-powered applications with the peace of mind that their metrics definitions remain consistent.

Cube solves this problem very well for application developers, but it’s been unsolved for users of dashboards and business intelligence tools, and the data engineering teams that support them.

In most modern organizations, there are multiple tools that consume data from the same single warehouse but perform their own downstream metrics calculations. This leads to inconsistent calculations and disagreements between teams: **How do we calculate revenue? Does it include revenue from X cohort? How do monthly payments affect annual projections?**

The more tools an organization uses, the more inconsistencies and conflicts arise, and the harder it is for a business to make decisions using accurate data. To avoid this, they need a centralized, upstream location in which to build and maintain their metrics, so that every tool works from the same source of metric truth.

Today, I’m excited to share a way for Cube to function as a metrics store for any data consumer: we’re proud to announce the new [Cube SQL API](https://cube.dev/docs/backend/sql/). With the addition of this API, Cube now functions as a headless BI layer to provide consistent metrics to any querying and visualization tool.

![](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/ebff03e0-fbcd-4941-9a3c-cc71b6142561.png)

## How it works

In the modern [data stack](https://cube.dev/product/data-apis), Cube acts as a proxy for data warehouses and translates every incoming query, whether it is JSON, GraphQL, or SQL, into native queries to the underlying data storage.

![](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/7bf46e5f-f4b8-4f2a-a236-c067ff894d86.png)

Cube translates queries by using a JSON-based data modeling layer consisting of cubes. Think of these as database views, backed by either a reference to an existing database table or a new table created by SELECT statement. Cubes contain defined measures and dimensions.

**Measures** are quantitative data, such as the number of units sold, unique visits, profit, and so forth. **Dimensions** are categorical data, such as state, gender, product name, or units of time. (You can learn more about Cube’s [data schema](https://cube.dev/docs/schema/getting-started) in the docs.)

Below is an example of the cube we can use to describe metrics about leads for a sales organization.

```javascript
cube(`Leads`, {
  sql: `
    SELECT
      persons.id,
      persons.created_date,
      deals.id as deal_id
    FROM persons
      LEFT JOIN deals ON deals.person_id = persons.id
  `,

  title: `Leads`,
  description: `Leads for Insides Sales`,

  measures: {
    count: {
      type: `count`
    },
    converted_to_deal_count: {
      type: `count`,
      filters: [
        { sql: `(${is_converted_to_deal}) = true` }
      ]
    },
    to_deal_conversion_rate: {
      type: `number`,
      sql: `ROUND(${converted_to_deal_count} / NULLIF(${count}, 0) * 100, 2)`,
      format: `percent`
    }
  },

  dimensions: {
    time: {
      sql: `created`,
      type: `time`
    },
    is_converted_to_deal: {
      type: `boolean`,
      sql: `deal_id IS NOT NULL`
    }
  }
})
```

With the above definitions of our metrics we can ask questions like **"What is our monthly lead-to-deal conversion rate over the last year?"**

When we query Cube’s metrics layer via the SQL API, cubes will be presented as tables and measures and dimensions as columns. To answer the above question with SQL we need to write the following query:

```sql
SELECT DATE_TRUNC('month', time),
       to_deal_conversion_rate
FROM leads
WHERE time >= '2021-01-01'
  AND time < '2022-01-01'
GROUP BY 1
```

Cube will translate this query into the query for the underlying database.

```sql
SELECT
  DATETIME_TRUNC(
    DATETIME(created_date, 'UTC'),
    MONTH
  ) `leads__time_month`,
  ROUND(
    count(
      CASE WHEN ((deal_id IS NOT NULL) = true) THEN 1 END
    ) / NULLIF(count(*), 0) * 100,
    2
  ) `leads__to_deal_conversion_rate`
FROM
  (
    SELECT
      persons.id,
      persons.created_date,
      deals.id as deal_id
     FROM persons
      LEFT JOIN deals ON deals.person_id = persons.id
  ) AS `leads`
WHERE
  (
    created_date >= TIMESTAMP('2021-01-01T00:00:00.000Z')
    AND created_date <= TIMESTAMP('2021-12-31T23:59:99.999Z')
  )
GROUP BY
  1
ORDER BY
  2 DESC
LIMIT
  10000
```

You can query Cube with SQL from your favorite programming language, such as Python.

![](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/2b0d23c8-37fa-4550-8c99-53196c832a26.gif)

Most powerfully, because the Cube SQL API speaks MySQL-compatible SQL, you also can connect your favorite BI tool—like Superset, Metabase, or Tableau—directly to Cube, and let Cube generate SQL to fetch and display data. Here’s an example of using Superset with the Cube SQL API.

![](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/a775a871-8e89-451c-afb1-671b6dd22e3f.png)

You can check our documentation for the full [Superset integration tutorial](https://cube.dev/docs/recipes/using-apache-superset-with-cube-sql).

## Built-in relational cache

Every query can leverage Cube’s pre-aggregations layer—a database-agnostic materialization engine—in order to make dashboards and reports load in milliseconds instead of minutes.

While defining metrics, developers can specify which metrics they want to pre-aggregate. Cube will run complex calculations beforehand in the background and will create a cache table with the results. All queries will be served from this cache table, dramatically increasing dashboards’ performance.

## Where we go next

We’re excited about today’s launch, but it is only the beginning of the journey!  We’re committed to supporting all the major SQL operations, and improving error handling to provide more useful tips to users. Please let us know in our Slack channel if you see something that is not working as you expected.

Everything described here is available Cube Core, licensed under Apache 2.0. In addition, we're working on cataloguing and collaboration tools for the Cube metrics layer in Cube Cloud, our fully-managed Cube service. Watch this space.

If you’re interested in learning more, [please give us a try.](https://cubecloud.dev/auth/signup)

Introducing the Cube SQL API: Building Metrics Stores with Cube

Nakshatra Mukhopadhyay

Data Visualization

Tableau-like Charts with MuzeJS, Cube, and React

We recently covered how to build an analytics dashboard using react, vue, or angular. But if you don't want to code and host your own dashboard, you have some open-source alternatives. Today I'll show you how to build an analytics dashboard using [Cube](https://cube.dev) Backend and [Redash](https://redash.io/).
You can find the resulting dashboard live [here](https://app.redash.io/statsbot/public/dashboards/Wq8iPcQwYDGTF3GqMSAQGP10Mg6mgTxl1r5C6MKH).

![Dashboard](https://media.graphcms.com/XVo6igwnQy25V6dHDWXp)

## Why Cube?
You can always connect Redash directly to your database. You can then write queries in pure SQL and build the same dashboard. It's easy to manage if you have one dashboard and just a couple of queries. But usually, a small dashboard is just a first step in building a complex analytics solution. As your business grows, your volume of data also grows. And soon, you may find a hundred dashboards with thousands of queries used by multiple departments. Now imagine you changed a column in the database. All of the queries should be checked and updated.

Another problem may be the data volume. Say you have a large dashboard powered by some complex queries that take some time to execute. Once you change a filter value on that dashboard, all queries will get executed on the database. In a simple case, it may take a long time to update the dashboard, but if you're using a per-query billed database like Google Bigquery or AWS Athena, this will also hit your monthly bill. 

Cube solves both of these problems. The queries used in Redash may be updated independently, so updating a column name or adding a join condition is a simple update in the data schema file. Also, Cube.js Backend manages [pre-aggregations](https://cube.dev/blog/high-performance-data-analytics-with-cubejs-pre-aggregations/), which helps with loading lots of data fast and efficiently. Cube pre-aggregates data for huge queries in separate tables and updates them in the background. This is efficient in terms of performance and cost. [Here](https://cube.dev/docs/guides/recipes/code-reusability/schema-generation) you can find a guide on Cube Data Schema to understand core concepts better.

## Setting up Cube Backend

To launch a Cube Backend, you'll need to provide a database where your analytics data is stored and a hosting option. In this demo, we'll use Postgresql database with our demo dataset. If you don't have access to your analytics database right now, you can use this dataset:

```bash
curl http://cube.dev/downloads/ecom-dump.sql > ecom-dump.sql
createdb ecom
psql --dbname ecom -f ecom-dump.sql
```

Now when you have your database running, we have to choose a deployment option. For this demo, we'll host our backend on [Heroku](https://heroku.com/). There's a guide for other deployment options in the [documentation](https://cube.dev/docs/deployment).

Let's install `cubejs-cli` and create a new Cube.js app:

```bash
npm install -g cubejs-cli
cubejs new redash-demo -d postgres
cd redash-demo
```

Now we have to set a data model. For this demo, we'll define only one cube and skip advanced options, which are covered in the [documentation](https://cube.dev/docs/product/data-modeling/overview).

```javascript
cube(`Users`, {
  sql: `SELECT * FROM users`,

  measures: {
    count: {
      sql: `id`,
      type: `count`
    }
  },

  dimensions: {
    city: {
      sql: `city`,
      type: `string`
    },

    signedUp: {
      sql: `created_at`,
      type: `time`
    },

    companyName: {
      sql: `company_name`,
      type: `string`
    }
  }
});

```

Now when we have our data model set we can deploy this app to Heroku:

```bash
git init
git add -A
git commit -am "Initial commit"
heroku create cubejs-redash-demo
git push heroku master

```

## Creating a Redash Dashboard

To use Cube Backend with Redash, you need to create a [JSON Data Source](https://redash.io/help/data-sources/querying/urls).

Once you've done that, you can create a query. There are a couple of options like URL and Authorization Headers that will be shared across all of the queries, so you can create one query and then fork it to create others. Here's a simple query that will count all Orders in our demo dataset:

```yaml
url: "YOUR-CUBEJS-URL/cubejs-api/v1/load"
headers: 
    Authorization: YOUR-API-TOKEN
path: data
params:
    query: '{"measures": ["Orders.count"]}'
```

Here you need to provide your API URL, which depends on the deployment option you chose. Also, you need to create an [API Token](https://cube.dev/docs/security) to authenticate requests. 
Now click "Save" and "Execute." You should get a response that looks like this:

![Query results](https://media.graphcms.com/8gWHLswcSBKExUAsNVzV)

Now you can add a visualization. For this query, we'll use a simple "counter" option:

![Counter](https://media.graphcms.com/ZpZ50RTD6ghE0V1X3SlA)

Let's create a more sophisticated query. We'll create a Stacked Bar Chart for the orders. First, let's define the query: 

```yaml
url: "https://awesome-ecom.gcp-us-central1.cubecloudapp.dev/cubejs-api/v1/load"
headers: 
    Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.e30.K9PiJkjegbhnw4Ca5pPlkTmZihoOm42w8bja9Qs2qJg
path: data
params:
    query: '{
      "measures":["Orders.count"],
      "dimensions":["Orders.status"],
      "timeDimensions":[{"dimension":"Orders.createdAt",
        "dateRange":["2017-01-01","2018-12-31"],
        "granularity":"month"
      }]
}'
```

Save and execute the query and you'll get a table, which is the default visualization. Let's create a Bar Chart:

![Stacked Bar Chart](https://media.graphcms.com/3GcT1LjVQaqqHNybhp3e)

Now we have enough queries to create a dashboard. Click "Create" -> "Dashboard," choose a name, and go ahead adding your query widgets.

And the dashboard is done!

## Setting Filters

There's also a Redash option called Parameters. We can set some query values using it. Let's add a daterange filter to our queries:

```yaml
url: "https://awesome-ecom.gcp-us-central1.cubecloudapp.dev/cubejs-api/v1/load"
headers: 
    Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.e30.K9PiJkjegbhnw4Ca5pPlkTmZihoOm42w8bja9Qs2qJg
path: data
params:
    query: '{"measures":["Orders.count"],
        "timeDimensions": [{
          "dimension" : "Orders.createdAt",
          "dateRange": ["{{ daterange.start }}","{{ daterange.end }}"]
        }]
    }'
```

You can see we've added params using the `{{ }}` expression. Now let's change the parameter type to daterange:

![Daterange Filter](https://media.graphcms.com/Xi0H6jBPSdW6GuOtwDwN)

Click "Save" and "Execute." Now this query has a daterange filter. You can add other parameters to the query in the same manner. Also, you can set multiple queries to use one dashboard-level filter value using the "edit Parameters" menu. Here's an example:

![17wbnsakge7l603k5sbr.png](https://media.graphcms.com/2mhGyZOLR0KAUxa1rFli)

And it's done! Now we have a live dashboard in Redash, which you can publish, query, or even run on a display with auto-update.