“The report is no longer ordered. It just opens.”

A 15-minute ThoughtSpot report now opens in 0.2 seconds

A data warehouse under a surface that couldn't change — zero edits to queries or schema, on 200+ million products.

Get in touch

A US supplier to retail chains · architecture and delivery · 2025, ongoing

15 min → 0.2 s

the largest customer's report

Zero

changes on the customer side

200M+

products in the warehouse

Summary

A US supplier to retail chains keeps over 200 million items in a data warehouse and reads them through ThoughtSpot. A report that used to take fifteen minutes now opens in 0.2 seconds; another, at four minutes, opens in 0.1.

The constraint was double: the queries are generated by the customer’s BI tool and cannot be changed, and the schema cannot be touched because the saved reports they use every day depend on it. The speed-up had to come from beneath an unchanged surface — through distribution and sort keys, materialized views refreshed daily, and moving exports into object storage.

The customer changed nothing. Their saved reports worked the same day, with the same queries.

The problem

The client sells fashion accessories to large US retail chains, and those chains look at their own data through ThoughtSpot. The key report took up to fifteen minutes — long enough that a customer opens it once, orders it and goes back to other work, instead of exploring the data.

The constraint

Double: ThoughtSpot generates the queries and they can't be optimized, and the schema can't be touched because customers have saved reports that depend on it. The speedup had to come from beneath an unchanged surface.

What we did

Redshift — because the client is moving to AWS anyway
The warehouse chosen by the client’s direction, not a feature list. Data arrives from the source system through export jobs to S3 and is loaded into the warehouse.
200M+ products
Schema untouched — we work beneath it
Distribution and sort keys chosen against the queries ThoughtSpot actually generates, not assumptions. Customers’ saved reports worked the same day.
Zero changes on the customer side
The heaviest reports precomputed
Incrementally refreshed materialized views with dependent views, daily refresh, and a validation script that checks precomputed data never drifts from the source.
15 min → 0.2 s

CUSTOMER QUERIES — UNCHANGED

ThoughtSpot — generates the queries

The customers’ BI tool generates the SQL itself — we couldn’t change a single query. Data arrives from the source system through export jobs to S3, then loads into the warehouse.

0.2 s — same report, same query — only the warehouse changed

The result

The largest customer's report: from over fifteen minutes to two tenths of a second. Saved reports worked the same day; nobody on the customer side had to change anything. A customer now asks ten questions in one conversation instead of one per meeting — the report is no longer ordered, it's explored.

For context

10 s

the limit above which a user stops following a response and turns to another task

Nielsen Norman Group

1 s

the limit of an uninterrupted train of thought

Nielsen Norman Group, after Miller (1968)

A fifteen-minute report was ninety times above the first limit. It now sits inside the second.

What we’d do differently

We would measure more reports. We have two measurements and both are dramatic, but twenty would show the distribution — where the speed-up holds and where it stops.

We would also wire the materialized views to refresh monitoring from the start. A daily cycle is enough here, but when one refresh is missed, the error shows up in a report rather than in a log.

Four re-platformings, zero downtimeThe same rule at another scale: MySQL as the only fixed point through four re-platformings.A construction ERP next to SAPBuilt alongside the existing system, not instead of it.When you can’t change the query or the schemaThe same work in full: what may be changed when the query is someone else’s.

All 18 case studies

Amazon Redshift
S3
MySQL
ThoughtSpot
Materialized views
Sort / dist keys

Are your reports waited on instead of used?

Get in touch

.eOBxHN{width:8px;height:8px;border-radius:50%;background:var(--mt-accent-bright);}The problem

The constraint

What we did.

Redshift — because the client is moving to AWS anyway

Schema untouched — we work beneath it

The heaviest reports precomputed

The result

.bezobb{width:8px;height:8px;border-radius:50%;background:var(--mt-muted);}What we’d do differently

Are your reports waited on instead of used?

The problem

What we did

What we’d do differently