Evaluate on TPC-DS

Inspect the historical terabyte result, then run a current evaluation.

TPC-DS is the standard retail and e-commerce benchmark for decision-support analytics. You can inspect the exact evidence behind our published SF1000 result — the report, the per-question byte and route matrices, and the live A/B records — and this guide shows how to put Tessallite in front of your own current SF1 or SF100 TPC-DS dataset and ask the same everyday questions the raw way and the accelerated way. The SF1000 exercise was a one-off and is retired; its public report is historical evidence, not an execution path. Because the internal runner, seed, and complete query suite are not part of the public package, your run is an independent evaluation rather than a byte-for-byte replay; the absolute numbers depend on your platform, region, and pricing.

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 analytical and decision-support systems, because the schema and the questions look like a real business. Tessallite sits in front of your source database: the source stays the system 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)Historical one-off result. The published Tessallite evidence was measured here on BigQuery; this scale is retired and is not available for execution.
SF1000 is retired. The published terabyte result remains available as historical evidence. Current evaluation guidance covers SF1 and SF100 only; do not generate, load, or recreate the retired SF1000 dataset. The Tessallite benchmark is TPC-DS-derived, not an official, audited TPC result, and it does not use the TPC logo. Tessallite does not redistribute generated data.

What to expect

The same answer, for a fraction of a cent.

These are the headline figures from the historical SF1000 run on BigQuery. They remain published evidence, not a current hosted-demo or execution tier. For a current evaluation, use SF1 or SF100; your absolute numbers will depend on your source platform, region, and pricing.

$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 database

A source database 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 source database. 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.

Run your own evaluation

Six steps from raw data to a verified result.

These steps let you reproduce the method on your own data — they are not a packaged replay of our exact run. Work up the current scale ladder in order — SF1, then optionally SF100. Prove the whole flow at SF1 first; SF1000 is retired and remains available only as historical evidence.

1

Load the data

Generate TPC-DS data with dsdgen at SF1 and load the 24 tables into your source database. This is your system 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 source SQL (your baseline) and once through Tessallite. Turn the source-side 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 source 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 source 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 source 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 source 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 source 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 source-side 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 source 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

  • For current work, use SF1 first and optionally SF100; SF1000 is historical evidence only.
  • 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.

Inspect the evidence, then evaluate on your own data.

The evidence package contains the historical terabyte report and its raw run records — the PDF, the per-question byte and route matrices, and the A/B result file — for you to inspect. It is an evidence package, not a runnable reproduction kit; use the steps above to evaluate Tessallite on your own SF1 or SF100 TPC-DS data.