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

News & Product Updates

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.

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

Igor Lukanin

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

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

We often hear from our customers that they want the ability to create data models in languages other than JavaScript—specifically YAML and Python. Today, we’re excited to release a public preview for YAML data modeling in Cube. This feature is available in both Cube Cloud and Cube Core.

Our goal is to support all the core features of Cube’s data modeling, as well as caching and multi-tenancy configurations, within YAML, and later, Python. 

YAML and Python are universally adopted in the modern data stack: data engineers setup Airflow DAGs in Python and author dbt models in YAML  while data analysts perform data exploration in Python-based notebooks. In order for data engineers to not have to shift between YAML and JS as they work with so many different tools in their stacks, we want to bring support for these languages to Cube.

> “Cube’s YAML support makes my life easier because it streamlines the compatibility between the tools in my stack and my data modeling. Not needing to toggle between different languages saves me time and effort. I’m excited about this feature—and about what Cube has in store for future updates!”

– Olivier Dupuis, Analytics Engineering Consultant, Rittman Analytics

## Getting started with YAML

To get started with YAML data modeling in Cube, you’ll need to first ensure that you’re using Cube version 0.31.0 or higher.

Then,  create a `schema/orders.yml` file with the following content: 

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

    measures:
      - name: count
        type: count
      - name: total_revenue
        sql: amount
        type: sum

    dimensions: 
      - name: id
        sql: id
        type: number
        primary_key: true  
      - name: status
        sql: status
        type: string
```

You can learn more about YAML models in our [newly-released documentation](https://cube.dev/docs/schema/getting-started/yaml). 

## The future of YAML (and Python) in Cube

This release is the first step in our journey to bring both YAML and Python support to Cube. As we continuously implement and bolster support, there are some things we’ll continue to enhance, specifically around developer experience.

The following are the major areas on which we’re working.

### Dynamic data models

Many of Cube’s customers leverage [dynamic data models](https://cube.dev/docs/schema/advanced/dynamic-schema-creation) for multi-tenant scenarios. While it is possible to use `COMPILE_CONTEXT` already, dynamic data model generation is not yet available for YAML models.

We’re planning to let users write Python to dynamically generate models the very same way they can write JavaScript to generate them today. And, if you’re interested in this feature, we’d love to hear your thoughts—so, please [post your thoughts](https://github.com/cube-js/cube.js/issues/5045) on how this feature should be implemented.

### YAML configuration

While most of the Cube configuration can be done via environment variables—the way we recommend doing it—users lean on the JS-based `cube.js` configuration file for advanced configuration. We’re planning to introduce YAML and Python support for advanced configuration scenarios as well.

### Documentation and best practices
We’re releasing initial documentation for YAML modeling today. In the near future, we’ll update Cube documentation to fully integrate YAML models reference and examples. We are also updating our guides, tutorials, and best practices to showcase YAML examples alongside JS ones.

### Cloud IDE support
As part of our Cube Cloud vision, we’re aiming to build a first-class development environment for building data models in Cube, which now includes YAML models. Our Cloud IDE will include data model validation, in-line tips, pre-commit testing, and many more useful features focused on developer productivity and ergonomics. 

## Give us feedback

You can help us prioritize the features we work on and engage with our open-source software via [Slack](https://slack.cube.dev/), [GitHub](https://github.com/cube-js/cube.js), or [our contact page](https://cube.dev/contact). 

And if you have any questions about getting started with Cube’s YAML support (or any other questions, for that matter) find us on our Slack! As always, we’d love to hear from you. 

Artyom Keydunov

Data Modeling

You asked—we listened. Now, you can do your Cube data modeling in YAML. 

Introducing YAML Data Modeling in Cube

Chart.js

A step-by-step guide into the new release of the most popular charting library.

Chart.js tutorial: Getting started with the all-new Chart.js v4

At Cube, we're on a mission to provide developers with an analytical data access layer to help them build modern applications. We call this data access layer a [’headless BI’ platform](https://cube.dev/blog/headless-bi).

The goal of headless BI is to facilitate consistent, performant, and secure access to all of your data. Of course, this mission only works if we—that is, [Cube, the headless BI platform](https://cube.dev/)—can simultaneously support all of your data sources and make those data sources compatible with the broadest array of downstream tools possible. 

So today, we’re proud to launch our new [integrations page](https://cube.dev/integrations)—so that you can find and read all about how your favorite tools integrate with Cube (and in that, the rest of your stack.)

## The inspiration: complexity

Cube was borne out of the sheer complexity of the modern data stack—one that exists not only because of the fractal-like explosion of data sources (cloud data warehouses, transactional databases, streams, document databases, query engines, etc.) but also in the types of tools with which users consume data.

Yes, for better or worse, gone are the days of an organization simply choosing a single business intelligence tool and connecting it to a transactional database. 

Now, users expect to gain insights from their data with both visualization and business intelligence tools, and with notebooks, and by building their own applications with low-code tools, powerful front-end frameworks, and charting libraries. And naturally, this expectation and the remarkable number of options available result in incredible building ability—but potentially mind-boggling connectivity complexity.

![](https://ucarecdn.com/60b3a40f-79aa-40d6-803a-928de8d7bfcc/)

## The goal: universal compatibility 

Universal compatibility—meaning the ability of every data source to connect to every downstream use case—is a tall order. The good news? We have an exceptionally well-known, durable, and scalable language on our side: SQL. [Cube’s Postgres-compliant SQL API](https://cube.dev/docs/backend/sql) is the magic translation layer by which we’re able to make universal compatibility happen. 

So, perhaps your business intelligence tool doesn’t have a native driver for your fancy new analytical query engine. Well, now there’s a solution for that: if you connect your query engine to Cube, Cube’s SQL API can expose it to whichever downstream, SQL-speaking tools you choose with a simple Postgres connection. 

Or, let’s take another scenario: what if you were building a [customer-facing analytics application](https://cube.dev/use-cases/embedded-analytics)? In that case, maybe you’d prefer to expose connections to your data sources as a [REST](https://cube.dev/docs/rest-api) or a [GraphQL API](https://cube.dev/docs/backend/graphql)? Cube could do that too. A rigid out-of-the-box business intelligence tool just can’t offer the same flexibility as Cube, with which you could then use any number of front-end frameworks or low-code tool builders.

![](https://ucarecdn.com/86bdb379-b989-4e68-bb71-df784c819bd9/)

## The future: new data sources, new tools, and much (much) more. 

We believe that you should be able to curate your stack with any data source and downstream tools you want. 

And we believe in open standards and in the power of a broad ecosystem.

These tightly held values mean that if you’ve come across a fantastic tool for which we haven’t yet listed an integration, [we’d love to hear from you](https://cube.dev/contact). Because really—we built this tool with a dedication to the data community and are determined to hone it further for the community (you can also find us on [Slack](https://slack.cube.dev/) and [Github](https://github.com/cube-js/cube.js).)

Even with all of the integrations we’ve built out already, this is just the beginning of our plans for the Cube ecosystem. So looking ahead, we’ll continue adding more data sources, more downstream tools, and more categories within the modern data stack. 

We’re on an exciting journey, here—and we hope you’ll join us for the ride :) 


So you can easily find your favorite data source or tool in Cube's integrations. 

Introducing Our Integrations Gallery

Today, we're happily announcing that Cube now works with [Trino](https://trino.io), the fast distributed SQL query engine for big data analytics, formerly known as PrestoSQL.

> [Meet the Cube team at Trino Summit](https://cube.dev/events/cube-at-trino-summit) on November 10, 2022. We'll be happy to chat and explore how Cube can augment your Trino experience.

## What is Trino?

Trino is an [open-source](https://github.com/trinodb/trino) query engine designed to work with big data.

It's fast, scalable, SQL-compliant, and has almost universal connectivity to all kinds of data sources and business intelligence tools. Let's explore these in more detail:

* **Scale.** Trino is capable of querying exabyte-scale data lakes and massive data warehouses, as confirmed by [Trino installations](https://trino.io/users.html) at companies such as LinkedIn, Netflix, and Shopify.
* **Performance.** Trino is a highly parallel and distributed query engine with two types of [cluster nodes](https://trino.io/docs/current/overview/concepts.html#server-types): coordinator nodes, responsible for query planning and execution, and worker nodes, responsible for fetching and processing data. You can fine-tune your Trino cluster to allow for efficient, low latency analytics.
* **Connectivity.** Trino can natively query data from a plethora of [data sources](https://trino.io/docs/current/connector.html) without the need to extract and load the data into a data warehouse, even if you'd like to do a cross-database join. Also, Trino is an ANSI SQL-compliant query engine that works with BI tools such as Tableau, Power BI, and Superset as well as headless BI tools such as Cube.

Most common use cases for Trino include ad-hoc analytics at interactive speeds, massive multi-hour batch queries, and high volume apps that perform sub-second queries.

Trino was originally [designed and developed at Facebook](https://trino.io/blog/2020/12/27/announcing-trino.html) in 2013 and beared the name *Presto* at that time. In 2019, Presto development forked and two query engines emerged: PrestoDB maintained by Facebook and PrestoSQL maintained by the Presto Software Foundation and the original creators. Later in 2020, PrestoSQL was renamed to Trino.

If you're not a Trino user yet, consider [self-hosting](https://trino.io/docs/current/installation.html) or using a managed platform provided by [Starburst](https://www.starburst.io) or AWS (as [Amazon Athena](https://aws.amazon.com/athena/), serverless interactive query service). 

## What is Cube?

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

![Cube schema](https://ucarecdn.com/5f6287b5-fd33-47c8-95be-2dffd84ccfe2/)

Cube is designed to take the central part in the data pipeline, delivering consistent data to all downstream teams and data consumers. It serves as a source of truth for the metrics definitions, access control rules, and caching settings. Regardless of how many data consumers you have (e.g., front-end applications with embedded analytics or BI tools), Cube will deliver consistent data to all of them with its [REST API](https://cube.dev/docs/rest-api), [GraphQL API](https://cube.dev/docs/backend/graphql), or [SQL API](https://cube.dev/docs/backend/sql).

## How Cube works with Trino

In a typical data pipeline, Trino is placed upstream of Cube, providing unrestricted access to all data sources as well as data federation capabilities. You can use Cube to create an additional [semantic layer](https://cube.dev/blog/open-source-data-modeling) or a last-mile [caching layer](https://cube.dev/docs/caching) on top of Trino.

More importantly, you can use the set of APIs that Cube provides, including REST API and GraphQL API, to deliver the data directly to custom-built front-end applications, retaining low latency and high concurrency.

![Cube and Trino architecture](https://ucarecdn.com/cc996b6f-5f7d-4efb-83e6-960fc63546cd/)

Also, you can leverage Cube's [multitenancy](https://cube.dev/docs/multitenancy-setup) and [access control](https://cube.dev/docs/security) features to fully control and customize how every user, role, or data consumer accesses the data in Trino and underlying data sources.

## Try Cube with Trino

Cube is [open source](https://github.com/cube-js/cube.js), so you can feel free to [self-host and deploy](https://cube.dev/docs/deployment/overview) it. You can also run fully managed Cube in [Cube Cloud](https://cube.dev/cloud) which is the fastest and most convenient way to use Cube.

Start by signing up for a free [Cube Cloud account](https://cubecloud.dev/auth/signup). You'll be prompted to select the cloud provider (AWS, GCP, or Azure) and a region for your deployment:

![Cube Cloud: 1st step](https://ucarecdn.com/7ae7b4ae-57a1-4fb9-9e3d-bfa3fc011a67/)

Then, pick Trino from the data source options:

![Cube Cloud: 2nd step](https://ucarecdn.com/9dcf732a-eb10-4be9-bb8b-685e9060c5f0/)

Lastly, provide the credentials for the Trino connection:

![Cube Cloud: 3rd step](https://ucarecdn.com/aa796b76-ee85-4aae-ad66-c2a7e8ced05a/)

In a few seconds, you'll get your Cube Cloud deployment up and running, ready to query your Trino installation and deliver data to downstream applications.

## What's next?

Would you like to learn more about Cube and what it brings to the table? [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, give Cube a [star on GitHub](https://github.com/cube-js/cube.js), or [schedule a time](https://cube.dev/contact) to chat 1:1.

Trino

Perform interactive big data analytics with a fast and distributed query engine.

Announcing the Cube integration with Trino, the SQL query engine for big data 

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. Check out the [live demo](http://metabase.examplescube.dev/public/dashboard/947a9fa9-0c79-47e8-9cca-55cee7eafbcf) as well! 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/)

> In early December, we're hosting a webinar on replacing Looker with Metabase and Cube. [RSVP and save the seat.](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](http://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/multitenancy-setup) 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/cloud/getting-started/create) 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/)

We’ve prepared a [live demo](http://metabase.examplescube.dev/public/dashboard/947a9fa9-0c79-47e8-9cca-55cee7eafbcf) for you to check out. Once you enable public sharing, you’ll have the option to send a link to the dashboard to whoever you want!

If you would rather want to embed the dashboard, using an iframe will look like this.

<iframe
src="https://metabase.examplescube.dev/public/dashboard/947a9fa9-0c79-47e8-9cca-55cee7eafbcf"
frameborder="0"
width="800"
height="600"
allowtransparency
> </iframe>

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!

Metabase

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

Self-service analytics with Metabase and Cube

## The Background

[Cloud Academy][1] is a SaaS startup based in San Francisco, CA. Their e-learning platform aims to give tech workers a personalized upskilling experience in technical subjects such as cloud technology, DevOps, and software development. 

“Personalized” is somewhat of an understatement: Cloud Academy’s training resources and assessments are customized precisely to the user’s trajectory, role, and skills. In addition, the analytics and personalization granularity of the platform offers organizations robust insights into their teams’ proficiency. With these insights, companies can boost employee retention and accelerate company operations.

## The Challenge

Cloud Academy was searching for a modern analytics platform to improve its existing enterprise analytics offering.

[Alessandro Lollo][2], Senior Data Engineer, explains that the team needed to deliver a seamless, highly available embedded analytics experience based on CI/CD best practices that also allowed planned outages for required infrastructure maintenance. They also needed to leverage their existing data warehouse and maintain high flexibility in their data modeling to serve both internal and external end users. 

Before Cube, Cloud Academy used a major BI platform on which their enterprise embedded analytics UI was based; internal stakeholders used the BI platform directly. However, the team needed a solution that would allow for greater flexibility when it came to effective data modeling, security context orchestration, and caching.

### The Requirements

Cloud Academy was looking for a solution that could serve as the basis of their embedded analytics while also offering:

 - Compatibility with existing data warehouse and datasets
 - Highly flexible data modeling
 - Highly flexible security context orchestration and data visibility configuration
 - Fully managed platform with zero downtime and multi-deployment
 - Easy integration with existing CI/CD process
 - Highly flexible, powerful, and fully managed caching
 - SQL API

> “With Cube, we’ve been able to speed up time to release a new data model to production by 5x and decrease analytics downtime by 90%. And, since the Cube team is so responsive, collaborative, and fast to deliver, we benefit from new features very frequently.” 
> —Alessandro Lollo, Senior Data Engineer

## The Solution

Lollo’s team found Cube in mid-2021 and chose it for its highly flexible [caching layer][3] and fully managed, [Git-integrated][4], and zero-downtime deployments.  

It took ten engineers about a month to onboard and integrate Cube with Cloud Academy’s existing CI/CD platform. After these initial processes, they delivered their first Cube-based analytics app to enterprise customers in less than three weeks.

Cube’s flexible data modeling framework made it easy for the team to use their existing data warehouse as a single source of truth, allowing them to serve consistent data models to both enterprise customers and internal stakeholders.

In addition, [Cube Store][5]’s fully managed pre-aggregation capabilities allowed them to boost the response times of complex data models that serve both internal and external use cases. 

Lastly, Cube Cloud’s isolated deployment and Git integration enabled the team to implement true and efficient SDLC, while its [RBAC framework][6] has served as a component in security context orchestration. 

__With Cube, Cloud Academy was able to speed up releases of new data models in production by 5x while decreasing their platform’s analytics downtime by 90%.__

Another surprising benefit was Cube’s [Alerts][7] feature, which provided the team with a simple yet effective mechanism to monitor deployments’ API health and pre-aggregation build failures.  

The cherry on top? “Since the Cube team is responsive, collaborative, and fast to deliver, we benefit from new features very frequently,” says Lollo.

## The Future

As they progress in their Cube implementation, Lollo’s team is planning to expand into incremental pre-aggregations and experiments using Cube’s [SQL API joins][8]. 

Looking ahead, they’re most excited for future Cube releases including [metrics layer][9], [Cube Store’s alternative to Redis][10], and [YAML support][11]. 

As for advice for others considering Cube Cloud, Lollo says, “When we first found Cube, we considered hosting it internally. However, we realized doing so would require quite the overhead from our DevOps team. If you plan on using Cube but don’t want to (or can’t) increase your infrastructure OPEX, then go for Cube Cloud—you won’t regret it.”

_Have an exciting Cube case study and want to be featured? Drop us a line: [hello@cube.dev][12]_

_Interested in managed [Cube Cloud][13] for your data modeling, access control, and caching needs? [Request a 1:1 here][14], or find us on [Slack][15] and [GitHub][16]._

[1]: https://cloudacademy.com/
[2]: https://www.linkedin.com/in/alessandrolollo/?originalSubdomain=it
[3]: https://cube.dev/docs/caching#overview
[4]: https://cube.dev/docs/cloud/release-notes/12-2021#git-integration
[5]: https://cube.dev/docs/deployment/overview#cube-store
[6]: https://cube.dev/docs/recipes/role-based-access#enforcing-role-based-access
[7]: https://cube.dev/docs/cloud/dev-tools/alerts
[8]: https://cube.dev/docs/backend/sql#sql-api
[9]: https://github.com/cube-js/cube.js/issues/5044
[10]: https://cube.dev/blog/replacing-redis-with-cube-store
[11]: https://github.com/cube-js/cube.js/issues/5045
[12]: mailto:hello@cube.dev
[13]: https://cube.dev/cloud
[14]: https://cubecloud.dev/auth/signup
[15]: https://slack.cube.dev/
[16]: https://github.com/cube-js/cube.js

Tamar Barlev

User Stories

How Cloud Academy sped up data modeling by 5x and decreased analytics downtime by 90%

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