GuardLabs
Demo stand · SQL / BI

From a slow query and numbers nobody trusts — to a datamart and a dashboard that doesn't lie

We walk through the whole path on one example: a reporting SQL query that was choking a live dashboard, a star schema with materialized views built under it, a ready BI dashboard with 4 charts — and separately, a real case where two reports disagreed on a number, and how we caught it.

Data is synthetic, modeled on a mid-size online store (~2.4M sales rows over 18 months). Optimization techniques are not disclosed in detail — that part is our know-how.
01 · Performance

Before / after on a real reporting query

The query behind a "revenue by channel over a period" dashboard, joining 4 tables with correlated subqueries for the refund filter.

Before
38.4 s
After
0.9 s
×42
faster
2.4M
rows in fact_sales
0
dashboard timeouts / week

What it meant for the client

  • The Tableau dashboard used to open in >40s and half the filters timed out — now it opens in <1s, filters stay responsive.
  • A nightly "just in case" cron report that re-computed the same numbers is gone — the live query is fast enough on its own now.
  • The same query now holds up under concurrent access from several analysts at once, with no degradation.
Specific techniques (indexing, execution plan, data model changes) are our commercial know-how. The demo shows the result, not the recipe.
02 · Data model

Star schema behind the dashboard

A fact table plus dimensions, with a layer of materialized views on top — that's what the BI tool (Power BI / ClickHouse) actually reads. The dashboard never touches raw transactional tables directly.

dim_date day · week · quarter dim_product category · brand · sku fact_sales qty · revenue · discount · cost ~2.4M rows dim_customer segment · region · cohort dim_channel web · marketplace · retail mv_daily_sales refreshed hourly mv_customer_ltv refreshed nightly
Fact table Dimensions Materialized views — the dashboard reads from these
03 · Dashboard

A ready dashboard on live (synthetic) numbers

4 charts plus a summary table, reading as one visual system instead of a pile of mismatched screenshots.

📊 Sales overview · last 12 weeks
source: mv_daily_sales · synthetic data
Revenue (12 wk)
$5.14M
▲ 8.3% WoW
Orders
48,260
▲ 4.1%
Avg order value
$106.60
▲ 3.9%
Refund rate
3.1%
▼ 0.4 pp
Weekly revenue trend $, M
Revenue by channel share, %
Top-10 products by revenue $, thousands
Summary by region 12 weeks
04 · Reconciliation

Why two reports disagreed — and how we caught it

A real class of discrepancy (the numbers below are a synthetic demo example): the Tableau dashboard and the finance export for the same month showed different revenue.

Tableau dashboard (June)
$512,700
Finance export (June)
$498,340
Discrepancy of $14,360 (2.8% of monthly revenue) — 41 orders landed in the wrong reporting day.
Verification stepFindingOrdersAmount, $
1. Diff daily totals between sourcesGap appears exactly at the May 31 / June 1 boundary
2. Compare the timezone used for cutoffsThe SQL query bucketed timestamps by UTC; the finance export used the store's local business day
3. Orders placed 21:00–23:59 local on May 31 (18:00–20:59 UTC)Landed in the June 1 report instead of May 314114,360
4. Fixed the day boundary in mv_daily_salesBoth reports now match, day for day00

Need your reports faster, or your dashboard numbers reconciled?

Send us a slow query or an example of a mismatch — we'll tell you what's going on and outline a plan. Fixed price, timeline in days.