Skip to main content
Card class: Hero • Category: Cross-Channel: Revenue at Risk

​
At a glance

A dual-axis chart that plots Databricks DBU burn against ecommerce order volume over the trailing 7 days. The premise is simple: if your Databricks compute exists to serve the business, then the cost of that compute should rise and fall roughly in step with how much business is flowing through. When DBU burn climbs while orders stay flat, you are paying more to process the same amount of work, which is the signature of an inefficient or runaway pipeline. This card is the cost-efficiency conscience of the platform team.
Left axis (Databricks)DBU burn, the Databricks-defining cost unit, aggregated per day from the billable usage data (the account-level usage API, mirrored by the system.billing.usage system table). Includes job compute, SQL warehouse, and interactive compute.
Right axis (ecom)Order volume from the connected storefront (Shopify, BigCommerce or Adobe Commerce), counted per day over the same window.
What it tracksThe ratio and shape of the two series. A healthy workspace shows the lines tracking together; divergence (DBU up, orders flat or down) is the signal.
Data sourceDatabricks billable usage data for DBU; the connected ecommerce platform’s orders data for volume. Both normalised to daily buckets in your reporting time zone.
Time window7d (trailing 7 days, day-level buckets).
Alert triggerDBU +50% WoW with orders flat. When week-over-week DBU burn rises 50% or more while order volume stays within its normal band, the card flags a cost-efficiency divergence.
Rolesowner, finance, engineering, operations

​
Calculation

The card builds two aligned daily time series over the trailing 7 days. The Databricks series is total DBU burned per day. The engine reads billable usage records (the account billable usage data, equivalent to the system.billing.usage system table) and sums usage_quantity in DBU across all SKUs (jobs compute, SQL warehouse, all-purpose interactive, DLT) per calendar day in your reporting time zone. This is the same figure that underpins the DBU Burned (24h) card, just bucketed over a week. The ecommerce series is order count per day, pulled from whichever storefront connector is linked (Shopify, BigCommerce or Adobe Commerce), counting paid or placed orders per day over the same buckets and time zone. The divergence test compares this week’s DBU total to the prior week (week-over-week, WoW). If DBU is up 50% or more while order volume is flat (within its normal week-over-week band, typically plus or minus 15%), the card raises the cost-efficiency flag. The point is not the absolute DBU number; it is the broken correlation. Compute that grows faster than the business it serves is, by definition, getting less efficient per order.

​
Worked example

A mid-market homeware retailer runs its analytics lakehouse on Databricks: nightly ETL jobs build the sales and inventory marts, a DLT pipeline streams clickstream events, and a SQL warehouse serves the merchandising dashboards. The platform team reviews this card every Monday. Reading taken on Monday 15 Jun 26, covering the trailing 7 days.
DayDBU burnedOrdersDBU per 1,000 orders
Mon 08 Jun1,1804,120286
Tue 09 Jun1,2054,050298
Wed 10 Jun1,2404,210295
Thu 11 Jun1,9904,180476
Fri 12 Jun2,5404,300591
Sat 13 Jun2,6103,980656
Sun 14 Jun2,6804,090655
The order line is almost perfectly flat: the storefront is doing its usual 4,000 to 4,300 orders a day. The DBU line, however, more than doubles from Wednesday to Sunday. Week-over-week the DBU total is up 61% (from roughly 8,300 the prior week to 13,445 this week) while orders are within 2%. The alert fires. 
Cost-efficiency divergence (the only thing that matters here):
  - Prior week DBU total:      ~8,300
  - This week DBU total:       13,445
  - WoW change in DBU:         +62%
  - WoW change in orders:      +1.5% (flat)
  - DBU per 1,000 orders:      290 (baseline) -> 655 (now), a 2.3x regression
  - If DBU runs ~$0.55 each:   extra ~$2,800 this week for zero extra business
The platform engineer drills in. The order series rules out a genuine demand spike. The jump starts on Thursday 11 Jun, which lines up with a deploy: a new clickstream enrichment step was added to the DLT pipeline that, because of a missing watermark, was reprocessing the full event history on every micro-batch instead of just new events. The pipeline was burning compute proportional to total data size, not to the day’s orders. Three takeaways the team should remember:
  1. The order line is the control. DBU burn on its own is just a cost number that always looks scary. Plotted against flat orders, it becomes a diagnosis: you are paying more for the same output. Always read the ratio, not the raw burn.
  2. Divergence has a date. The DBU line bent on a specific day. That day is almost always a deploy, a schema change, a new pipeline, or an auto-scaling config edit. Use it to narrow the change set rather than auditing everything.
  3. Cost runaway is usually a correctness bug. Reprocessing all history, a missing partition filter, a cartesian join, a cluster that never auto-terminates: the expensive ones are bugs that also waste money. Fixing the efficiency usually fixes a latent data-quality risk too.

​
Sibling cards

CardWhy pair it with DBU Burn vs Ecom Order VolumeWhat the combination tells you
DBU Burned (24h)The single-day absolute version of the left axis.Confirms whether today is contributing to the weekly divergence or is already back to baseline.
DBU Burn +50% Week-over-WeekThe pure-Databricks anomaly alert that shares the +50% WoW logic.If both fire, the burn spike is real and independent of order volume; if only the cross-channel card fires, orders may actually be down.
Avg DBU per Job RunDecomposes the burn to the job level.Tells you whether one job got more expensive or the whole fleet did.
DBU by Cluster (7d)Attributes the weekly burn to specific clusters.Pinpoints which cluster owns the divergence.
Idle Cluster DBU Wasted (24h)Separates productive burn from waste.If wasted DBU is rising with total DBU, the divergence is auto-termination, not workload.
Pipeline Lag vs Ecom Order FlowThe freshness sibling in the same cross-channel category.High burn that is not buying you fresher data is the worst case: paying more and still lagging.
Databricks Health ScoreThe composite that folds cost-efficiency into overall health.A burn divergence alone can drag the health score even when nothing is failing.

​
Reconciling against the source

Where to look in Databricks for the DBU side:
Account Console → Usage for the billable usage dashboard with DBU broken down by SKU, workspace and day. system.billing.usage (Unity Catalog system table) for the authoritative per-record usage data; sum usage_quantity grouped by usage_date to rebuild the left axis exactly. system.billing.list_prices if you want to convert DBU to currency to match a finance figure.
Where to look for the ecom side:
The order count comes from the connected storefront’s own reporting (Shopify Analytics, BigCommerce Analytics, or Adobe Commerce reports). Match the same daily buckets and time zone.
Why our number may legitimately differ:
ReasonDirectionWhy
Billing lagVortex IQ value briefly lowerBillable usage records can land in system.billing.usage a few hours after the compute ran; the most recent day may be incomplete until the feed settles.
Time zoneDay boundaries shiftVortex IQ buckets in your reporting time zone; the Account Console usage view defaults to UTC. A late-night job can land in a different day.
SKU scopeVortex IQ may be higherThe card sums all DBU SKUs (jobs, SQL, interactive, DLT); a console view filtered to one SKU will read lower.
Order definitionOrder count differsVortex IQ counts paid or placed orders per the connector’s order definition; a storefront report counting sessions or including cancelled orders will not match.
Cross-connector reconciliation:
CardExpected relationshipWhat causes divergence
shopify.total_orders / bigcommerce.total_ordersThe right axis should match the storefront’s own order count for the same days.A mismatch means a time-zone or order-status definition difference; reconcile the order definition first.
databricks.dbu_burned_24hThe sum of seven daily DBU values here should equal seven stacked readings of the 24h card.Billing lag on the latest day is the usual culprit.

​
Known limitations / FAQs

DBU burn went up but so did orders, and the card did not flag. Is that right? Yes. The card only flags divergence: DBU rising while orders stay flat. If both rise together, your compute is scaling with the business, which is exactly what you want. The cost is going up but the cost per order is holding. Watch the DBU-per-1,000-orders ratio in the worked example: as long as that ratio is stable, growth in absolute burn is healthy. Why 50% week-over-week and not a fixed DBU number? A fixed DBU threshold would fire constantly for large workspaces and never for small ones. Week-over-week percentage normalises across workspace size and naturally accounts for seasonality in your own baseline. You can tune the threshold per profile in the Sensitivity tab if your workload is spiky by design (for example, weekly full rebuilds). Our DBU genuinely spikes every Sunday for a weekly rebuild. How do we stop false alerts? Compare like with like. The WoW logic already compares this Sunday to last Sunday, so a regular weekly rebuild should not trip it. If it still does, the rebuild is growing faster than your data, which is itself worth knowing. For predictable batch spikes, raise the per-profile threshold or scope the alert to exclude the known rebuild job. The most recent day shows lower DBU than expected. Bug? Almost always billing lag. Billable usage records can take a few hours to fully land in system.billing.usage, so the current day is often incomplete until the feed settles. Judge the divergence on complete days; the final day fills in over the following hours. Can DBU divergence be caused by something other than a bad pipeline? Yes, several benign causes: a cluster left running over a weekend (see Idle Cluster DBU Wasted), a backfill or one-off reprocessing job, a new dashboard driving heavy interactive SQL, or a Photon or instance-type change that altered the DBU rate. The card flags the divergence; Avg DBU per Job Run and DBU by Cluster (7d) tell you which. Does this card convert DBU to currency? No, the chart is in raw DBU because DBU rates vary by SKU, cloud, commit tier and region. To estimate cost, multiply DBU by your effective rate, or join system.billing.usage to system.billing.list_prices in Databricks for the exact figure. Keeping the card in DBU avoids a currency conversion that would drift from your actual contract pricing.

​
Tracked live in Vortex IQ Nerve Centre

DBU Burn vs Ecom Order Volume is one of hundreds of KPI pulses Vortex IQ tracks across Databricks and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.