Why Cube Cloud Makes Your Query Costs Predictable (and Lower)

Scaling AI and analytics means making data more accessible to everyone in the organization, but that also comes with growing costs. Every query your team runs against a cloud data platform eats into your budget, especially when dashboards refresh on a schedule, embedded analytics serve end users, or AI agents are constantly querying your data sources. And those prices can quickly spiral out of control.

Understanding the actual cost of a single query becomes more important than ever. Whether you're building internal dashboards or powering a public-facing data app, every query to your data warehouse has a price, and cumulatively, they rack up a large bill. That’s why we put Cube Cloud to the test. Using a standardized benchmark, we compared the cost-per-query of Cube Cloud against direct queries to a modern cloud data platform with the cost-per-query model outlined in this Select.dev blog post. We'll show why Cube's compute model offers more predictable and lower costs per query, especially at high throughput.

How Compute Pricing Works

Let’s break down how compute-based pricing works in both scenarios.

1. Modern Cloud Data Warehouses

Most modern platforms charge based on the following:

• Compute time: Measured in seconds or minutes, typically billed in "credits" or "slots."
• Concurrency scaling: Simultaneous users can spin up additional compute clusters.
• Query complexity: Longer or more complex queries consume more resources.
• Data Scanned: The amount of data read to execute the query.

So when 10 users hit a dashboard at once, you're not necessarily paying for 10 separate compute sessions but increasing total compute time. The cost-per-query can be estimated by pro-rating the warehouse cost over the number of queries completed during that time, as outlined in Select.dev's cost-per-query model. This is exactly how we calculated query costs in our benchmark, by measuring how many queries ran within a fixed window and then allocating the total compute cost proportionally.

To make the comparison fair and realistic, we also ran a separate load test to identify the maximum QPS (queries per second) the data warehouse could sustain for this specific query type. This allowed us to optimize concurrency and throughput to minimize cost-per-query, a common practice in real-world production environments, where teams tune dashboards and batch queries to get the most out of their warehouse time.

2. Cube Cloud

Cube Cloud works differently:

• Pre-aggregations and Cube Store eliminate the need to hit the warehouse for most queries. However, building pre-aggregations could be costly since these long-running queries require considerable computing power.
• Cube costs are based on API instance and worker compute usage, not query volume or amount of data scanned.
• You're effectively paying for throughput, not for query complexity.

Benchmarking Query Cost: Cube vs Modern Data Warehouse

We ran a benchmark using the industry-standard TPC-H dataset at scale factor 100 to compare query cost predictability and performance. The test simulates a realistic dashboard scenario, with users issuing an increasing number of concurrent requests. Each query will contain a random set of parameters for the filters, ensuring we have a low cache-hit ratio to showcase the cost difference and be closer to a more realistic scenario.

Here's the exact SQL query used in the benchmark:

SELECT
  "part"."P_TYPE" "item_information__part_type",
  "region"."R_NAME" "item_information__region_name",
  "customer"."C_MKTSEGMENT" "item_information__market_segment",
  "lineitem"."L_SHIPMODE" "item_information__ship_mode",
  count(
    CAST(
      CONCAT(
        "lineitem"."L_ORDERKEY",
        "lineitem"."L_LINENUMBER"
      ) as TEXT
    ) || CAST("lineitem"."L_ORDERKEY" as TEXT)
  ) "item_information__count",
  sum("lineitem"."L_DISCOUNT") "item_information__total_discount",
  sum("lineitem"."L_EXTENDEDPRICE") "item_information__total_price",
  sum("lineitem"."L_EXTENDEDPRICE") - sum("lineitem"."L_DISCOUNT") - sum("lineitem"."L_TAX") "item_information__total_profit",
  sum("lineitem"."L_QUANTITY") "item_information__total_quantity",
  sum("lineitem"."L_EXTENDEDPRICE") - sum("lineitem"."L_DISCOUNT") "item_information__total_revenue"
FROM
  (
    SELECT *
    FROM TPCH_100.LINEITEM
    WHERE L_LINESTATUS = 'O' AND L_RETURNFLAG = 'N'
  ) AS "lineitem"
  LEFT JOIN "TPCH_100"."PART" AS "part" ON "lineitem"."L_PARTKEY" = "part"."P_PARTKEY"
  LEFT JOIN (
    SELECT *
    FROM TPCH_100.ORDERS
    WHERE O_ORDERSTATUS = 'O'
  ) AS "orders" ON "lineitem"."L_ORDERKEY" = "orders"."O_ORDERKEY"
  LEFT JOIN "TPCH_100"."CUSTOMER" AS "customer" ON "orders"."O_CUSTKEY" = "customer"."C_CUSTKEY"
  LEFT JOIN "TPCH_100"."NATION" AS "nation" ON "customer"."C_NATIONKEY" = "nation"."N_NATIONKEY"
  LEFT JOIN "TPCH_100"."REGION" AS "region" ON "nation"."N_REGIONKEY" = "region"."R_REGIONKEY"
WHERE
  "lineitem"."L_SHIPDATE" BETWEEN '1994-01-01' AND '1995-02-01'
  AND "part"."P_TYPE" = 'PROMO POLISHED NICKEL'
  AND "nation"."N_NAME" IS NOT NULL
  AND "region"."R_NAME" IS NOT NULL
  AND "lineitem"."L_RETURNFLAG" IS NOT NULL
GROUP BY 1, 2, 3, 4
ORDER BY 5 DESC
LIMIT 100

How Cube Optimized This Query

In Cube, we modeled the same query using a pre-aggregation that rolls up the relevant measures and dimensions. This reduces the complexity of the query and shifts heavy computation to the pre-aggregation layer.

Here's the pre-aggregation configuration used:

pre_aggregations:
  - name: item_rollup
    measures:
      - CUBE.total_discount
      - CUBE.total_price
      - CUBE.total_profit
      - CUBE.total_quantity
      - CUBE.total_revenue
      - CUBE.count
    dimensions:
      - CUBE.ship_mode
      - customer.market_segment
      - part.part_type
      - nation.nation_name
      - region.region_name
    allow_non_strict_date_range_match: true
    time_dimension: ship_date
    granularity: month
    partition_granularity: year
    refresh_key:
      every: 1 hour

Note: We assume a complete rebuild of this pre-aggregation once per hour, a common scenario in real-world systems, especially with slowly changing dimensions.

Benchmark Setup

To make the comparison fairer, we ran the benchmark assuming you need a Cube Cloud Production cluster turned on 24/7. That is to keep the pre-aggregations updated. Since there's a fixed cost of building pre-aggregations, there's a scenario when querying directly the Data Warehouse is cheaper than using pre-aggregations. This is a real-world consideration that has to be made when using Cube Cloud in production. When using Cube Cloud, you don't want to pre-aggregate everything; you should add pre-aggregations for queries with repeatable query patterns and a very low Cube's in-memory cache-hit ratio.

Then, to size the Cube Cloud Production Cluster, we started with the minimum size of two API instances, and we scaled up every 100 queries to simulate the increased required throughput. When we reach the maximum of 10 API instances per Production Cluster, the next level of horizontal scaling will be using a Cube Cloud Multi-Cluster deployment. That complicates the calculation a bit since sometimes having more Multi-Clusters than API instances is better. So, for this exercise, we will stick to regular Production Clusters and theoretically unlimited API instances. Having a Cube Store Cluster turned on 24/7 costs 96 CCUs per day, and assuming a $0.3 price per credit, we get $28.8 per day, which only includes 2 API instances. There's a maximum of 10 API instances per cluster with a maximum theoretical throughput of 100 Queries Per Second; each additional API instance costs 1 CCU per hour. For the Data Warehouse the cost used was $2 per credit, using the same tier as Cube Cloud with no discounts.

That means that while a Data Warehouse could take hours to calculate 1000 queries, a Cube Cloud Production Cluster just needed 13 seconds on average to finish serving 1000 queries when scaled to 10 API instances. Read more about how Cube is consistently faster than modern Data Warehouses for OLAP queries.

Benchmark Results

As expected at the beginning of the series, the initial cost of building pre-aggregations makes the cost per query more expensive in Cube Cloud. Still, as volume increases, the cost per query in Cube Cloud decreases drastically, while the cost per query in the Data Warehouse decreases at a slower rate.

Now, 1000 queries in a day is nothing in a real-world scenario. At one million queries per day, the cost per query in Cube Cloud is $0.0012, the cost per query in a Data Warehouse is $0.0480, even after increasing compute size to increase throughput. That's around 40 times cheaper to run your high-throughput workloads in Cube Cloud using pre-aggregations. In addition to that, running this type of query in Cube Cloud with pre-aggregations is 31 times faster.

The main difference between the cost of both scenarios is that in the Data Warehouse, the cost grows proportionally with usage at a high rate. In Cube Cloud, there is a fixed cost for building pre-aggregations. The cost per query for using Cube Store is much lower than the cost per query in any modern Data Warehouse; in other words, Cube Store has excellent economies of scale compared to cloud data platforms.

The actual cost of running this experiment in Cube Cloud was no more than $200 per day; I extrapolated the results to consider having this deployment running 24/7, while the cost for the Data Warehouse was $719.70, which was calculated using this Select.dev blog post.

Scale Smarter, Not Harder

Cube Cloud fundamentally changes the cost dynamics of querying data at scale by acting as a smart query acceleration layer. While cloud data platforms rack up charges as usage grows, Cube’s fixed-cost pre-aggregation model unlocks massive savings, especially once you cross into high-volume territory. Using pre-aggregations and in-memory stores, Cube can reduce your cost-per-query with performance and scale to match.

At 1 million queries per day, Cube is 40x cheaper and 31x faster than running the same queries directly on the warehouse. That’s not just better performance. That’s operational optimization. Now you can pay for throughput, instead of how complex a SQL query is. If you’re looking to make your analytics architecture future-ready with predictable costs and lightning-fast query times, it’s time to put Cube in the middle. Contact sales to learn how Cube could reduce cloud data platform costs.