*This blog post is the outcome of a collaboration between [Isha Terdal](https://github.com/ishaterdal) from Cube, [Andrey Pechkurov](https://github.com/puzpuzpuz) from QuestDB and [Yitaek Hwang](https://github.com/yitaek), a QuestDB contributor.*

Time series data has now become a critical part of the data applications landscape. And at Cube, we’re super excited about how QuestDB changes the way companies work with it. In this blog, we’ll take a look at how QuestDB and Cube work together to provide a time series data pipeline that is fast, consistent, and reliable.


## What is QuestDB?

[QuestDB](https://questdb.io) is a performant open-source database for time series data. Its codebase is optimized for storing and processing large amounts of time-stamped data efficiently through lightning-fast SQL queries. 

QuestDB also allows for integration with a variety of popular open source tools through the PostgreSQL wire protocol, and its use cases range from real-time analytics and monitoring to market/tick data and industrial telemetry.


## What is Cube?

[Cube](https://cube.dev) is a headless business intelligence platform that can organize all your data into a structured data model. Defining metrics upstream of your applications—so, for instance, defining the granularity of data observed—enables you to access the same data metrics across various applications, use cases, and teams. 

With Cube’s data modeling capabilities, you can shorten your project timeline from weeks to hours. And, with its API-first approach, Cube you can connect to your streamlined data via an API that best suits your application and infrastructure (whether it be a REST, GraphQL, or SQL API).


## How QuestDB and Cube Work Together

So there you have it — a structured data model built on top of a fast repository of time series data. QuestDB is optimized for slicing and dicing time-stamped data through its [SQL extensions](https://questdb.io/docs/concept/sql-extensions/). Cube also offers multiple ways of [pre-aggregating data](https://cube.dev/docs/caching/using-pre-aggregations) effectively building a caching layer on top of your data to speed up performance of slow queries. Together, QuestDB and Cube have your time series data all set up for use downstream.


## Exploring Crypto Prices with QuestDB and Cube

Let’s illustrate how the two app stacks work together. In this example, we’ll show how you can efficiently build an end-to-end crypto price analysis platform with QuestDB and Cube. We will use Cube to expose time series data in QuestDB via multiple APIs.


![full-connection-process](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/9313db63-7368-425c-95b0-144e0b370531.png)


### Setting Up QuestDB and Importing Time Series Data

First, you should set up a new project directory in your local system e.g. ‘questdb_cube’.

We’ll begin our demo by using the [Crypto dataset](https://www.kaggle.com/datasets/sudalairajkumar/cryptocurrencypricehistory) to show how we can create a time series database in QuestDB, and then organize the data downstream with Cube. Since both applications can be initiated using [Docker](https://docs.docker.com/get-docker/), let’s start up both engines by stringing them together using Docker Compose.

Then, create a docker-compose.yml file in the project directory with the following contents:


```yaml
version: "2.2"

services: 
  cube: 
    environment: 
      - CUBEJS_DEV_MODE=true
    image: "cubejs/cube:latest"
    ports: 
      - "4000:4000"
    volumes: 
      - ".:/cube/conf"
  questdb: 
    container_name: questdb
    hostname: questdb
    image: "questdb/questdb:latest"
    ports: 
      - "9000:9000"
      - "8812:8812"
```


Add an .env file that gives Cube the details for connecting to QuestDB:


```
CUBEJS_DB_HOST=questdb
CUBEJS_DB_PORT=8812
CUBEJS_DB_NAME=qdb
CUBEJS_DB_USER=admin
CUBEJS_DB_PASS=quest
CUBEJS_DB_TYPE=questdb
```


Run the containers using the following command:

 `docker-compose up -d`


![QuestDB in Docker](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/efb18c3c-882c-4f6b-a920-adf3af725f2b.png)


Navigate to [localhost:9000](http://localhost:9000) to open QuestDB’s Web Console, click on the “Upload” icon on the left-hand panel, and import the [csv files of interest](https://www.kaggle.com/sudalairajkumar/cryptocurrencypricehistory). While this example uses the Ethereum dataset, any of the coin datasets will work perfectly.


![QuestDb Web Console](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/35aae092-6989-4967-ae8a-6fede2a53e0a.png)


Note: Cube works best with table names that do not contain any special characters. So, we’re going to rename our table using the following command:


```sql
RENAME TABLE 'coin_Ethereum.csv' TO 'ethereum';
```


![Table Rename Query](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/299f3352-e426-463c-90bf-fc20001bf8af.png)


Now, we’re able to query the data:

![QuestDB Web Console showing database](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/e8a828e7-f72f-4191-b6e5-d1693af856ed.png)


### Building a Cube Data Model

The next step is to organize the time series data from QuestDB in a uniform and accessible manner; we do this by defining a data model.

The [Cube data model](https://cube.dev/docs/schema/fundamentals/concepts) consists of entities we call ‘cubes’ that define metrics by **_dimensions_** (qualitative categories) and **_measures_** (numerical values). So, with that in mind, let’s continue by creating a cube for our Ethereum data.

Navigate to localhost:4000/#/schema and click on the Ethereum table we imported into QuestDB:


![Tables in Cube](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/23687509-dc3b-4e84-b569-a26a53a2c339.png)


Clicking on the ‘Generate Schema’ button automatically bootstraps a cube for the data in our local project directory—a folder named ‘schema’. This folder contains a file called ‘Ethereum.js’ that you can open with any text editor.

By default, the ‘count’ field falls under **measures**; name, symbol, and date fields are auto-populated as **dimensions**. Since we’re interested in price columns, let’s add them in (defined as ‘high’ and ‘low’ in the data model as shown below):


```javascript
cube(`Ethereum`, {
  sql: `SELECT * FROM ethereum`,

  measures: {
    count: {
      type: `count`,
      drillMembers: [name, date]
    }
  },
      
  dimensions: {
    name: {
      sql: `${CUBE}."Name"`,
      type: `string`
    },
        
    symbol: {
      sql: `${CUBE}."Symbol"`,
      type: `string`
    },
        
    date: {
      sql: `${CUBE}."Date"`,
      type: `time`
    },

    high: {
      type: 'number',
      sql: `${CUBE}."High"`
    },

    low: {
      type: 'number',
      sql: `${CUBE}."Low"`
    }
  }
});
```


Then, by clicking on the ‘Build’ tab in Cube, we can see the data:


![Data in Cube](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/bfdcf494-88fc-4fd5-b3aa-18b5f61b7c83.png)


We can also use Cube’s built-in measure type, **'avg’** to calculate average high or low prices:

  
```javascript
  measures: {
    avgHigh: {
      type: 'avg',
      sql: `${CUBE}."High"`
    },
    
    avgLow: {
      type: 'avg',
      sql: `${CUBE}."Low"`
    }
  },
```


Next, we can recreate the classic price-over-time graph:


![Price over Time graph](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/5af8cf98-b457-4c71-90f6-d0f49839ac05.png)


Additionally with Cube, you can pre-aggregate data to speed up the queries. Cube will create materialized rollups of specified dimensions and measures internally, and use aggregate awareness logic to route the queries. This logic will use the most optimal pre-aggregation available to serve the query instead of processing the raw dataset. You can define pre-aggregations within your data model as shown below. 


```javascript
  preAggregations: {
    main: {
      measures: [avgHigh, avgLow],
      timeDimemsion: date,
      granularity: `day`
    }
  }
```


You can learn more about Cube [pre-aggregations in the documentation.](https://cube.dev/docs/caching/pre-aggregations/getting-started)


### Consuming Time Series Data via APIs

If you’ve followed along so far, your data is now processed and organized neatly into a data model—aka a cube. So, what’s next? Good question. The answer is simply to connect the data to your application.

The versatility of Cube—given its ‘headlessness’—enables you to seamlessly connect to any data application you need, whether it’s a dashboard, notebook, or the backend of your application.

By taking an API-first approach, Cube as a headless BI tool brings about endless ways of using your data downstream of your time series data sources. And, API endpoints ensure that the metrics are available and consistent across different applications, tools, and teams.

Let’s take a look at the various ways you can connect to the data model you built via its APIs.


![Cube API view](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/1da1cc0e-3ecc-44b2-8a10-acb4b9bdb81b.png)


There are three API endpoints that you can use to access your data model: 

1. REST API: If you’re using Cube as the backend for your application, you can connect to it with the [REST API](https://cube.dev/docs/rest-api). 
2. GraphQL API: If you’re looking to use standard GraphQL queries for embedded analytics or other data apps, you can connect to Cube with the [GraphQL API](https://cube.dev/docs/backend/graphql).
3. SQL API: If you’re querying data using standard ANSI SQL format, you can connect to Cube with the [SQL API](https://cube.dev/docs/backend/sql). No need to learn additional syntax—just use SQL to interact with your data. This is especially useful if you are working with BI tools, dashboards, or data science models.


![GraphQL API](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/344d451c-b36f-4461-b193-b87b9fda0a3d.png)


### Conclusion

With QuestDB’s speedy processing of time series data, and Cube’s data modeling capabilities for consistent definitions, we can now efficiently power many use cases with real-time, reliable data. So, think embedded analytics, business intelligence, machine learning—you name it.

Curious to see QuestDB’s incredibly performant time series database in action? Check out the [QuestDB demo](https://demo.questdb.io). Eager to join the QuestDB discussion? Join the QuestDB community on [GitHub](https://github.com/questdb/questdb) and [Slack](https://slack.questdb.io/).

Want to see how QuestDB and Cube can power your project together? [See the docs](https://cube.dev/docs/) and [create a free Cube Cloud account today](https://cube.dev/cloud). Have questions or feedback? [Drop us a line](https://cube.dev/contact), [join our Slack](https://slack.cube.dev/), or [check us out on GitHub](https://github.com/cube-js/). 

QuestDB

Time Series Data Analytics with QuestDB and Cube