Full Review of Cube - by ajo - Strata Business Intelligence

SubscribeSign in

Full Review of Cube<br>We put Cube.dev through its paces against AWS Athena — modeling 27 tables, breaking the semantic layer on hard measures, building dashboards, and testing its AI agents

ajo<br>Jul 22, 2026

Share

Disclosure: Strata competes with Cube — we're building a semantic layer of our own — so treat this as an informed but interested take. Our sharpest criticisms (the view layer as an access point, and pushing calculations to runtime instead of the model) happen to be areas where we've made a different design bet. That's not an accident, and you should weigh it accordingly. The goal of this series is to understand the market and bring you along

Getting Started

This was going to be a pure semantic layer as middleware review of Cube. But it turns out Cube has evolved (pivoted?) to include workbooks, dashboards, and AI chat interfaces. They are basically a full BI solution now.<br>Read my recent gloating on how this was inevitable and correct.

Semantic Layer Middleware is Not Enough<br>ajo<br>Jul 16

Read full story

For the semantic layer we used the open source package via docker. Simple docker run command and your off to the races. When you access the UI it walks you through the process of connecting your database and generating models with default configurations from your db. The models are defined in YAML files or Javascript. We opted for YAML. These files are mounted in your local directory and you can directly edit them from any IDE. After an edit the model is instantly available on the server. No long setup process. No user account management barriers. No edit → deploy cycles. You go from docker run to seeing your models in the UI rapidly.<br>While this is great we did wonder about the ability to have multiple branches in production. This becomes important during migrations or major changes. There is no built in test automation for the models. Versioning will exclusively be done via git.<br>Once your model files are created they are instantly accessible in the playground UI. This is where we did most of our semantic capabilities test. I believe the semantic layer in the open source version and cloud are identical in capabilities.<br>Note on Cube Cloud<br>We did not use the cloud version for model development. Cloud has an IDE environment to edit and manage your model files. Additionally, as far as we can tell the Cube CLI is meant to deploy local projects to the cloud. No additional functionality was reported on the doc sites.

Review Setup

We are testing Cube and other BI tools against our AWS Athena data warehouse. Its loaded with a small sample size TPC-DS data model. Our objective with this review and other BI tool reviews is to see how much self service can be enabled for non technical users. How many personas are involved in maintaining this tool in a well functioning analytics deployment?<br>Semantic Layer

There are two types of main model files in Cube: Cubes and Views. Cubes tend to map one to one with a table. However, it is possible to model multiple cubes in a single model file. I would assume best practice is one model file equals one table in the target database. Views reference cubes to create a curated access layer for users to interact with the underlying models. This is similar in functionality in many ways to how Looker models and explores work.<br>Here is a truncated cube definition for our catalog_sales fact table:<br>cubes:<br>- name: catalog_sales<br>sql_table: tpcds.catalog_sales_new<br>data_source: default

joins:<br>- name: date_dim<br>relationship: many_to_one<br>sql: "{CUBE}.cs_sold_date_sk = {date_dim}.d_date_sk"<br>...

dimensions:<br>- name: cs_order_number<br>sql: cs_order_number<br>primary_key: true<br>type: number

measures:<br>- name: catalog_sales_count<br>type: count

- name: cs_quantity<br>sql: cs_quantity<br>type: sum

...

A cube model consists of joins, measures, dimensions, and any pre aggregations ( more on this later ). Joins here are meant to be a path length of one. I.e. from fact table to a dimension table. At query time it will resolve full join paths up an entire hierarchy (table a → table b → table c …). When you have join path ambiguity or any issues in join construction you need to use a view to resolve.<br>We manually modeled a handful of tables and then used Claude to create the rest using an existing Strata model as a template. This went pretty fast for about 27 tables total. Once this is done you can use the playground UI to build and execute queries. One thing to note at least in this UI, there is no awareness of what a legal query is. You can easily create illegal queries and get a “can’t find join path” error. We will explore query building in more detail in the Dashboards section below.

Subscribe

Cross Domain Data Blending

Cube call these multi fact views. As you guessed you need a view for every combination of cross fact queries. Although the docs recommend only adding facts with common dimensions it is possible to add...