Customer Usage & Capacity Data

What these pipelines support

Distinct from billing (which is transactional and customer-facing), the usage and capacity pipelines support internal decisions:

• How much GPU capacity to procure next quarter.
• Which regions to expand into.
• Which customer segments to invest in.
• What pricing changes to consider.
• Which existing reservations are under- or over-utilized.
• How customer behavior is evolving.

Utilization marts

The utilization mart is the analytics-friendly view of "what's running, what's idle":

• Fact: instance-hours. One row per GPU per hour with state (busy/idle/maintenance) and customer.
• Dimensions: Customer, region, SKU, instance class, contract type.
• Aggregations: Utilization percentage by SKU per region per day; by customer per month; by contract.

This mart is the substrate for fleet-level decisions. "How much B200 capacity is idle at any given moment?" should be a one-line SQL query.

Capacity planning

The capacity-planning pipelines blend utilization history with forward forecasts:

• Committed capacity model. What capacity is committed to which customers across what time periods. From contracts and reservations.
• Demand forecast. What additional demand to expect from existing customers (growth) and new ones (sales pipeline).
• Supply roadmap. When new GPUs come online, when datacenter buildouts complete.
• Capacity gap. Where forecast demand exceeds supply (need to procure / build) and where it's below (idle / writedown risk).

The DE function builds the data layer; product / finance / leadership consume the dashboards. Some neoclouds invest substantial DS effort in the forecasting models (covered in the DS guide); the DE provides the data they need.

Commitment tracking

Reserved-capacity customers commit to GPU-hours over multi-year terms. Tracking commitments is critical:

• Are customers drawing down their commitments at the expected pace?
• Are reservations approaching expiry without renewal discussions?
• Are commitments under-utilized (red flag for renewal)?
• Are commitments over-utilized (selling more than committed; opportunity for upsell)?

The DE team owns the commitment fact table joining contracts (from CRM / contract management) with usage (from billing / telemetry). Account managers use the resulting dashboards to manage renewals.

Customer cohorts

Cohort analysis is standard SaaS analytics applied to GPU customers:

• Acquisition cohort: when the customer signed up.
• Workload cohort: training-heavy vs inference-heavy vs mixed.
• Size cohort: mid-market vs enterprise.
• Geography cohort: regional distribution of usage.

Cohort marts let product and growth teams ask "are this quarter's signups behaving differently from last quarter's?" The answer often drives marketing and product investment.

✓ Check yourself

Answer from memory before opening each one.

1. Why is the utilization fact one row per GPU per hour rather than one per customer per day?

   Show answer

   Fleet questions, such as how much B200 capacity is idle right now, need state per GPU at fine grain. A daily customer grain cannot answer them, while a fine-grain fact rolls up to any coarser view. See utilization marts.

2. Forecast demand for next quarter is 1,200 GPUs and the supply roadmap shows 1,000 online. What does the capacity gap tell you, and what would the opposite result mean?

   Show answer

   A gap of 200 GPUs to procure or build. If supply exceeded demand, the surplus is idle capacity and a writedown risk. Data engineering builds the committed, forecast and supply tables; forecasting models are data science work. See capacity planning.

3. A customer committed 1 million GPU-hours over 36 months and has used 12 percent after 14 months. What do you read from this?

   Show answer

   The straight-line pace at month 14 is about 39 percent, so the customer is well under the pace. That is a renewal risk and a prompt for the account manager to ask why. See commitment tracking.

4. Why does the commitment table join CRM contract data to usage rather than read billing alone?

   Show answer

   Contracts say what was committed and when it expires, and usage says what was drawn. Neither alone gives pace or risk. See commitment tracking.

5. Last quarter's signup cohort shows lower 90-day usage than the quarter before. Before anyone reacts, what do you check?

   Show answer

   Whether the cohort mix changed: more small or inference-heavy customers lowers average usage without any change in behavior. Cut the cohort by workload and size, then compare like with like. See customer cohorts.

Takeaway

• Usage and capacity pipelines serve internal decisions about procurement, regions, pricing and renewals, not customer invoices.
• The utilization mart holds one row per GPU per hour with state, customer, region, SKU and contract, so idle capacity is a one-line query.
• Capacity planning compares committed capacity, demand forecast and supply roadmap to expose gaps and surplus.
• Commitment tracking joins contracts to usage to show drawdown pace against expected pace.
• Cohort marts separate real behavior change from a shift in customer mix.

Marketplace neoclouds add a stream of bids, listings and preemptions on top of that. → Marketplace Event Streams

Further reading

• Dimensional Modeling Techniques — Kimball Group, accessed 2026. Fact grain, dimensions and the periodic snapshot pattern behind the mart.
• AggregatingMergeTree — ClickHouse, accessed 2026. Incremental aggregation, which suits fine-grain utilization rollups.
• DuckDB documentation — DuckDB Foundation, accessed 2026. A fast way to prototype mart queries on Parquet before choosing a warehouse.
• Delta Lake documentation — Delta Lake project, accessed 2026. Table versioning and time travel for reproducible marts.