In the recent update to [Cube Cloud](https://cube.dev/product/why-cube-cloud), we focused on the workspace and introduced or updated the tools for building data models and optimizing query performance: *Query History* and *SQL Runner*. On top of that, we added a few visual touches to make the time you spend in the Cube Cloud workspace more enjoyable.

All features in this update are available in Cube Cloud for users on [all tiers](https://cube.dev/pricing), including free development instances.

## SQL Runner

In Cube Cloud, we strive to provide a complete set of tools for building and operating semantic layers. We also know that authoring data models is a [thorough](https://cube.dev/blog/cube-core-v0-33-data-modeling-update) and iterative process: exploring the data, defining a metric, reviewing the result, and repeating until ready. Now, with [SQL Runner](https://cube.dev/docs/cloud/sql-runner), you can perform all these steps within the Cube Cloud workspace.

Available from the side menu, SQL Runner allows running arbitrary SQL queries against any of configured [data sources](https://cube.dev/docs/config/databases). You can explore the database schema and preview raw data in SQL Runner, author the data model in [Cube IDE](https://cube.dev/docs/cloud/workspace/cube-ide), and run queries in [Playground](https://cube.dev/docs/dev-tools/dev-playground) to validate the result. If needed, copy the generated SQL query from Playground to SQL Runner or find the query in Query History and click <Btn>Open in SQL Runner</Btn>. Of course, you’re still free to use your favorite Worksheets in Snowflake or SQL Workspace in BigQuery; however, SQL Runner might be a great alternative when working in the Cube Cloud workspace.

Here’s how SQL Runner works:

<video width="100%" controls><source src="https://ucarecdn.com/8cbdd639-e86b-4190-bbaa-37122c39bc01/video.mp4" type="video/mp4"/></video>

Sometimes, data source configuration is dynamic and depends on the incoming query and its [security context](https://cube.dev/docs/security/context); for instance, when [multitenancy](https://cube.dev/docs/config/multitenancy) is used. SQL Runner will recognize [pre-configured security contexts](https://cube.dev/docs/config#options-reference-scheduled-refresh-contexts) and also let you provide a custom one. Conveniently, Cube Store is available for querying as yet another data source, so you can inspect the contents of pre-aggregations.

## Query History

With Cube, you can build fast and responsive data experiences for end users. To support that, we’ve released the updated [Query History](https://cube.dev/docs/cloud/inspecting-queries) in Cube Cloud, available from the side menu and formerly known as *Queries*. Every query is analyzed and visualized in Query History with charts, performance metrics, and specialized representations like [flame graphs](https://www.datadoghq.com/knowledge-center/distributed-tracing/flame-graph/) to help you with the following tasks:
Getting a high-level understanding if your queries run fast enough.
Finding those ones that require optimization and fine-tuning.
Understanding the root cause and performing optimization.

Query History provides visibility both into incoming queries (e.g., from BI tools or data applications) and queries that Cube subsequently runs against data sources. You can watch queries live or review the last 72 hours of historical data; analyze the high-level picture or drill down into a particular query.

See Query History in action:

<video width="100%" controls>
  <source src="https://ucarecdn.com/ceba0bdc-298b-44e6-8491-2b0e39985465/video.mp4" type="video/mp4"/>
</video>

Frankly, even with the best tooling available, analytical query performance is an exceptionally complex topic. __In a few weeks, we’ll be hosting a webinar to demonstrate how Query History and other Cube Cloud features can be leveraged to help you analyze and optimize query performance. [Register today](https://cube.dev/events/analyzing-and-optimizing-query-performance-with-cube).__

## Renaming tabs in Playground

If you’ve ever run queries in Cube Cloud, you probably noticed that Playground preserves open [query tabs](https://cube.dev/docs/dev-tools/dev-playground#query-tabs) so you can resume your work when needed. However, it’s not very evident that you can also double-click a query tab to give it a meaningful name instead of something like “Query 2.”

<video width="100%" controls><source src="https://ucarecdn.com/9e3d7651-4dca-4cd3-9fc9-541c3182effd/video.mp4" type="video/mp4"/></video>

This way, queries to your semantic layer will be even more semantic 😜

## Dark mode

This feature would make the Cube Cloud workspace more enjoyable for some of you—and make no difference for the rest. Now, you can enjoy the dark theme that can be [configured](https://cube.dev/docs/workspace/preferences) to match system settings or be always on.

<video width="100%" controls><source src="https://ucarecdn.com/b7ded0d1-fc4a-469c-8c38-59b3136b18f7/video.mp4" type="video/mp4"/></video>

However, we’re not leaving you in the dark 🙃 

## What’s next in Cube Cloud

We’re focused on making the Cube Cloud workspace even more powerful. So, please stay tuned for the upcoming updates that we’ll be publishing in the [Changelog](https://cube.dev/blog/category/changelog).

You can try Query History, SQL Runner, Playground, and the dark mode today. Sign up for [Cube Cloud](https://cubecloud.dev/auth/signup) for free and see them in action.

We’re always happy to hear your feedback. Please don't hesitate to [get in touch](https://cube.dev/contact) or reach out in our [Slack community](https://slack.cube.dev) of more than 8,000 data practitioners.

There’s one more thing. **We’re running a survey to better understand how you do data engineering and use Cube Cloud.** 5 minutes spent by you filling this survey will mean a world to us; please take a moment to [share with us what you think](https://forms.gle/b7iQHpocAXfpNfeR7).

Igor Lukanin

Changelog

Better workspace tools for optimizing query performance and building data models

Cube Cloud update — Query History, SQL Runner

In the recent v0.33 release of [Cube Core](https://github.com/cube-js/cube), we focused on improving the data modeling experience and conventions in Cube. We've been receiving consistent requests for additional conventions and a more pronounced *Cube way of data modeling*.

Based on feedback and observations of data modeling patterns across various use cases, we've made changes to Cube's data modeling. These revisions promote best practices to enhance consistency across different Cube projects, and establish a foundation for future conventions.

In addition, we're introducing a [Cube style guide](https://cube.dev/docs/style-guide) that we'll use across documentation, examples, learning materials, and customer engagements. This will help make our materials consistent and easier to maintain. We are making our style guide public and recommend that the Cube community follows it.

There are no breaking or backward-incompatible changes in the v0.33 release.

## Snake case naming convention

Six month ago, we [introduced YAML syntax](https://cube.dev/blog/introducing-cube-support-for-yaml-data-modeling) for data modeling in Cube; its adoption has been growing rapidly. YAML syntax provides a way to write concise data model files without too many quotes, backticks, and braces. 

The problem was, the [`camelCase`](https://en.wikipedia.org/wiki/Camel_case) name convention—which has been used in Cube since the very beginning—didn’t play nice with YAML. Considering that, we’ve decided to go with [`snake_case`](https://en.wikipedia.org/wiki/Snake_case) as a default naming convention across both JavaScript and YAML models.

We know that some of you may prefer to keep using `camelCase`, and that’s why we're going to support all definitions in both `snake_case` and `camelCase`. However, for the documentation, examples, and data model generation, we’ll use the `snake_case` moving forward.

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

    joins:
      - name: orders
        sql: "{CUBE}.order_id = {orders.id}"
        relationship: many_to_one

    measures:
      - name: count
        type: count

      - name: total_amount
        sql: price
        type: sum

    dimensions:
      - name: id
        sql: id
        type: number
        primary_key: true

      - name: created_date
        sql: created_at
        type: time
 ```

 ## Schema is now called data model

We've been using the terms "data model" and "schema" interchangeably for quite some time. Moving forward, we will use the term "data model" instead of "schema" to ensure clarity and consistency. The term "schema" could be confused with a database schema—hence the change in terminology.

With that change, we're also introducing a [conventional folder structure](https://cube.dev/docs/data-modeling/syntax) for Cube projects. Views are becoming a crucial component of Cube's data modeling, serving as data marts to expose slices of your data graph to BI tools and data applications via APIs. Therefore, they need to have their own designated folder within the project structure.

```tree
model
├── cubes
│   ├── base_orders.yml
│   └── base_customers.yml
└── views
    └── orders.yml
```

Cube will now automatically generate a `model` folder with `views` and `cubes` subfolders inside. If you're using a `schema` folder to keep your data model, it will continue to work.

## Conventional names for join relationships

In the v0.33 release, we are renaming [join relationships](https://cube.dev/docs/schema/reference/joins#parameters-relationship) to use widely adopted terminology: `one_to_many`, `many_to_one`, and `one_to_one`. As with all changes in this release, it's not a breaking change, and the previous names can still be used.

As a reminder, Cube always uses `LEFT JOIN`, and join relationships are used to avoid fanouts when generating SQL to query upstream data sources.

## Syntactic sugar for cube definitions

Often, cubes are backed by entire tables in upstream data sources and defined with fairly typical `SELECT *` one-liners. And so, we're introducing the [`sql_table` parameter](https://cube.dev/docs/schema/reference/cube#parameters-sql-table) to help define such cubes in a more concise way.

```yaml
cubes:
  - name: orders
    sql: SELECT * FROM my_schema.orders

# Now this can be written as:

cubes:
  - name: orders
    sql_table: schema.orders
```

## Update to views

Views are used to expose slices of your data graph and act as data marts. You control which measures and dimensions are exposed to BI or data apps and the direction of joins between exposed cubes.

![](https://ucarecdn.com/bfc3e04a-b690-40bc-a6f8-14a9175fb4fd/)

In the v0.33 release, we're introducing the `cubes` parameter in views to include exposed cubes in bulk. You can build your view by combining multiple joined cubes together and specifying the path by which they should be joined for that particular view. You can learn more about views [in the documentation](https://cube.dev/docs/schema/reference/view).

```yaml
views:
  - name: pages

    cubes:
      - join_path: web_pages
        includes: *
        excludes:
          - session_id

      - join_path: web_pages.web_sessions
        alias: sessions
        prefix: true
        includes:
          - start_date
          - duration
          - exit_path
          - is_first

      - join_path: web_pages.web_sessions.web_users
        alias: users
        prefix: true
        includes:
          - city
          - company
          - age
          - name: ltv
            alias: life_time_value
```

## Unified visibility control

We've unified visibility management across cubes, views, measures, dimensions, and segments with the [`public` parameter](https://cube.dev/docs/schema/reference/cube#parameters-public). The default value is `true`, meaning that all these elements are public, available through APIs, and visible to data consumers by default. However, you can hide some of them by setting this parameter to `false`.

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

You can also use `COMPILE_CONTEXT` for dynamic visibility if necessary.

```yaml
views:
  - name: arr
    description: Annual Recurring Revenue
    public: COMPILE_CONTEXT.security_context.has_finance_role

    includes:
      - customers.plan
      - revenue.arr
      - revenue.date
```

Private cubes and their members are now available in [Playground](https://cube.dev/docs/dev-tools/dev-playground). They will have a lock icon to indicate that they are private and not accessible via APIs.

![](https://ucarecdn.com/c666ea6b-627b-465b-987b-5863ff2534ee/)

As usual, the detailed changelog is [available on GitHub](https://github.com/cube-js/cube/blob/master/CHANGELOG.md).

## What’s next in Cube Core

You may have noticed that the Cube configuration file is still only in camelCase. In version 0.34, we will support snake_case in the configuration file, and we will also introduce initial Python support for configuration. Consequently, it will be possible to write the configuration entirely in Python in a `cube.py` file. Moreover, this release will bring dynamic data models in YAML with Jinja and Python.

You can try the new v0.33 release today in Cube Core with our Docker distribution. It's also available on the latest release channel in [Cube Cloud](https://cubecloud.dev/auth/signup).

As always, please don't hesitate to [get in touch](https://cube.dev/contact) with us and share your feedback in our [Slack community](https://slack.cube.dev) of more than 8,000 data practitioners.

Artyom Keydunov

Better data modeling experience for building maintainable semantic layers

Cube Core v0.33 — Data Modeling Update 

As businesses collect more and more data from users, customers, and partners, the need for secure data access becomes ever more significant. 

Think of it like this: if you don’t have tight controls on who has access to your valuable data, then anyone could potentially view or even modify it. Essentially, exactly why security and authentication in a semantic layer are vital to protecting your—or your users’—data.

So, let’s talk about how semantic layers help implement tighter data security. We’ll also explore the importance of multitenancy, authentication tokens, and data access controls in general (both row-based and column-based) as they relate to HIPAA and SOC 2 compliance. 

## What is a Semantic Layer?

Simply put, a semantic layer is a layer of abstraction that sits between the user interface (UI) and the underlying database of a data application. And, IOHO (in our humble opinion), a good semantic layer—or rather, [a complete, universal semantic layer](https://cube.dev/)—should do more than only metrics definitions. 

Its duties encompass data modeling, sure—ensuring that software engineering best practices such as the DRY principle are being employed in metrics orchestration to organize and make data across the stack consistent. 

However, a semantic layer should also include a [caching layer](https://cube.dev/product/caching-and-data-performance) to speed up and application performance and make querying cost-effective. 

Also in the requirements for a good semantic layer? An [API layer](https://cube.dev/product/data-apis) to maintain complete data accessibility across a flexible stack. 

And lastly—but certainly not least…ly—it must provide extra security for sensitive information stored within the database by limiting who can view or modify specific information. 

Essentially, a *good* semantic layer *must* also include [a governance layer or data access controls](https://cube.dev/product/data-access-control). 

## Why is it important to orchestrate data access controls upstream of data apps?

Having data access controls as a part of a semantic layer is crucial for maintaining data security and integrity. It enables organizations to limit access to sensitive data, ensuring only authorized individuals can access the information they need. 

### A fictional example of what *not* to do:

Imagine, if you will, a highly fictional, highly hypothetical credit card score company called Creditlandia, which holds the extremely precious financial data of millions.

Creed is a data engineer at Creditlandia. Moreover, Creed is very tired because he has to manually orchestrate security context for each of Creditlandia's downstream apps; they are all fed data from its massive data stores. 

One day, Creed—the human he is—makes a mistake in the tedious and exhausting work that he does. 

As a result, a begrudged member of the CX team suddenly sees they have read and write access to every customer’s data. They delightedly export this PII (Personal Identifiable Information) to a hard drive, sell it on the dark web, and retire happily at 36. Creed and management, meanwhile, are not so happy. 

And, likely, neither are their millions of customers.

…so, do we see where Creditlandia went wrong? 

By faciliating a data pipeline against best practices; one that necessitates duplicated processes and envitably opens gaps in consistency (of security, metrics, and so on). 

### Orchestrating security context and data governance with a semantic layer

Suppose data access controls are installed in a semantic layer—the middleware sitting downstream of every data source and upstream of every data app. In that case, Creed joyously no longer has to orchestrate security context for each manually. 

An organization can then be rest assured that only the right people have the right access to the right information. An executive can have every kind of access to every customer record, but a customer service rep can only read anonymized versions of their open tickets.  

Orchestrating granular data access controls in a semantic layer also enables organizations to maintain compliance with regulatory requirements. Centralizing security context provides a comprehensive view of data access across the organization. Ergo, companies can easily identify who has access to what data, enabling them to quickly audit and adjust access controls as necessary.

Overall, implementing data access controls upstream of every data application is vital for providing a more efficient means of managing data security across the organization. And in doing so, enhancing governance and ensuring compliance.

Basically, don’t be like Creditlandia. 

### The details about data access controls

#### What are Authentication Tokens?

Authentication tokens are unique identifiers assigned to users upon successful login or authentication. These tokens are then used to authenticate and authorize the same user's access to the system or application, particularly when accessing sensitive data. 

In this way, authentication tokens are a crucial aspect of data access control because they ensure that only authorized and authenticated users can access confidential information or processes within an organization's information system.

#### What is Role-Based Access Control & what is Column-Based Access Control?

[Role-based access control (RBAC)](https://cube.dev/docs/recipes/role-based-access) is a security feature that restricts access within a system by assigning permissions and privileges based on an individual's role or position in the organization. For instance, managers would have permission to access information that entry-level employees would not. This restricts unauthorized personnel from accessing sensitive information and provides an added layer of protection for confidential data.

For example, RBAC might be used within a financial institution. The bank has several departments such as customer service, accounting, and marketing. Each department has different duties and responsibilities, and there is a risk of data breaches if employees can access information outside their scope of work. 

RBAC could be implemented to restrict data access based on employees' job titles or roles, preventing unauthorised personnel from accessing private client data. This enhances security and privacy while ensuring that employees can access the information necessary to perform their duties. 

[Column-based access control (CBAC)](https://cube.dev/docs/recipes/column-based-access) works similarly, but restricts which columns in a table are visible instead of restricting rows. 

For example, an employee may be allowed to see all customer records but may only be able to view certain columns such as first name or last name but not address information or phone number information unless they have additional authorization tokens granting them permission to do so.

### What is Multitenancy?

[Multitenancy](https://cube.dev/docs/config/multitenancy#multitenancy) is when multiple organizations use the same instance of software, rather than each organization having its own. For example, many companies now use cloud software such as Salesforce or Microsoft Office 365, instead of buying a server for their organization's exclusive use. 

Of course, this is highly applicable to [embedded analytics](https://cube.dev/use-cases/embedded-analytics) applications—for example, e-commerce dashboards for small businesses. One vendor—Quirky Hats 4 U—should not have access to the sales information of another, say, Funny Hats 4 Us. 

Multitenancy is essential in terms of security because it allows organizations to share resources while maintaining individualized  protection over their own data sets. In addition, authentication tokens ensure that only authorized users can access specific databases within an instance of multi-tenant software.

## Data Access Controls, HIPAA & SOC 2 Compliance

Data access controls help protect sensitive PII, such as social security numbers or health records, by prohibiting unauthorized users from accessing confidential files without proper authorization tokens. 

These controls are critical when dealing with [HIPAA](https://www.cdc.gov/phlp/publications/topic/hipaa.html#:~:text=The%20Health%20Insurance%20Portability%20and,the%20patient's%20consent%20or%20knowledge.) compliance since healthcare organizations must adhere strictly to HIPAA regulations concerning patient privacy. Failing to do so can result in fines or other penalties imposed by the Department of Health and Human Services Office for Civil Rights (OCR).

Similarly, [SOC 2](https://www.finra.org/compliance-tools/cybersecurity-checklist) compliance requires organizations dealing with financial services, or handling large amounts of sensitive PII data, to adhere strictly to SOC 2 regulations regarding storage and transmission requirements. Failing here, too, can result in hefty fines from regulatory agencies like The Financial Industry Regulatory Authority (FINRA). 

A well-implemented semantic layer can help guarantee compliance with these regulations by providing granular controls over who has access to what pieces of PII at any given time. By doing so, organizations ensure that data remains secure even after being transferred between systems or networks.

## Summing it up: why a semantic layer is key in data security and authentication

All in all, security and authentication in a semantic layer are essential for protecting your valuable business assets—particularly when dealing with PII. 

Not only does this type of setup allow you granular control over who has access to what kinds of data at any given time, but it also ensures your company complies with applicable laws like HIPAA and SOC 2.

If you’re interested in learning more about how crucial semantic layers are in a modern data stack—not just for security but also data consistency, speed, and accessibility—[try Cube for free](https://cubecloud.dev/auth/signup) or [reach out to us](https://cube.dev/contact).

Onward and upwards, 
Tamar 


Tamar Barlev

Best Practices

Or, why you *need* a middleware that includes data access controls.

The (Earnest) Importance of Orchestrating Security Context in a Semantic Layer: HIPAA and SOC 2

Today, we’re happy to present the newest addition to the plethora of [data tools](https://cube.dev/integrations) that work with Cube, the semantic layer for building data apps. [Delphi](https://www.delphihq.com) provides a way to interact with Cube in natural language and delivers insights straight to business users in Slack. 

![Diagram: Cube and Delphi](https://ucarecdn.com/ed0d51c4-2ff7-40cc-891f-32badcc57a51/)

Powered by the newest large language model (LLM) technology from OpenAI, Delphi brings the accessibility of self-service analytics to the next level and enables a compelling use case for semantic layers. See Cube and Delphi in action:

<iframe width="790" height="447" src="https://www.youtube.com/embed/FotEaaf20gY" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen allow="fullscreen;"></iframe>

Learn more about Delphi and [semantic superiority](https://davidsj.substack.com/p/semantic-superiority-part-4) from David Jayatillake, co-founder and CEO at Delphi Labs:

## Natural language interface for data

Our mission for Delphi is to solve the whole workflow, from question to answer, with data. Today, this is broken—self-serve BI tools haven’t delivered on this promise to date, and data teams are bombarded with ad hoc requests at a scale greater than ever before as businesses move to operate with data.

When we ask data leaders in the space what % of their organization is capable of self-serving with data, the answer is usually between 10 to 25%, with only 10% being very competent. It’s been three years since “dashboards are dead,” but unfortunately they’re still being used as the primary way to serve data. In my experience, no stakeholder ever wanted a dashboard. They wanted an answer, an explanation, a prediction, data to use elsewhere operationally, a graph or a slide to make a specific point.
This is the problem space we aim to solve with Delphi.

There are many other entrants who are trying to offer a natural language interface to data in this LLM gold rush. However, almost all of them are pointing the LLM at a database schema and getting it to generate SQL. We believe this is the wrong approach: every time a query is answered using this method, the LLM generates a minimal semantic layer on the fly in order to derive meaning from the data. As humans created the data structures and their meaning in the first place, why introduce a probabilistic element into the meaning of your data?

We believe that working with semantic layers curated by data folks is the best approach. It synthesizes the information already baked into the semantic layer, truly enabling safe and accurate answers. It also allows us to say that we can’t answer the question—a very normal outcome when asking a data team a question; LLMs connected directly to a data store will simply guess, as they don’t have a concept of a world and what does, and doesn’t, exist in it, which a semantic layer offers.

This is why we’re so excited to work with semantic layers like Cube—we’re already blown away by the interest we’ve had from the Cube community and hope to continue to work with you all!

As I’ve written in my [substack](https://davidsj.substack.com/archive), I believe the future of semantic layers is standalone. It’s what the people want.

## What’s next?

Here's what an early adopter of Delphi and Cube thinks:

> Getting started with Delphi on Cube was a breeze and we really quickly had a conversational AI interface to our data warehouse. The accuracy was great and some of the Delphi features really helped explain our data and ensure we knew how we were querying it. I'd highly recommend it for it's wow factor and enabling moving towards a data driven culture.

Interested? Implement your [semantic layer](https://cube.dev/use-cases/semantic-layer) with Cube by [getting started with Cube Cloud](https://cubecloud.dev/auth/signup) today or by [contacting us](https://cube.dev/contact). Also, [sign up for Delphi](https://docs.google.com/forms/d/e/1FAIpQLSc7nJc1Zeu5kEHcKrghbTPy3MSxJLOBsge0kj4Iiz5aqX6zJg/viewform) and see it in action at [slack.cube.dev](https://slack.cube.dev) in the `#random-delphi-demo` channel:

![Delphi in Slack](https://ucarecdn.com/ddf30e1e-c179-4fda-8aa8-2f75a05f808e/)


David Jayatillake

News

Announcing Cube’s integration and partnership with Delphi Labs

AI-powered conversational interface for the semantic layer

Today, I am excited to announce the launch of [the Cube Partner Network](https://cube.dev/consulting/cube-partner-network), our program for partners who deliver solutions to customers using Cube.

With Cube, [the semantic layer](https://cube.dev/use-cases/semantic-layer) for data applications, our customers are building powerful, scalable and differentiated data experiences for their internal users as well as their customers. 

Cube makes it feasible for smaller teams and more efficient for developers to create unique, highly customized data applications. With Cube’s universal stack compatibility, our customers are building these apps using the data sources, visualization tools, front-end frameworks and low-code tools they know and love. 

And so, as we grow, it’s important to us that we continue to expand our ecosystem of integrations, further enabling our users to build with the tools of their choosing.

However, the myriad of integration possibilities can lead to complexity; we have had many users reach out to us to ask for support with wide-ranging topics such as data engineering, front-end development and analytics best practices. 

We field these questions as best as we can (many of us have significant data analytics experience, which is why we built Cube!) but we recognize that this process isn’t really scalable. At the same time, we’ve had many world-class data analytics consultancies reach out to us to inquire about a consulting partner program. 

So—demand, meet supply.

Through the Cube Partner Network, we aim to provide our customers with access to a network of trusted consulting firms that have deep expertise in implementing and optimizing data applications. 

Whether a customer's use case is [embedded analytics](https://cube.dev/use-cases/embedded-analytics) solutions, internal business intelligence initiatives, or some other use of Cube that we haven't yet dreamed up, our partners will work closely with Cube to ensure that our customers receive the highest level of service and support. 

## Benefits of the Cube Partner Network

By partnering with Cube, consulting firms will gain access to a range of benefits, including:

### 1. Technical and Sales Training and Support

Our partners will receive comprehensive technical training and support to ensure that they have a deep understanding of the Cube platform and can provide the best possible service to our customers.

### 2. Co-Marketing Opportunities

We will work closely with our partners to develop co-marketing initiatives that will help them promote their services to our customers and prospects.

### 3. Access to sandbox Cube Cloud environments

Our partners will have access to sandbox Cube Cloud environments to assist their consultants in getting hands-on with the software and making it easier to demo solutions for prospects.

### 4. Referral Opportunities

We will refer our customers to our consulting partners when they require implementation or optimization services, helping our partners to grow their business.

This collaboration has been thoughtfully designed with the inclusion of valuable input from several esteemed consulting partners who have graciously lent their voices to the cause. These partners have shared their insights to help shape the program, and relayed to us the impacts that partnering with Cube is making in their business.

> “Partnering with Cube gives us an in-depth view into the future of the semantic layer, thanks to their team we can be confident our deployments will be the best-of-breed for our clients.”

— Olivier Dupuis, Chief Product Officer at Rittman Analytics

## How to Become a Consulting Partner

We are looking for consulting firms that have a proven track record of delivering high-quality data services to their clients. 

If you are interested in becoming a Cube Consulting Partner, please reach out to us at __partnerships@cube.dev__ or complete the form on the [Cube Partner Network page.](https://cube.dev/consulting/cube-partner-network "Cube Partner Network")

We're excited to work with our partners to help our customers achieve their goals and unlock the full potential of embedded analytics. 

Onwards and upwards.


Brian Bickell

A community for our customers and partners.

Introducing the Cube Partner Network

With this article, we start a multi-part series that will cover the spectrum of reasons to use Cube Store, a purpose-built distributed, fast, and reliable data store, as a part of your Cube deployments.

With [more than 2 years](https://cube.dev/blog/introducing-cubestore) in active development, Cube Store accounts for half of Cube’s [Rust code base](https://github.com/cube-js/cube/tree/master/rust) and supports some of the most critical features: in-memory cache, query queue management, and pre-aggregations. Thanks to these features, Cube provides fantastic support for [embedded analytics](https://cube.dev/use-cases/embedded-analytics) and [real-time analytics](https://cube.dev/use-cases/real-time-analytics) use cases, processing client queries to cloud data warehouses and streaming databases with sub-second latency and high concurrency while safeguarding these data sources from load bursts and overspending.

In this article, we’ll focus on the in-memory cache and query queue features. Last year, we [announced](https://cube.dev/blog/replacing-redis-with-cube-store) plans to update these features to use Cube Store and, consequently, remove Redis®* from Cube deployments. [Much work](https://github.com/cube-js/cube.js/issues/5042) has been done on GitHub, and we’ve also run a [webinar](https://cube.dev/events/migrating-from-redis) covering these changes recently. Now, let’s recap and dig deeper.

_&ast; Redis is a registered trademark of Redis Ltd. Any rights therein are reserved to Redis Ltd. Any use by Cube is for referential purposes only and does not indicate any sponsorship, endorsement or affiliation between Redis and Cube._

## In-memory cache in Cube

As the semantic layer for data applications, Cube is designed to sit between data sources (e.g., cloud data warehouses and traditional databases) and data consumers (e.g., BI tools, data notebooks, and front-end apps). It receives queries from these data consumers via any of the supported APIs (i.e., SQL API, REST API, and GraphQL API) and fulfills them in a timely manner.

![Semantic layer](https://ucarecdn.com/0e3e2588-ec07-44bf-a4ee-856f793132be/)

In the most trivial scenario, to fulfill a query, Cube would analyze the query, apply access control rules, transform it using the data model, generate a new SQL query, run this new query against the upstream data source, and deliver the result set back to the data consumer. It takes time, and querying the upstream data source is the most time-consuming..

You can expect the latency to be up to a few seconds when using cloud data warehouses such as Snowflake or BigQuery; it can grow indefinitely when using traditional databases such as Postgres. It depends on multiple factors, including but not limited to the following: the complexity of the query, the volume of data to be processed, the type of data storage (row-based vs. columnar), the database architecture (single-node vs. distributed), and implemented optimizations.

It means that, to ensure low query latency and excellent user experience at the data consumer level, __running queries against upstream data sources should be avoided at all costs, when possible__. Let’s consider one of these possibilities.

Often, multiple identical queries would hit Cube within a short time frame. It usually happens when multiple users open the same dashboard in a BI tool or the same page of a front-end application; it also happens when a single user refreshes a page or navigates back to it. In many cases, a result of a query that was run 5 seconds ago should still be relevant for the same query that has just arrived; moreover, query results often don't depend on the query time at all. For example, the revenue generated by the Oregon branch of your company last week or the volume of deposits withdrawn from Silicon Valley Bank on the week of March 5, 2023, don’t change as time passes.

### Query deduplication

Cube deduplicates identical queries to its APIs.

Let’s unpack how it works:

- When the first-of-a-kind query arrives, it will be fulfilled by querying the upstream data source. The result would also be put in the in-memory cache that Cube maintains.
- Next, when a query identical to the first one arrives, it would be fulfilled from the in-memory cache—almost instantly. We’re talking about milliseconds vs. seconds in the case of upstream data sources.
- As more and more identical queries hit Cube, almost counterintuitively, the overall performance would improve. Indeed, median and 95th percentile latencies for the query would naturally tend to the in-memory cache latency, not that of the upstream data source.

Please watch the following 10-minute demo to see how query deduplication works and how it affects query latencies:

<iframe width="560" height="315" src="https://www.youtube.com/embed/ULVkdUlKpUc?start=2389" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

Here’s the most insightful part of the demo above:

```bash
% k6 run scripts/1.js | grep iteration
     iterations.....................: 2950   588.92/s
     iteration_duration.............: min=2.46ms med=10.33ms p(95)=23.13ms max=1563.71ms
```

When thousands of queries are being run (specifically, 2950), the maximum latency is well over a second because one query has to hit the upstream data source; the median and p(95) latencies are two orders of magnitude lower, in the range of 10–23 milliseconds. __Cube effectively employs its in-memory cache to deduplicate identical queries and provide the lowest query latency possible.__

It’s worth noting that the in-memory cache is, naturally, a cache, so it’s subject to one of the [two hardest things](https://skeptics.stackexchange.com/questions/19836/has-phil-karlton-ever-said-there-are-only-two-hard-things-in-computer-science) in computer science: cache invalidation. By default, Cube would invalidate the entries in the in-memory cache after a [time interval](https://cube.dev/docs/schema/reference/cube#parameters-refresh-key) that depends on the upstream data source: every 2 minutes for BigQuery, Athena, Snowflake, and Presto; every 10 seconds for all other databases. It makes sense to deduplicate queries against data warehouses more aggressively since running them costs money and consumes limited resource quotas.

### API idempotence and scalability

Cube’s architecture allows scaling its API instances from one to many. Regardless of which API instance was hit by an incoming query, Cube will check if its unified in-memory cache has a relevant cached result.

Such architecture makes Cube’s APIs idempotent. You can distribute the load between API instances however you want (a simple round-robin strategy works excellently), and no sticky behavior is needed. You can also implement more sophisticated load-balancing strategies, e.g., when running [massive multitenant deployments](https://cube.dev/docs/cloud/configuration/deployment-types#production-multi-cluster) in production. It means __you can freely and quickly scale API instances up and down__, no cache warm-up is needed for new instances.

Production deployments in Cube Cloud are able to [auto-scale the number of API instances](https://cube.dev/docs/cloud/configuration/deployment-types#cube-api-instance) from 2 to 10 (and above), so you can process dozens and hundreds of requests per second (RPS). [Talk to us](https://cube.dev/contact) if you’d like to discuss your use case and performance requirements.

## Query queue in Cube

When Cube needs to run a query against the upstream data source, it goes through the following steps:

- First, the query is added to the query queue. Cube maintains a separate query queue for every upstream [data source](https://cube.dev/docs/schema/reference/cube#data-source) and your data model can surely work with [multiple data sources](https://cube.dev/docs/config/multiple-data-sources) at once.
- Second, Cube will pick a query from the queue and execute it against the data source. The maximum number of simultaneously executed queries is defined by the [`CUBEJS_CONCURRENCY` config option](https://cube.dev/docs/reference/environment-variables/#cubejs-concurrency) and depends on the upstream data source: 2 for Postgres, 4 for Redshift, 5 for Athena and Snowflake, 10 for BigQuery, etc. These sane defaults prevent the data source from overloading and data warehouse resource quotas from depleting.
- Lastly, when the query execution is completed, Cube will put its results in the in-memory cache. Immediately thereafter, all API requests that were waiting for the results of this query will be fulfilled.

Please watch the following 3-minute demo to see how the query queue works and how it allows limiting query concurrency on the data source side:

<iframe width="560" height="315" src="https://www.youtube.com/embed/ULVkdUlKpUc?start=3098" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

Queuing queries instead of running them directly against the upstream data source brings substantial benefits. __Query queue safeguards data sources from excess queries in case of burst load;__ it also allows servicing long-running interactive queries and canceling queries initiated by dropped API connections.

## In-memory cache and query queue implementation

As evident from the previous sections, in-memory cache and query queue are essential parts of Cube that have been present from day one.

### Initial architecture

Initially, they were implemented using [Redis](https://redis.io), an open-source in-memory data store, to keep the cache and queue entries. Cube API instances and refresh workers interacted with Redis to maintain the query queue and use the in-memory cache. The following architecture was used:

![Architecture with Redis](https://ucarecdn.com/18f3c514-1856-49b2-bd4d-1d48c8a043f7/)

It worked really well for many use cases. However, we collected enough evidence over time to decide that Cube needed to move on from Redis.

### Reasons to move on from Redis 

Please read the [blog post](https://cube.dev/blog/replacing-redis-with-cube-store) with detailed reasoning by Pavel Tiunov, CTO at Cube.

Alternatively, refer to the following summary:

- __Operations and reliability considerations.__ Redis requires a complex setup for [scalability](https://redis.io/docs/management/scaling/) and [high availability](https://redis.io/docs/management/sentinel/). To maintain a Redis cluster, you must run at least three Redis and Redis Sentinel nodes. Moreover, cluster coordination consumes a lot of resources under high load.
Use case considerations. Redis works well as a data store for the in-memory cache. However, it was never designed for large columnar payloads and low bandwidth consumption. Also, Redis is less than optimally suited as a data store for the query queue given the [complexity of data flow](https://github.com/cube-js/cube.js/blob/master/packages/cubejs-query-orchestrator/DEVELOPMENT.md).
- __Client stability and code complexity considerations.__ Since the first days of Cube, Redis has required substantial effort to provide stable support on the client side. We had to introduce the support for multiple client libraries (node-redis and ioredis) and the related [`CUBEJS_REDIS_USE_IOREDIS` config option](https://cube.dev/docs/reference/environment-variables#cubejs-redis-use-ioredis). Moreover, we had to maintain complex and error-prone code on the client side to manage the query queue (see examples: [one](https://github.com/cube-js/cube.js/blob/02a8e027c1f414c50cb49f257ce68c01425400ec/packages/cubejs-query-orchestrator/src/orchestrator/RedisQueueDriver.js#L93,L101), [two](https://github.com/cube-js/cube.js/blob/02a8e027c1f414c50cb49f257ce68c01425400ec/packages/cubejs-query-orchestrator/src/orchestrator/RedisQueueDriver.js#L130,L137), [three](https://github.com/cube-js/cube.js/blob/02a8e027c1f414c50cb49f257ce68c01425400ec/packages/cubejs-query-orchestrator/src/orchestrator/RedisQueueDriver.js#L209,L218)).

One more deciding factor was that many Cube deployments—in addition to Redis—include Cube Store, a purpose-built distributed, fast, and reliable data store. So, we updated the implementation of the in-memory cache and query queue to use Cube Store.

### Up-to-date architecture

Up-to-date Cube deployments use Cube Store as the all-in-one data store: for in-memory cache, query queue, and pre-aggregations. Redis is not needed.

![Architecture with Cube Store](https://ucarecdn.com/c97e77a5-1ebf-4542-951c-480a7ccc2509/)

If you still have Redis as a part of Cube deployment, read on for the migration guide.

## How to migrate to Cube Store

Cube supports using Cube Store for in-memory cache and query queue starting from version 0.31.60. To migrate, you will need to upgrade Cube to this version and check the [`CUBEJS_CACHE_AND_QUEUE_DRIVER` config option](https://cube.dev/docs/reference/environment-variables#cubejs-cache-and-queue-driver).

Migration scenarios slightly differ depending on where you run Cube: in Cube Cloud, in a self-hosted environment, or locally on your computer.

### Migration in Cube Cloud

In Cube Cloud, the migration from Redis is seamless. Every [production cluster](https://cube.dev/docs/cloud/configuration/deployment-types#production-cluster) in Cube Cloud includes a fully managed Cube Store with high availability.

Proceed through the following steps:

1. Pick a deployment, navigate to <Btn>Settings</Btn> / <Btn>General</Btn>, and ensure the Cube version is at least 0.31.60. Choose either a <Btn>Stable</Btn> (preferred) or the <Btn>Latest</Btn> channel:

    ![Versions](https://ucarecdn.com/7798b767-b917-4258-9fd8-54d5f87c9046/)

2. Starting from 0.32.0, no additional configuration is needed. If you’ve chosen a version between 0.31.60 and 0.32.0, go to <Btn>Settings</Btn> / <Btn>Configuration</Btn> and ensure you have the [`CUBEJS_CACHE_AND_QUEUE_DRIVER` config option](https://cube.dev/docs/reference/environment-variables#cubejs-cache-and-queue-driver) set to `cubestore`.

    ![Environment variables](https://ucarecdn.com/3eeb9e89-a8c2-4a73-ab4a-56de840429eb/)

That is all. Now you run Cube with Cube Store for the in-memory cache and query queue.

### Migration when self-hosting

In a self-hosted environment, the migration is really easy if you already have Cube Store. If you don’t run it yet and don’t want to complicate your setup, consider [using Cube Cloud](https://cubecloud.dev/auth/signup) which provides a seamless migration experience.

Proceed through the following steps:

1. If you don’t run Cube Store yet, you should run at least a Cube Store router. Please refer to the Cube Store [architecture overview](https://cube.dev/docs/caching/running-in-production#architecture) and example Docker configuration.
2. Ensure the version is at least 0.31.60 for all Cube nodes: API instances, refresh workers, Cube Store routers, and Cube Store workers.
3. Starting from 0.32.0, no additional configuration is needed. If you’ve chosen a version between 0.31.60 and 0.32.0, ensure you have the [`CUBEJS_CACHE_AND_QUEUE_DRIVER` config option](https://cube.dev/docs/reference/environment-variables#cubejs-cache-and-queue-driver) set to `cubestore` for all API instances and refresh workers.
4. Remove all [`CUBEJS_REDIS_*` config options](https://cube.dev/docs/reference/environment-variables/#cubejs-redis-url) from all API instances and refresh workers.
5. Remove Redis from your architecture.

That is all. Now you run Cube with Cube Store for the in-memory cache and query queue.

### Migration on a local computer

If you run a single instance of Cube locally on your computer in the [development mode](https://cube.dev/docs/configuration/overview#development-mode), the migration is really easy because you already have Cube Store running in-process.

Proceed through the following steps:

1. Ensure the Cube version is at least 0.31.60.
2. Starting from 0.32.0, no additional configuration is needed. If you’ve chosen a version between 0.31.60 and 0.32.0, ensure you have the [`CUBEJS_CACHE_AND_QUEUE_DRIVER` config option](https://cube.dev/docs/reference/environment-variables#cubejs-cache-and-queue-driver) set to `cubestore`.

That is all. Now you run Cube with Cube Store for the in-memory cache and query queue.

## What’s next?

Run Cube Store as part of your Cube deployments. [Get started today in Cube Cloud](https://cubecloud.dev/auth/signup) to try a fully managed Cube experience.

Enjoy the benefits of using Cube Store for the in-memory cache and query queue, including low query latency for identical queries and safeguarding data sources from burst load.

Please don’t hesitate to [talk to us](https://cube.dev/contact) if you have any questions. Also, join our Slack community of 8,000 data practitioners at [slack.cube.dev](https://slack.cube.dev) to discuss your experience with Cube Store.

Deep Dives

Moving on from Redis to a better in-memory cache and query queue

How you win by using Cube Store: Part 1

We [launched Cube Cloud](https://cube.dev/blog/announcing-cube-cloud) back in 2021 and have been busy ever since launching new features, growing Cube Cloud usage, and listening to your feedback. Today, we are happy to make a major update to Cube Cloud pricing.

This update—measuring usage with Cube Compute Units—makes pricing more predictable and reflects the diversity of enterprise customers using Cube Cloud with custom-tailored pricing plans. Let’s walk through these changes.

## Transparent and predictable pricing

We have always wanted Cube Cloud pricing to be transparent and predictable for Cube Cloud users, so that it reflects the actual usage of the service and can be forecast in advance. That is why we think that *consumption-based pricing* is the best option for Cube Cloud.

Initially, we chose *data pass through*—defined as the amount of data transferred between Cube Cloud and API clients or database—as the measure of resource consumption. It definitely helped users quantitatively understand how much data flows from a data warehouse to Cube and from Cube to data consumers.

However, this model turned out to not be transparent and predictable enough. Often, the most pragmatic way to understand the expected data pass through of a deployment was to actually make it live and then measure. Also, changes to data model, caching configuration, queries, etc. would sometimes result in step changes and make data pass through hard to predict. For these reasons, we’ve decided to introduce a better alternative.

### Cube Compute Units (CCUs)

Now, our users’ resource consumption is measured in *Cube Compute Units*, which precisely and transparently reflect the compute required to run certain Cube components, i.e., API instances and development instances, refresh workers, Cube Cloud routers and workers. (Note that Redis instances are not present in this list since we have [migrated from Redis](https://cube.dev/events/migrating-from-redis) to Cube Store.)

![Cube Compute Units](https://ucarecdn.com/be1a7fa4-0f3e-446e-8de0-aa0c9705ae3d/)

Let’s explain. Assume that you have a minimal yet very potent Production Deployment that includes two Cube API Instances (enough for serving up to 20 requests per second), a Cube Refresh Worker, and two Cube Store Routers. You also choose to include two Cube Store Workers because you want to use pre-aggregations and provide your users with blazing-fast experience:

![Architecture](https://ucarecdn.com/d7dc276b-54b8-422e-a549-6710a1ba5eed/)

We can go through a few real-world scenarios for that deployment:

1. Running this deployment would consume 4 to 6 CCUs per hour or approximately 2900 to 4400 CCUs per month (keep in mind that when pre-aggregations are not being refreshed or used to serve queries, Cube Store Workers are scaled down).
2. Additionally, if every workday at peak hour your API autoscales from 2 to 10 instances, that would add roughly 200 CCUs per month.
3. Also, if two engineers on your team hack on the data model for a couple of hours every workday while running their Development Instances, that would add about 100 CCUs per month.

For simplicity, we used whole hours in the calculation. However, __Cube Cloud will actually scale instances up and then back down within minutes, so you’re never overcharged for the unused resources.__

### Updated Billing Experience

We believe that this flavor of consumption-based billing, popularized by many industry leaders such as Snowflake (credits) and Databricks (DBUs), is already well-known to many Cube Cloud users and the overall data community.

To further help Cube Cloud users understand and forecast their usage and related costs, we also updated the Billing page in Cube Cloud. Now, you’re able to break down usage by deployments and services, review it on a daily and monthly basis, and monitor spend in CCUs and USD:

![Billing interface](https://ucarecdn.com/eb6bc535-82e0-4545-b3cb-11c8cad872f7/)

Needless to say, this page is powered by Cube and provides near real-time experience.

## New plans for production deployments

Over the last couple of years, we’ve accumulated vast knowledge of Cube Cloud users. Our familiarity with our user base provided us with the insights to launch many new features and update pricing plans so they’re tailored to their everyday needs.

You can see the entirety of new plans on the updated [pricing page](https://cube.dev/pricing).

### Try a Development Instance of Cube Cloud, free of charge

One hill we’ll die on? Using Cube Cloud is the *best* way to get started with Cube.

Fully managed, secure, and packed with features that provide a smooth developer experience, Cube Cloud should be available to every single engineer getting started with Cube. So, in that vein,, we continue to provide an option to [try Cube Cloud for free](https://cubecloud.dev/auth/signup) for your non-production or proof-of-concept deployment.

This option empowers you to evaluate Cube indefinitely and upgrade to any of the following plans when you’re ready to go into production.

### Choose a plan for production deployments

We’re introducing four new plans: [Starter, Premium, Enterprise, and Enterprise Premier](https://cube.dev/pricing).

Every plan has a different price per CCU—and for a good reason. We’ve built these plans so they reflect the needs of different Cube Cloud users: from seed-stage startups to Fortune 500 companies with mission-critical data applications.

A few highlights regarding these new plans:

* __Starter__ plan will let you run deployments on AWS and GCP, collaborate as a team using [development mode](https://cube.dev/docs/cloud/workspace/development-api) and [data model IDE](https://cube.dev/docs/cloud/workspace/cube-ide), and have full observability with real-time application performance monitoring (APM) and [alerts](https://cube.dev/docs/cloud/workspace/alerts).
* __Premium__ plan guarantees 99.950% uptime, lets you run deployments in a [dedicated virtual private cloud (VPC)](https://cube.dev/docs/cloud/configuration/connecting-with-a-vpc), supports Azure in addition to AWS and GCP, and provides your team with single sign-on (SSO) via Okta.
* __Enterprise__ plan guarantees 99.990% uptime, provides VPC peering, [logs and metrics export](https://cube.dev/docs/cloud/workspace/logs), SSO via SAML/LDAP as well as [role-based access control (RBAC)](https://cube.dev/docs/cloud/access-control/). You will also get a dedicated customer support manager (CSM) who would be in direct contact with you at every step of your Cube Cloud experience.
* __Enterprise Premier__ plan guarantees 99.995% uptime, provides unlimited scalability with multi-cluster deployments as well as connectivity to Elastic and [Kafka (via ksqlDB)](https://cube.dev/docs/config/databases/ksqldb) for [real-time streaming](https://cube.dev/events/building-real-time-streaming-data-applications-with-cube). You will also get the utmost level of support for your mission-critical data applications.

Indeed, Cube Cloud is packed with features for organizations of all sizes, so one could get overwhelmed with the available options—but don’t fret.  We’re always happy to help out, so just [get in touch](https://cube.dev/contact) with us.

## What’s next

Our updated pricing with new plans, Cube Compute Units, and great billing experience are already available to all new Cube Cloud users. Check our updated [pricing page](https://cube.dev/pricing) and [start using Cube Cloud](https://cubecloud.dev/auth/signup) today. Also, don't hesitate to [talk to us](https://cube.dev/contact) so we can help you get started.

Note that nothing is changing for existing Cube Cloud users on Standard and Enterprise plans as of right now. If you’re in this amazing category, thank you for your support. If you see something in the new plans that gets you excited, [please reach out](https://cube.dev/contact) and we will get you set up. Or—just carry on using Cube Cloud on your current plan and we’ll get in touch sometime soon to assist you with upgrading to new plans.

If you have any questions or feedback regarding our updated pricing, [please reach out](https://cube.dev/contact); we’d be happy to walk you through how it works. Or share your thoughts in the `#cube-cloud` channel in our [Slack community](https://slack.cube.dev)—because even with almost 8,000 data practitioners, it’s still never too late to join 🙂

Pay for what you use: Cube Cloud pricing gets back to its roots

Cube Core v0.32 release brings the GraphQL API into general availability, adds a number of quality-of-life improvements to Cube SQL and adds significant performance boosts to Cube Store.

## Breaking changes and deprecations

This release, we have 2 deprecations and 5 breaking changes:

Please check the [deprecation document](https://github.com/cube-js/cube/blob/master/DEPRECATION.md) for more details.

### Breaking changes

- Cube Store is now the default cache and queue engine, replacing Redis. We've talked previously about how [Cube Store will be replacing Redis][cube-blog-redis-deprecation], and this release makes it official.

- Support for Node.js v12 and v15 has been dropped due to [them reaching
  end-of-life][nodejs-eol]. We strongly recommend upgrading to Node.js v16.

- Absolute imports for the following packages have been removed. We now provide a public API from the package directly:

  - `@cubejs-backend/query-orchestrator`
  - `@cubejs-backend/schema-compiler`
  - `@cubejs-backend/server-core`

### Deprecations

- Support for Node.js v14 has been marked as deprecated due to [it reaching
  end-of-life][nodejs-eol] in April 2023. We strongly recommend upgrading to
  Node.js v16.

- Using Cube with the Serverless Framework and the `@cubejs-backend/serverless` packages is now deprecated, we strongly recommend using [Docker-based deployments][cube-docs-deploy-docker] or [Cube Cloud][cube-docs-deploy-cloud] instead.

[nodejs-eol]: https://github.com/nodejs/Release#end-of-life-releases

## Pre-aggregations

Following on from the [Lambda pre-aggregation][cube-docs-caching-lambda] support introduced in our [last release][cube-docs-0-31], Cube now supports multiple rollups from the same cube in a `rollupLambda` definition.

## CLI

The Cube CLI now lets you validate your models on your local machine - simply
run `npx cubejs-cli validate` to check the models in your project for errors:

```bash{outputLines: 2-20}
npx cubejs-cli validate
❌ Cube Schema validation failed

Cube Error ---------------------------------------

Orders cube: "dimensions.id" does not match any of the allowed types
Possible reasons (one of):
  * (dimensions.id.case) is required
  * (dimensions.id.latitude) is required
  * (dimensions.id.sql) is required
LineItems cube: Cube Orders doesn't exist

Need some help? -------------------------------------

  Ask this question in Cube Slack: https://slack.cube.dev
  Post an issue: https://github.com/cube-js/cube/issues
```

## Drivers

We've enabled `readOnly: true` as the default for the
[Clickhouse][cube-docs-conf-clickhouse], [MSSQL][cube-docs-conf-mssql] and
[Oracle][cube-docs-conf-oracle] drivers which lets Cube build pre-aggregations
without creating temporary tables in those databases.

## GraphQL API

We're extremely excited to announce general availability of the GraphQL API in
Cube. With this, the GraphQL API now fully supports variables, a much-requested
(and much-needed) improvement:

```javascript
import { gql } from '@apollo/client';

const getOrdersQuery = gql`
  query CubeQuery($orderBy: OrdersOrderByInput) {
    cube {
      orders(orderBy: $orderBy) {
        count
        status
      }
    }
  }
`;

const variables = {
  orderBy: {
    count: 'desc',
  },
};

client
  .query({
    query: getOrdersQuery,
    variables,
  })
  .then((result) => console.log(result));
```

## SQL API

Cube SQL continues to see quality-of-life improvements as well as enhanced
support for even more SQL functions as selections and projections. Some examples
of what we've improved this release include:

- Support for `CASE` statements in Cube projections
- Support for expressions like `NOT(LOWER() IN)`
- Allow using `CAST` in `HAVING` clauses
- Support for `LEFT` and `RIGHT` functions in projections
- Support for `NULLIF` in projections
- Allow using `TO_DATE()` in `DATE_DIFF()` expressions
- Allow using `DATE_TRUNC()` in `WHERE` clauses

We hope that you find these helpful in your work with Cube SQL; please let us know if you have any feedback or suggestions by [opening
issues][cube-gh-issue-new] on our GitHub repository.

[cube-blog-redis-deprecation]:
  https://cube.dev/blog/replacing-redis-with-cube-store
[cube-docs-0-31]: https://cube.dev/docs/releases/v0-31
[cube-docs-caching-lambda]: /caching/pre-aggregations/lambda-pre-aggregations
[cube-docs-conf-clickhouse]: /config/databases/clickhouse
[cube-docs-conf-mssql]: /config/databases/mssql
[cube-docs-conf-oracle]: /config/databases/oracle
[cube-docs-deploy-cloud]: /deployment/platforms/cube-cloud
[cube-docs-deploy-docker]: /deployment/platforms/docker
[cube-gh-issue-new]: https://github.com/cube-js/cube/issues/new/choose


Hassan Khan

Cube Core v0.32 — Bye, Redis!

Since I joined Cube in October 2020, we have seen massive growth in our community. I remember celebrating 2,000 members on our Slack shortly after I joined, and today the number is well above 7,000! Beyond the growth in numbers, it’s been great to see more interactions among community members. As someone who worked in several open source communities, it's especially gratifying to see community members helping each other as this is the way communities scale. 

In order to further improve community engagement and facilitate the growth of our community, we wanted to make some changes in the next few weeks. 

First, some of you may remember that we started a [Discourse forum](https://forum.cube.dev/) in 1H’2021. We recently decided to end-of-life Discourse as the usage has been very low. Also, one of the reasons we wanted to use a forum was so that we could preserve some of the conversations from Slack (as our Slack messages disappear after 90 days). We did export some of the Slack discussions on recipes/tips to Discourse, but we decided that a better practice would be to add these discussions to our documentation (e.g., under the [examples & tutorials section](https://cube.dev/docs/examples)). Our Discourse forum is currently in “read-only” mode, and we will officially shut it down in a few months. 

Next, on our Slack, some of you may have already noticed some minor changes that we made over the past few weeks. First, we renamed some channels so that they’re more descriptive, such as #cube-store-and-caching, #jobs-and-careers, #contributing-to-cube, etc. Next, we added new channels that can be dedicated to some of the popular topics in our community, such as #data-modeling and #hosting-and-deploy. 

In addition, to encourage conversations to take place in appropriate channels (vs. all happening in #general), we’ll be using a Slack application called the [Reacji channeler](https://reacji-channeler.builtbyslack.com/) to copy threads from #general to other channels. For example, if we see a post on #general that is related to pre-aggregations, we’ll add a 💨 emoji to copy the conversation to the #cube-store-and-caching channel and continue the conversation in   . For the next few months, we’ll be adding reminders that the conversation has been moved to a different channel as we get used to this. Other emoji’s that we’ll use with Reacji channeler are 📦 (for #hosting-and-deploy), 💹 (for #dataviz), and 📐 (for #data-modeling). By doing this, we hope this will prevent everyone from being overwhelmed with messages in #general.

Speaking of our #general channel, we plan on making changes here as well. First, we’ll be creating a new channel called #advice-and-questions for people to post questions when it doesn’t fit in with other channel topics or if they’re not sure where to post. The #general channel will be renamed to #announcements-and-news where only Slack admins will be able to post. In the past, we found that people were posting solicitation-type posts on our #announcements channel, so we want to prevent this in the future. 

Over the past few months, I hope you saw our announcement posts like the one below where we recognized community members who were helpful or provided interesting insights on Slack. This has been a lot of fun for us as it’s amazing to see more questions being answered by real Cube users, and it’s always nice to recognize people. We hope this recognition of Slack contributions becomes a long-running tradition in our community. 

![](https://ucarecdn.com/ebad9212-82e1-468d-9736-df782aa33e92/)

Speaking of recognitions, I’m also excited to announce the latest addition to our Cube Heroes rank. Ryan Woodring has been very active in helping other community members on Slack, and we’re excited that he agreed to be our new Cube hero. You can find Ryan’s bio on our [community page](https://cube.dev/community), and you'll probably get a chance to see him in future community calls. 


Ray Paik

Community Updates

We're also excited to have Ryan Woodring as our new Cube Hero! 🎉

The next evolution of our community channels

__Today, we are immensely proud to announce that [Jen Grant](https://www.linkedin.com/in/jencgrant/) is joining us as COO.__ 

How to sum up Jen Grant in three words? Seasoned-leader. Skiing-aficionado. Uniquely-good-at-taking-companies-from-early-stages-to-billion-dollar-outcomes. 

We’ll be transparent—it’s in our best interest to brag here about our new COO’s achievements; fortunately for our marketer, her resume reads like the player card of a career NBA MVP (but, you know, tech). So, here are some of Jen’s stats: 

A graduate of Princeton and Wharton, she began her marketing career at [Google](https://about.google/); she closed her time there as a leader of several product marketing teams, having launched products such as Gmail, Calendar, Talk, and Blogger. 

After Google, Jen joined [Box](https://www.box.com/) as its first executive marketing hire—she took the company from obscurity to serving 95% of F500 companies and all the way to a [$1.7B IPO](https://techcrunch.com/2015/01/23/box-skyrockets-50-to-more-than-21-per-share-in-first-minutes-as-a-public-company/). 

Jen then served as CMO of [Elastic](https://www.elastic.co/), where she led its rebranding and established its marketing team. 

And subsequently, Jen continued on to become [Looker](https://www.looker.com/)’s CMO, where she grew the marketing team from 60 to 150+ and led the company to its [$2.6B acquisition by Google](https://techcrunch.com/2020/02/13/google-closes-2-6b-looker-acquisition/).

Following *that* absurdly successful tenure, she co-founded and served as [Appify](https://appify.com/)’s CEO, where she is now an advisor to the board. She also sits on the boards of Kyndi, Dialpad, and Pecan AI and advises Stytch, Waitlist.me, and Postal.io.

As Cube continues to expand and hit major milestones, our product-market fit is evident—and so is our need to continue to grow our team of (humble) rockstars with (humble) rockstar leadership. From her [widely recognized](https://csuitespotlight.com/2021/06/06/the-top-100-princeton-alumni-in-technology-of-2021/) experience in data, it's clear that Jen has a love for building organizations and a knack for spotting the critical problems to solve and the right solutions to solve them—making our pairing an ideal match.  

With all of this, it's easy to understand why we are so excited to have Jen join us as our COO. 

Welcome, Jen!

## A note from Jen:

> “There is so much potential here that I just couldn’t sit on the sidelines any longer.” 

Cube came across my desk about half a year ago—when I had resolved to take the winter off from work. The thing is, my intrigue in the massive problem Cube is solving and how it's solving it eclipsed even my love of skiing. 

As the CMO of Looker, I was acutely aware of how costly inconsistent data was to organizations. Businesses had many data sources, even more data apps, and consequently, way, way too many data silos which stood in the way of producing meaningful insights. 

What I also understood was that this was happening in almost all companies, [86% of which use two BI tools simultaneously, and 61% of which use four or more](https://www.forrester.com/blogs/the-bi-fabric-baby-is-slowly-but-surely-growing-up/): businesses *wanted* to do analysis over all their data sources but knew that the tech to make that possible didn’t exist (even Looker was only a step towards solving this challenge)

Too late for me to use it at Looker, but at the perfect time for me to jump at the incredible opportunity to help build it, I learned about Cube. 

As a [universal semantic layer](https://cube.dev/use-cases/semantic-layer), Cube solves the problem we shared at Looker with so many other organizations. Cube allows companies to easily connect to multiple cloud data warehouses, define metrics consistently through a single upstream data model, and feed that consistent data to any data app. It addresses security issues with its centralized data access controls, data performance issues with its two-level caching layer, and stack incompatibility issues with its instant APIs. 

So, yes, I was *personally* familiar with the problem Cube is fixing. 

But also, the proof of the entire market’s need for Cube is in the product-led growth pudding: initially just an open-source product, the company surpassed $1MM ARR in only a year—and by a healthy amount. We’re continually growing, [we’re selling](https://cube.dev/contact), we’re raising, and [we’re hiring](https://cube.dev/careers)—and knowing all of this, the decision to put away my skis and join Cube as COO was easy to make. 

There is so much potential here that I just couldn’t sit on the sidelines any longer.

Onwards and upwards,

Jen


Jen Grant

“There is so much potential here that I just couldn’t sit on the sidelines any longer.”

Announcing Jen Grant as Cube’s COO

Adnan Rahic

GraphQL

Building extremely fast, low-latency GraphQL APIs with Apollo and Cube.

GraphQL federation example with Apollo Federation and Apollo GraphOS

Use Hasura Remote Schemas to build a low-latency data application.

GraphQL federation with Hasura GraphQL Engine

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

Latest news and insights from Cube

Data Engineering

Application Development

All Things Cube