ModelUnit economicsForecastingExplainable math

Showback Cost Model

Generic methodology to define unit costs and translate telemetry volumes into spend forecasts—with scenario overlays to evaluate optimizations and governance decisions.

Back to Program View Architecture

What this model answers

Translate growth → spend

If you can forecast volumes (telemetry), you can forecast spend using stable unit costs.

Separate growth from efficiency

Totals can rise with adoption. Unit costs reveal whether the platform is getting better or worse.

Prioritize the right optimizations

Changes should target the real driver (scan, runtime, retention footprint), not guesswork.

Make conversations actionable

Allocation dimensions + unit costs support credible customer discussions and accountability.

Telemetry + cost attribution

Telemetry provides the denominators (TB ingested, query minutes, GB scanned). Cost attribution provides the numerators (spend mapped to buckets and allocation dimensions).

Without both, you can’t link behavior to spend—so you can’t credibly talk to customers, and you risk building the wrong optimizations.

Method

Step 1 — Define cost buckets and drivers

—Choose a small set of explainable buckets: ingestion, storage, query, shared overhead.
—Choose measurable telemetry drivers: TB ingested, TB-months, query minutes, GB scanned.
—Confirm bucket-to-driver mapping is stable and reviewable.

Step 2 — Compute baseline unit costs

—Use recent history in a rolling window (e.g., last 2–3 months).
—UnitCost = SpendBucket ÷ DriverVolume.
—Treat early variance as expected; trend stability matters more than one month.

Step 3 — Forecast volumes from telemetry

—Forecast driver volumes using trend + known step-changes (new tenants, new regions).
—Forecast each driver separately (ingestion vs query behave differently).

Step 4 — Forecast spend (do-nothing scenario)

—SpendForecast = ForecastVolume × UnitCost (per bucket).
—Add shared overhead separately if it does not scale linearly with drivers.

Step 5 — Apply scenario overlays

—Retention reduces TB-months (storage driver).
—Indexing and query tuning reduce GB scanned and/or query minutes.
—Compaction can improve both storage footprint and query efficiency.

Step 6 — Publish showback views

—Allocate spend across dimensions (team/product/dataset) using consistent mappings.
—Ensure drill-down paths exist from owner → driver → raw usage → cost bucket.

Unit cost definitions

Metric

Definition

Notes

Cost per TB ingested

Ingestion spend ÷ TB ingested

Use for ingestion efficiency + growth-to-spend translation.

Cost per TB stored

Storage spend ÷ TB-months (avg retained TB in month)

Use for retention/tiering impacts and storage footprint control.

Cost per query minute

Query spend ÷ total query runtime minutes

Use for engine efficiency and workload mix changes.

Cost per GB scanned

Scan spend ÷ GB scanned

Useful when scan-based pricing dominates query costs.

Assumptions and constraints

Unit costs are directional. Use trend direction and stability, not one-month precision.
Re-baseline after step-changes (pricing model shifts, engine migration, major architecture changes).
Keep cost buckets explainable and consistently mapped to allocation dimensions.
Use a rolling window (e.g., last 2–3 months) to smooth noise while staying current.

Formulas (copy/paste)

Baseline unit costs

For each bucket b and driver d:
  UnitCost[b] = Spend[b] / Volume[d]

Examples:
  UnitIngest = IngestSpend / TBIgnested
  UnitStore  = StorageSpend / TBMonths
  UnitQuery  = QuerySpend / QueryMinutes
  UnitScan   = ScanSpend / GBScanned

Do-nothing spend forecast

For forecast month t:
  SpendForecast[b,t] = VolumeForecast[d,t] * UnitCost[b]

TotalForecast[t] = sum_b( SpendForecast[b,t] ) + SharedOverhead[t]

Scenario overlay (illustrative)

Retention:
  TBMonthsScenario[t] = TBMonthsBaseline[t] * (1 - retention_reduction_pct)

Indexing / tuning:
  GBScannedScenario[t] = GBScannedBaseline[t] * (1 - scan_reduction_pct)
  QueryMinutesScenario[t] = QueryMinutesBaseline[t] * (1 - runtime_reduction_pct)

Scenario total

Replace baseline volumes with scenario volumes:
  TotalScenario[t] = sum_b( VolumeScenario[d,t] * UnitCost[b] ) + SharedOverhead[t]

Savings[t] = TotalBaseline[t] - TotalScenario[t]

Program overview

Why showback matters, the platform approach, governance, and outcomes.

Architecture

Ingest → allocate → publish flow and explainability paths.

Note: This page is intentionally generic (no vendor or internal system names). Swap in your platform equivalents as needed.

What this model answers

Translate growth → spend

If you can forecast volumes (telemetry), you can forecast spend using stable unit costs.

Separate growth from efficiency

Totals can rise with adoption. Unit costs reveal whether the platform is getting better or worse.

Prioritize the right optimizations

Changes should target the real driver (scan, runtime, retention footprint), not guesswork.

Make conversations actionable

Allocation dimensions + unit costs support credible customer discussions and accountability.

Telemetry + cost attribution

Telemetry provides the denominators (TB ingested, query minutes, GB scanned). Cost attribution provides the numerators (spend mapped to buckets and allocation dimensions).

Without both, you can’t link behavior to spend—so you can’t credibly talk to customers, and you risk building the wrong optimizations.

Method

Step 1 — Define cost buckets and drivers

—Choose a small set of explainable buckets: ingestion, storage, query, shared overhead.
—Choose measurable telemetry drivers: TB ingested, TB-months, query minutes, GB scanned.
—Confirm bucket-to-driver mapping is stable and reviewable.

Step 2 — Compute baseline unit costs

—Use recent history in a rolling window (e.g., last 2–3 months).
—UnitCost = SpendBucket ÷ DriverVolume.
—Treat early variance as expected; trend stability matters more than one month.

Step 3 — Forecast volumes from telemetry

—Forecast driver volumes using trend + known step-changes (new tenants, new regions).
—Forecast each driver separately (ingestion vs query behave differently).

Step 4 — Forecast spend (do-nothing scenario)

—SpendForecast = ForecastVolume × UnitCost (per bucket).
—Add shared overhead separately if it does not scale linearly with drivers.

Step 5 — Apply scenario overlays

—Retention reduces TB-months (storage driver).
—Indexing and query tuning reduce GB scanned and/or query minutes.
—Compaction can improve both storage footprint and query efficiency.

Step 6 — Publish showback views

—Allocate spend across dimensions (team/product/dataset) using consistent mappings.
—Ensure drill-down paths exist from owner → driver → raw usage → cost bucket.

Unit cost definitions

Metric

Definition

Notes

Cost per TB ingested

Ingestion spend ÷ TB ingested

Use for ingestion efficiency + growth-to-spend translation.

Cost per TB stored

Storage spend ÷ TB-months (avg retained TB in month)

Use for retention/tiering impacts and storage footprint control.

Cost per query minute

Query spend ÷ total query runtime minutes

Use for engine efficiency and workload mix changes.

Cost per GB scanned

Scan spend ÷ GB scanned

Useful when scan-based pricing dominates query costs.

Assumptions and constraints

Unit costs are directional. Use trend direction and stability, not one-month precision.

Re-baseline after step-changes (pricing model shifts, engine migration, major architecture changes).

Keep cost buckets explainable and consistently mapped to allocation dimensions.

Use a rolling window (e.g., last 2–3 months) to smooth noise while staying current.

For each bucket b and driver d: UnitCost[b] = Spend[b] / Volume[d] Examples: UnitIngest = IngestSpend / TBIgnested UnitStore = StorageSpend / TBMonths UnitQuery = QuerySpend / QueryMinutes UnitScan = ScanSpend / GBScanned

Retention: TBMonthsScenario[t] = TBMonthsBaseline[t] * (1 - retention_reduction_pct) Indexing / tuning: GBScannedScenario[t] = GBScannedBaseline[t] * (1 - scan_reduction_pct) QueryMinutesScenario[t] = QueryMinutesBaseline[t] * (1 - runtime_reduction_pct)