Evaluate on TPC-DS

Reproduce the terabyte result yourself.

TPC-DS is the standard retail and e-commerce benchmark for data-warehouse analytics. This guide shows how to put Tessallite in front of a TPC-DS dataset — from a 1 GB laptop scale to a full terabyte — and ask the same everyday business questions the raw way and the accelerated way, so you can verify the cost and the answers for yourself.

What it is

A standard dataset, used the honest way.

TPC-DS models a large retailer selling through store, catalogue, and web channels. It is widely used to test the performance of systems built for data warehousing and analytics, because the schema and the questions look like a real business. Tessallite sits in front of your warehouse: the warehouse stays the source of truth, and Tessallite adds governed modelling, multi-protocol access, route selection, and transparent acceleration.

Scale factorApprox. sizeWhat it is for
SF1~1 GBDevelopment and smoke validation. The first path for schema, load, model, acceleration, and query checks. Runs comfortably on a laptop-class deployment.
SF100~100 GBRehearsal scale. Use after SF1 is stable to validate load time, model ergonomics, and acceleration behaviour.
SF1000~1 TB (2.88 billion sales records)Flagship scale. The published Tessallite result was measured here, on BigQuery.
The Tessallite benchmark is TPC-DS-derived. It is not an official, audited TPC result, and it does not use the TPC logo. The data is generated with the public TPC-DS toolkit; you generate your own copy to evaluate — Tessallite does not redistribute the generated data.

What to expect

The same answer, for a fraction of a cent.

These are the headline figures from the published SF1000 run on BigQuery. When you reproduce it, your absolute numbers will depend on your warehouse, region, and pricing — but the shape holds: the accelerated route reads a tiny maintained summary instead of the whole terabyte, and returns the identical answer.

$330 → $0.05

Cost to ask one everyday question 1,000 times — raw BigQuery versus with Tessallite.

66 GB → a few KB

Data scanned to answer it — the same answer from a maintained summary.

4 / 4 identical

Every accelerated answer matched the raw-source answer, within tolerance.

A team running 40 dashboards refreshed hourly asks these questions about 350,000 times a year — roughly $116,000 in BigQuery scan today, about $18 with Tessallite. Read the full report — all 17 business questions.

Before you start

Prerequisites.

A source warehouse

A warehouse you can load TPC-DS data into and that Tessallite can read through a governed connection. The published run used BigQuery; any supported source works.

  • Read access for Tessallite's connection.
  • A separate write target for materialised aggregates.

TPC-DS data

Generate it with the public TPC-DS toolkit (dsdgen) at the scale you want, then load the table files into your warehouse. Start at SF1.

  • 24 TPC-DS tables, standard schema.
  • Keep the generated data private to your environment.

A Tessallite deployment

A running Tessallite stack with the gateway reachable. Community is enough to evaluate at SF1; larger scales follow the same steps.

  • Gateway on JDBC and XMLA.
  • A tenant and project to hold the model.

Reproduce it

Six steps from raw data to a verified result.

Work up the scale ladder in order — SF1, then SF100, then SF1000. Prove the whole flow at SF1 first; the larger scales are the same steps against a bigger dataset.

1

Load the data

Generate TPC-DS data with dsdgen at SF1 and load the 24 tables into your warehouse. This is your source of truth and your raw-cost baseline.

2

Build the model

Connect the source, add the tables, and define the semantic model: store_sales as the fact, LEFT joins to the dimensions, and the business measures (net sales, gross margin, return rate).

3

Seed acceleration

Define the aggregates and pockets that match the recurring questions — for example monthly sales by channel and category — and let Tessallite maintain them.

4

Connect a tool

Point Excel, Power BI, a JDBC client, the API, or the agent at the gateway. Every tool reads the same governed model and gets the same answer.

5

Run raw vs accelerated

Ask each business question twice: once as direct warehouse SQL (your baseline) and once through Tessallite. Turn the warehouse result cache off so every run executes for real.

6

Check and compare

Confirm the accelerated answer equals the raw answer within tolerance, then compare bytes scanned and cost. Record the route Tessallite chose for each question.

Sample questions

Ask the same thing, two ways.

These are real questions from the curated suite. On the left is the direct warehouse SQL you run as the baseline; on the right is the equivalent question against the Tessallite model. Same answer, far less to read. Replace {project}.{dataset} with your own warehouse location.

1. Monthly net sales by channel

Routes to: aggregate

Net sales by month and sales channel for 2001. The baseline unions the three sales channels and joins the date dimension; the Tessallite query is a single governed statement.

Direct warehouse SQL (baseline)
SELECT d.d_year  AS sales_year,
       d.d_moy   AS sales_month,
       channel,
       SUM(net_sales) AS net_sales
FROM (
  SELECT ss_sold_date_sk AS sold_date_sk,
         'store' AS channel,
         ss_net_paid AS net_sales
  FROM `{project}.{dataset}.store_sales`
  UNION ALL
  SELECT cs_sold_date_sk, 'catalog', cs_net_paid
  FROM `{project}.{dataset}.catalog_sales`
  UNION ALL
  SELECT ws_sold_date_sk, 'web', ws_net_paid
  FROM `{project}.{dataset}.web_sales`
) sales
JOIN `{project}.{dataset}.date_dim` d
  ON d.d_date_sk = sales.sold_date_sk
WHERE d.d_year = 2001
GROUP BY sales_year, sales_month, channel
ORDER BY sales_year, sales_month, channel
Through Tessallite
SELECT year,
       month,
       sales_channel,
       SUM(net_sales) AS net_sales
FROM tpcds_retail_analytics
WHERE year = 2001
GROUP BY year, month, sales_channel
ORDER BY year, month, sales_channel

2. Top categories by net sales

Routes to: aggregate

Rank product categories by net sales for 2001 across all channels.

Direct warehouse SQL (baseline)
SELECT i.i_category AS item_category,
       SUM(net_sales) AS net_sales
FROM (
  SELECT ss_item_sk AS item_sk, ss_sold_date_sk AS sold_date_sk,
         ss_net_paid AS net_sales
  FROM `{project}.{dataset}.store_sales`
  UNION ALL
  SELECT cs_item_sk, cs_sold_date_sk, cs_net_paid
  FROM `{project}.{dataset}.catalog_sales`
  UNION ALL
  SELECT ws_item_sk, ws_sold_date_sk, ws_net_paid
  FROM `{project}.{dataset}.web_sales`
) sales
JOIN `{project}.{dataset}.item` i
  ON i.i_item_sk = sales.item_sk
JOIN `{project}.{dataset}.date_dim` d
  ON d.d_date_sk = sales.sold_date_sk
WHERE d.d_year = 2001
GROUP BY item_category
ORDER BY net_sales DESC, item_category
LIMIT 20
Through Tessallite
SELECT item_category,
       SUM(net_sales) AS net_sales
FROM tpcds_retail_analytics
WHERE year = 2001
GROUP BY item_category
ORDER BY net_sales DESC, item_category
LIMIT 20

3. Store return-rate exceptions

Routes to: source

Stores with the highest return rate in 2001. An exception-style question that stays on the governed source route until a matching aggregate is seeded — useful for seeing how Tessallite reports the route it chose.

Direct warehouse SQL (baseline)
SELECT s.s_state AS store_state,
       s.s_store_name AS store_name,
       SAFE_DIVIDE(SUM(sr.sr_return_amt),
                   NULLIF(SUM(ss.ss_net_paid), 0)) AS return_rate,
       SUM(ss.ss_net_paid)  AS net_sales,
       SUM(sr.sr_return_amt) AS return_amount
FROM `{project}.{dataset}.store_sales` ss
JOIN `{project}.{dataset}.date_dim` d
  ON d.d_date_sk = ss.ss_sold_date_sk
JOIN `{project}.{dataset}.store` s
  ON s.s_store_sk = ss.ss_store_sk
LEFT JOIN `{project}.{dataset}.store_returns` sr
  ON sr.sr_item_sk = ss.ss_item_sk
 AND sr.sr_ticket_number = ss.ss_ticket_number
WHERE d.d_year = 2001
GROUP BY store_state, store_name
HAVING net_sales > 0
ORDER BY return_rate DESC, net_sales DESC
LIMIT 20
Through Tessallite
SELECT store_state,
       store_name,
       return_rate,
       SUM(net_sales)    AS net_sales,
       SUM(return_amount) AS return_amount
FROM tpcds_retail_analytics
WHERE year = 2001
GROUP BY store_state, store_name
ORDER BY return_rate DESC, net_sales DESC
LIMIT 20

The published report runs the full set of 17 business questions, including the CFO weekly revenue dashboard that routes to a maintained pocket. See every question and its measured numbers.

Best practices

Measure it so the numbers stand up.

A benchmark is only useful if it is honest. These are the controls the Tessallite run uses, and the ones we recommend you apply to yours.

Measurement discipline

  • Turn the warehouse result cache off so every run executes for real.
  • Run each question several times; discard a warmup run.
  • Record P50 and P95 latency, variance, bytes processed, and the route chosen.
  • Note the date, region, compute model, and versions with the run.

Correctness first

  • Compare each accelerated answer back to the raw warehouse answer before it counts.
  • Use an explicit tolerance, and compare row order exactly for ranked or top-N questions.
  • Pin each measure to the exact source columns so the accelerated value equals the baseline.
  • If an accelerated answer ever disagrees, treat it as a failure, not a speed-up.

Scope honestly

  • Work up the scale ladder in order: SF1, then SF100, then SF1000.
  • Cap the bytes a single query may bill so a runaway query is caught, not paid for.
  • Label which scale every result came from; never relabel evidence across scales.
  • Call it TPC-DS-derived, not an official audited TPC result.

See the proof, then run it yourself.

Read the measured terabyte result, take the full report with its raw run records, and get Tessallite to reproduce it on your own data.