Where the money goes — and whether you can trust the number. DBU spend dollarized by SKU, product, job, notebook, endpoint, tag and identity; negotiated-vs-list price; egress and GenAI tokens.
War story“We're 100% tagged” — and nobody could be billedA perfect tagging-coverage dashboard that produced zero real chargeback.system.billing.usageThe account's billed-consumption fact table and the backbone of almost every query in this folder.
record_type. A single logical charge can appear as multiple rows across record_type values (ORIGINAL, then a later RETRACTION/RESTATEMENT correction), so a *net* figure must SUM usage_quantity across all record types — never filter to ORIGINAL.usage_date (DATE, the recommended partition/filter column), usage_end_time (TIMESTAMP, used to pick the active price window), ingestion_date (load date, distinct from usage_date — drives the freshness/lag caveat).usage_quantity — the metered amount in usage_unit. This is DBUs/bytes/hours/tokens, NOT dollars.usage_unit — DBU, STORAGE_SPACE bytes, hours, TOKEN, etc. Queries that price against a per-DBU rate filter usage_unit = 'DBU' so they never blend units.usage_type — confirmed enum: COMPUTE_TIME, STORAGE_SPACE, NETWORK_BYTE, NETWORK_HOUR, API_OPERATION, TOKEN, GPU_TIME, ANSWER.record_type — ORIGINAL / RETRACTION / RESTATEMENT (the correction/trust signal).sku_name, billing_origin_product (product line: JOBS / SQL / DLT / MODEL_SERVING / VECTOR_SEARCH / DEFAULT_STORAGE / … — populated but with no published closed enum, so literals like DEFAULT_STORAGE are treated as unverified; a blank value is "unattributed", not zero), cloud, currency_code, workspace_id (NULL for account-level SKUs — kept as "not workspace-attributable"), account_id.custom_tags (MAP — compute-resource and serverless-usage-policy tags; keys are customer-defined, never hardcode them).usage_metadata (STRUCT): cluster_id, warehouse_id, instance_pool_id, job_id, job_run_id, notebook_id, endpoint_id, endpoint_name, storage_api_type, catalog_id, metastore_id (AWS-only), source_region/destination_region (always NULL on GCP), networking_client, recipient_id, usage_policy_id, budget_policy_id (deprecated). These are sparse/conditional — populated only for the compute type that generated the row (e.g. job_id only for jobs compute, notebook_id only for notebook-attached interactive usage), otherwise NULL.identity_metadata (STRUCT): run_as, owned_by (SQL-warehouse usage only), created_by. Sparse, and replaced with the literal '__REDACTED__' in FedRamp workspaces — treat '__REDACTED__'/NULL as "identity unavailable".product_features (STRUCT): is_serverless, is_photon, jobs_tier, sql_tier, dlt_tier, performance_target, serving_type. Sparse — subfields are NULL where the choice doesn't apply.system.billing be enabled on the metastore, plus SELECT granted on the table. A feature the account doesn't use simply yields no rows for it (e.g. no serving = no MODEL_SERVING rows), which is a valid empty result, not $0.system.billing.list_pricesThe public list (pre-discount) price history per SKU. Joined to usage to dollarize DBUs.
[price_start_time, price_end_time) validity window per (sku_name, cloud, currency_code, usage_unit). price_end_time IS NULL means the currently-active price.price_start_time, price_end_time, account_id, sku_name, cloud, currency_code, usage_unit, and the pricing STRUCT — pricing.default (typed STRING in docs) and pricing.effective_list (typed only as an object in docs; the nested pricing.effective_list.default scalar path and its numeric cast are unverified), plus pricing.promotional. Queries collect these raw as JSON strings so collection survives struct drift and dollarize in-engine.SELECT needed. Small table. Because the join is a point-in-time window match, the price predicate must be (price_end_time IS NULL OR usage < price_end_time) — using only usage < price_end_time silently zeroes recent usage.system.billing.account_pricesThe account's actual negotiated price history — the same shape as list_prices but carrying the discounted rate the account really pays.
[price_start_time, price_end_time) window per sku_name + cloud + currency_code + usage_unit). price_end_time IS NULL = currently-active negotiated price.price_start_time, price_end_time, account_id, sku_name, cloud, currency_code, usage_unit, and pricing.default (the negotiated rate; typed STRING, numeric cast unverified). Important: this table has only pricing.default — there is no pricing.effective_list here (that lives on list_prices). Actual-vs-list compares account_prices.pricing.default against list_prices.pricing.effective_list.default.SELECT needed. Multi-cloud/multi-currency accounts have several rows per sku_name, so joins must key on cloud + currency_code + usage_unit + sku_name, not sku_name alone.system.billing.attributed_usageDatabricks' fair-split allocation of shared-pool DBUs back to the consuming entity.
system.billing.usage: usage_date, usage_quantity, usage_unit, billing_origin_product, cloud, …).usage_date, cloud, billing_origin_product, usage_unit, usage_quantity.billing_origin_product = 'SQL'.system.billing.cloud_infra_costThe cloud provider's own infrastructure charge (instance hours, network/egress) that sits *outside* DBU pricing — the 10–25% of spend the usage table misses.
usage_date / cloud / currency_code.usage_date, cloud, currency_code, and cost (DOUBLE — a real billed dollar in the row's currency, unlike usage_quantity).$0. Do not LEFT JOIN compute change-history tables (warehouses/clusters) into this rollup — they fan out rows and double-count SUM(cost); dedupe to latest-row-per-id first in a separate step if attribution is needed.system.access.workspaces_latestA tiny workspace-id → name lookup, kept deliberately separate from billing.
workspace_id, workspace_name, status (active vs deleted).system.access (UC-required, SELECT needed; may not be enabled on every metastore). It is intentionally not joined into billing.usage at query time — if it's unavailable, only NAME resolution is lost and every per-workspace cost figure (keyed on workspace_id) still works, falling back to the numeric id.system.* schemas aren’t uniformly available — several (e.g. system.query, system.lakeflow) are still in preview or must be enabled per-metastore. A query that returns nothing usually means its schema isn’t enabled for your account yet.system.billing.list_prices) unless a query explicitly joins account_prices.Per-SKU net DBUs alongside their default-rate dollars and list-rate dollars, so an admin can quantify how much the account's discount actually saves on each SKU — both rate bases come from list_prices (no account_prices/negotiated-rate table exists in this environment).
system.billing.usagesystem.billing.list_pricesOne row = a cloud + SKU + usage_unit's DBU spend for the window, priced two ways. The columns that matter are net_default_cost (what you are estimated to actually pay) and net_list_cost (undiscounted list price) - the smaller the gap between them, the less discount you are realizing on that SKU.
RequiresSELECT on system.billing; GA
This lines up, for every DBU-billed SKU, what the account pays at its default rate against public list, so the per-SKU gap (net_list_cost − net_default_cost) is the directional dollar saving and feeds the discount-realization % and savings headline on the Pricing and Allocation tab. This environment has no account_prices/negotiated-rate table, so the true negotiated rate is unavailable and list_prices.pricing.default stands in for it — read the realized-saving figure as directional, not a contract-proof number. A SKU where the two are equal — or where net_default_cost is null while DBUs are large — flags a SKU with no matching active price row (coverage leakage). Both dollar bases are decimal casts labelled default/list-unverified and must not be promoted to a billed headline until confirmed on-workspace.
SELECT u.cloud, u.sku_name, u.usage_unit, u.billing_origin_product,
SUM(u.usage_quantity) AS net_usage_quantity,
SUM(u.usage_quantity * dp.default_rate) AS net_default_cost,
SUM(u.usage_quantity * lp.list_rate) AS net_list_cost,
-- status: discount-realization band on default-cost / list-cost (field heuristic; :warn_realization_ratio / :crit_realization_ratio).
CASE
WHEN SUM(u.usage_quantity * dp.default_rate) IS NULL OR SUM(u.usage_quantity * lp.list_rate) IS NULL THEN 'NOT_ASSESSED'
WHEN (SUM(u.usage_quantity * dp.default_rate) / NULLIF(SUM(u.usage_quantity * lp.list_rate), 0)) >= :crit_realization_ratio THEN 'CRITICAL'
WHEN (SUM(u.usage_quantity * dp.default_rate) / NULLIF(SUM(u.usage_quantity * lp.list_rate), 0)) >= :warn_realization_ratio THEN 'WARN'
ELSE 'OK'
END AS status
FROM system.billing.usage u
LEFT JOIN (
SELECT sku_name, cloud, usage_unit, price_start_time, price_end_time,
CAST(pricing.default AS DOUBLE) AS default_rate -- list_prices: pricing.default (account_prices does not exist)
FROM system.billing.list_prices
) dp
ON u.sku_name = dp.sku_name
AND u.cloud = dp.cloud
AND u.usage_unit = dp.usage_unit
AND u.usage_date >= DATE(dp.price_start_time)
AND (dp.price_end_time IS NULL OR u.usage_date < DATE(dp.price_end_time)) -- active rows carry NULL end_time
LEFT JOIN (
SELECT sku_name, cloud, usage_unit, price_start_time, price_end_time,
CAST(pricing.effective_list.default AS DOUBLE) AS list_rate -- list_prices: effective_list.default
FROM system.billing.list_prices
) lp
ON u.sku_name = lp.sku_name
AND u.cloud = lp.cloud
AND u.usage_unit = lp.usage_unit
AND u.usage_date >= DATE(lp.price_start_time)
AND (lp.price_end_time IS NULL OR u.usage_date < DATE(lp.price_end_time)) -- same active-row predicate
WHERE u.usage_date >= dateadd(day, -:period_days, current_date())
AND u.usage_date < current_date()
AND upper(u.usage_unit) = 'DBU' -- price only DBU rows against a per-DBU rate; never blend bytes/hours/tokens
GROUP BY u.cloud, u.sku_name, u.usage_unit, u.billing_origin_product
ORDER BY (SUM(u.usage_quantity * dp.default_rate) / NULLIF(SUM(u.usage_quantity * lp.list_rate), 0)) DESC NULLS LAST, net_list_cost DESC:period_daysdefault 30rolling window in days:warn_realization_ratiodefault 0.75share of list price you are estimated to actually pay that flags WARN:crit_realization_ratiodefault 0.9share of list price you are estimated to actually pay that flags CRITICAL - field heuristicnet_list_cost − net_default_cost) is the dollar saving the account realizes on that SKU — but since no negotiated-rate table exists here, pricing.default stands in for the negotiated rate, so read the gap as directional.| Column | How to read it |
|---|---|
| cloud | Cloud provider the SKU ran on (aws/azure/gcp); part of the grain and a price-join key, so the same sku_name can appear once per cloud. |
| sku_name | The billed SKU. The unit of comparison for default-vs-list; a SKU with net_usage_quantity but null costs has no matching active price row (coverage gap). |
| usage_unit | Always 'DBU' here (the WHERE clause filters upper(usage_unit)='DBU') — confirms the rate applied is a per-DBU rate, not bytes/hours/tokens. |
| billing_origin_product | Product line that generated the usage (JOBS/SQL/DLT/MODEL_SERVING/…); part of the GROUP BY so a SKU split across products yields multiple rows. Blank = unattributed, not zero. |
| net_usage_quantity | SUM(usage_quantity) in DBUs across all record_types over the window — the net metered consumption. DBUs, NOT dollars. |
| net_default_cost | SUM(usage_quantity × list_prices.pricing.default rate) — dollars at the account's default rate. This environment has no account_prices/negotiated-rate table, so pricing.default stands in for the negotiated rate. DEFAULT-UNVERIFIED; NULL if no active price row matched. |
| net_list_cost | SUM(usage_quantity × list_prices.pricing.effective_list.default rate) — dollars at public pre-discount list. LIST-UNVERIFIED; NULL if no list price row matched. net_list_cost − net_default_cost is the (directional) realized saving. |
net_default_cost stays well below net_list_cost - i.e. the realization ratio (net_default_cost / net_list_cost) is under :warn_realization_ratio (field heuristic; tune for your account's commit).
realization ratio at/above :warn_realization_ratio (WARN) or :crit_realization_ratio (CRITICAL) - you are paying close to list price on that SKU; or either cost column is NULL (NOT_ASSESSED - a priced-coverage gap, not $0).
| cloud | sku_name | usage_unit | net_usage_quantity | net_default_cost | net_list_cost |
|---|---|---|---|---|---|
| aws | ENTERPRISE_ALL_PURPOSE_COMPUTE | DBU | 12500 | 5500.00 | 6875.00 |
| aws | ENTERPRISE_SQL_COMPUTE | DBU | 3000 | 528.00 | 660.00 |
| azure | PREMIUM_JOBS_SERVERLESS_COMPUTE | DBU | 800 | NULL | NULL |
Rank SKUs by the net_list_cost − net_default_cost gap to see where the account realizes a saving; feed the per-SKU discount-realization % into the Pricing and Allocation tab, and chase any SKU with net_usage_quantity but null costs as a priced-coverage gap (missing active price row), never as $0. Because this environment has no negotiated-rate table, pricing.default stands in for the negotiated rate — read the gap as directional, and confirm on-workspace which list_prices rate should feed the finding before promoting any dollar figure.
Feeds into: actual (default) vs list $ per SKU; discount realization %; savings_usd headline on the Pricing & Allocation tab
Net DBU consumption and distinct run count per job per day, split by workspace, cloud, product line, and classic-vs-serverless placement.
system.billing.usageOne row = a day + workspace + job's DBU cost. The columns that matter are job_id (which job) and net_usage_quantity (its DBU burn that day) - distinct_runs lets you tell a job that is expensive because it runs constantly apart from one that is expensive because a single run is heavy.
RequiresSELECT on system.billing; GA
Jobs compute is usually the largest single product line on a Databricks bill, and this query pinpoints exactly which job_id drives the DBUs so an admin can target the worst offenders instead of the whole account. The is_serverless split lets you dollarize the jobs-on-all-purpose / classic-vs-serverless placement premium -- the same workload can cost materially more depending on where it runs. Pairing net_usage_quantity with distinct_runs surfaces failed-run and over-scheduled waste (many runs burning DBUs with little to show), which is often pure recoverable spend once the DBUs are priced.
SELECT usage_date, cloud, workspace_id, billing_origin_product,
usage_metadata.job_id AS job_id,
product_features.is_serverless AS is_serverless,
SUM(usage_quantity) AS net_usage_quantity,
COUNT(DISTINCT usage_metadata.job_run_id) AS distinct_runs,
-- status: magnitude band on daily DBU cost per job (field heuristic; :warn_job_dbus_per_day / :crit_job_dbus_per_day).
CASE
WHEN SUM(usage_quantity) IS NULL THEN 'NOT_ASSESSED'
WHEN SUM(usage_quantity) >= :crit_job_dbus_per_day THEN 'CRITICAL'
WHEN SUM(usage_quantity) >= :warn_job_dbus_per_day THEN 'WARN'
ELSE 'OK'
END AS status
FROM system.billing.usage
WHERE usage_date >= dateadd(day, -:period_days, current_date())
AND usage_date < current_date()
AND usage_unit = 'DBU'
AND usage_metadata.job_id IS NOT NULL
GROUP BY usage_date, cloud, workspace_id, billing_origin_product,
usage_metadata.job_id, product_features.is_serverless
ORDER BY net_usage_quantity DESC:period_daysdefault 30rolling window in days:warn_job_dbus_per_daydefault 50DBUs/day on a single job that flags WARN:crit_job_dbus_per_daydefault 200DBUs/day that flags CRITICAL| Column | How to read it |
|---|---|
| usage_date | The calendar day (DATE) the job consumption was metered. One row per job per day per placement, so the same job_id appears on multiple dates -- sum across dates for a period total. |
| cloud | The cloud provider for the usage (AWS/AZURE/GCP). Part of the grain and a required key when later joining price tables. |
| workspace_id | The workspace that ran the job. NULL for account-level SKUs; resolve to dev/uat/prod via cost_workspace_names downstream, otherwise it reads as an opaque numeric id. |
| billing_origin_product | The product line billed (typically JOBS for jobs-compute, but can be DLT or others). No published closed enum; a blank value is unattributed, not zero. |
| job_id | The Databricks job identifier (from usage_metadata.job_id). This is a stable id but carries no name/owner -- join to system.lakeflow.jobs (latest by change_time) for name and run_as. |
| is_serverless | product_features.is_serverless: TRUE for jobs-serverless, FALSE for classic jobs-compute. This is the placement-premium signal that separates serverless from classic runs of the same job. |
| net_usage_quantity | Net DBUs consumed by that job on that day/placement, SUM(usage_quantity) across all record_types (already correction-netted). DBUs, NOT dollars -- multiply by a per-DBU rate to dollarize. |
| distinct_runs | COUNT(DISTINCT usage_metadata.job_run_id) -- how many separate job runs generated the DBUs that day. High DBUs over few runs = heavy runs; high runs = frequent scheduling; pair with failed-run analysis to size retry/failure waste. |
net_usage_quantity below :warn_job_dbus_per_day DBUs/day per job (field heuristic - tune :warn_job_dbus_per_day for your account).
net_usage_quantity at/above :warn_job_dbus_per_day (WARN) or :crit_job_dbus_per_day (CRITICAL) DBUs/day - field heuristic; a job that is consistently in-band and just large may be fine, a job whose per-run cost keeps climbing is the one to open first.
| usage_date | workspace_id | job_id | is_serverless | net_usage_quantity | distinct_runs |
|---|---|---|---|---|---|
| 2026-07-04 | 1234567890123456 | 849302 | false | 412.75 | 24 |
| 2026-07-04 | 1234567890123456 | 849302 | true | 58.10 | 3 |
| 2026-07-04 | 9876543210987654 | 771044 | false | 1180.00 | 1 |
Rank jobs by net_usage_quantity within a workspace/day, then resolve the top job_ids to names and run_as via system.lakeflow.jobs (SCD2, latest by change_time), dollarize the DBUs through list_prices, and target the biggest classic-jobs-compute lines and high-run-count offenders for right-sizing, scheduling, or moving off all-purpose compute.
Feeds into: per-JOB DBU cost -> which jobs cost the most; DOLLARIZES the jobs-on-all-purpose premium (the 17 jobs) and per-job failed-run waste; per-workspace job cost
Net DBU consumption and record count broken down by every custom_tags key/value pair per usage_date, cloud, workspace, and product line — with untagged usage retained as NULL-key rows so the "% untagged" denominator is real.
system.billing.usageOne row = a day + workspace + product + tag key/value pair's DBU usage, including a row per tag_key = NULL where a resource carried no tags at all. The columns that matter are tag_key/tag_value (a real chargeback cut needs a key whose values actually vary) and net_usage_quantity - pair the NULL-tag rows against cost_totals_by_sku_day's total for the same window to get the untagged share.
RequiresSELECT on system.billing; GA
Chargeback and showback only work if spend is attributable to a team, project, or cost center via tags — and this query is how an admin proves whether that attribution actually exists. The NULL-key rows produced by the OUTER explode quantify the DBUs that carry no tag at all (the % untagged spend that no one can be billed for), while counting distinct tag_values per tag_key exposes the trap where a single umbrella tag covers ~100% of DBUs yet resolves to one cost center, giving zero real team-level chargeback. On an account spending six or seven figures, untagged or falsely-"100%-tagged" DBUs are money that lands in a shared bucket and gets cross-subsidized instead of billed back to the workload that caused it.
SELECT usage_date, cloud, workspace_id, billing_origin_product, tag_key, tag_value,
SUM(usage_quantity) AS net_usage_quantity,
COUNT(*) AS record_count
FROM system.billing.usage
LATERAL VIEW OUTER explode(custom_tags) t AS tag_key, tag_value
WHERE usage_date >= dateadd(day, -:period_days, current_date())
AND usage_date < current_date()
GROUP BY usage_date, cloud, workspace_id, billing_origin_product, tag_key, tag_value
ORDER BY usage_date DESC, workspace_id, tag_key, tag_value:period_daysdefault 30rolling window in days| Column | How to read it |
|---|---|
| usage_date | The calendar day (DATE) the consumption was metered. Today is always excluded; treat the most recent day as provisional due to billing populate lag. |
| cloud | Cloud provider for the row (e.g. AWS/AZURE/GCP). Part of the grain and a required join key elsewhere — never collapse tags across clouds without keeping this. |
| workspace_id | Numeric workspace the usage belongs to; lets chargeback be cut per workspace. NULL for account-level SKUs (not workspace-attributable). Resolve to dev/uat/prod names downstream via cost_workspace_names. |
| billing_origin_product | Product line that generated the usage (JOBS/SQL/DLT/MODEL_SERVING/…). No published closed enum, so treat literals as unverified; a blank value is 'unattributed', not zero. |
| tag_key | One key from the custom_tags map (customer-defined — never hardcode key names). NULL means the source usage row carried no tags at all: this is the untagged bucket that drives the % untagged metric. |
| tag_value | The value for that tag_key on the row. NULL alongside a NULL tag_key marks untagged usage. Count DISTINCT tag_value per tag_key downstream to detect an umbrella key that covers everything but resolves to a single cost center. |
| net_usage_quantity | SUM(usage_quantity) for the group — net DBUs/units (in usage_unit, NOT dollars) across all record_types. Multiply by a price rate downstream to dollarize. Note different usage_units are summed together here, so scope by product/SKU if you need a single unit. |
| record_count | COUNT(*) of exploded usage rows in the group — a volume/skew sanity check (how many metered slices carry this tag), not a monetary figure. |
Inventory / reference query — it returns state to read, not a pass/fail band.
| usage_date | cloud | workspace_id | billing_origin_product | tag_key | tag_value | net_usage_quantity | record_count |
|---|---|---|---|---|---|---|---|
| 2026-07-04 | AWS | 1234567890123456 | JOBS | cost_center | data-platform | 842.50 | 37 |
| 2026-07-04 | AWS | 1234567890123456 | SQL | team | analytics | 318.75 | 22 |
| 2026-07-04 | AWS | 1234567890123456 | DLT | NULL | NULL | 156.20 | 9 |
Rank tag_keys by SUM(net_usage_quantity) and count distinct tag_value per tag_key: a key that covers ~100% of DBUs but has only one distinct value is an umbrella/single-cost-center tag giving no team-level chargeback — flag it and require a team/cost-center dimension. Compute % untagged DBUs by comparing the NULL-tag_key rows against the account total from cost_totals_by_sku_day, then chase down the owners of the largest untagged slices to enforce a tagging policy.
Feeds into: chargeback/tagging (custom_tags); % untagged DBU spend; per-tag rollups / tag drift; per-WORKSPACE + per-product tag rollup; chargeback-USABLE coverage (a key with >1 distinct value, derived downstream from tag_key/tag_value)
Net DBU (and other-unit) consumption multiplied by the point-in-time list rate to produce a pre-discount list-dollar figure (net_list_cost) per usage_date x cloud x SKU x product x usage_type x unit x currency.
system.billing.usagesystem.billing.list_pricesOne row = a day + cloud + SKU + product + usage type/unit's usage, priced at list. The columns that matter are net_usage_quantity (the native-unit volume) and net_list_cost (usage_quantity x the list rate) - this is a pre-discount estimate, not what you actually pay.
RequiresSELECT on system.billing; GA
This is the query that turns raw DBU consumption into money, so it drives every headline cost chart, dollar-denominated anomaly series, and chargeback rollup an admin builds. The stakes are twofold: get the number and get the caveat right. net_list_cost is list (pre-discount) price only, DBU-only, and excludes cloud infra/egress, so it overstates what the account actually pays; worse, the list_rate path (pricing.effective_list.default cast to DOUBLE) is unverified on-workspace, so a silently-wrong cast could mis-scale every dollar figure downstream. Used carefully it prioritizes which SKUs and product lines to attack; used blindly it produces a confidently wrong bill.
SELECT u.usage_date, u.cloud, u.sku_name, u.billing_origin_product, u.usage_type, u.usage_unit,
lp.currency_code,
SUM(u.usage_quantity) AS net_usage_quantity,
SUM(u.usage_quantity * lp.list_rate) AS net_list_cost
FROM system.billing.usage u
LEFT JOIN (
SELECT sku_name, cloud, currency_code, usage_unit, price_start_time, price_end_time,
CAST(pricing.effective_list.default AS DOUBLE) AS list_rate -- <-- UNVERIFIED path
FROM system.billing.list_prices
) lp
ON u.sku_name = lp.sku_name
AND u.cloud = lp.cloud
AND u.usage_end_time >= lp.price_start_time
AND (lp.price_end_time IS NULL OR u.usage_end_time < lp.price_end_time)
WHERE u.usage_date >= dateadd(day, -:period_days, current_date())
AND u.usage_date < current_date()
GROUP BY u.usage_date, u.cloud, u.sku_name, u.billing_origin_product, u.usage_type, u.usage_unit, lp.currency_code
ORDER BY u.usage_date DESC, u.cloud, u.sku_name:period_daysdefault 30rolling window in days| Column | How to read it |
|---|---|
| usage_date | The billed usage day (DATE). One row per day per SKU/product/usage_type/unit/currency combination within the trailing window; today is excluded. |
| cloud | Cloud provider for the usage (e.g. AWS/AZURE/GCP). Also a join key to the price window, so pricing is cloud-correct. |
| sku_name | The Databricks billing SKU. The primary price-join key; each SKU carries its own list rate. |
| billing_origin_product | Product line that generated the usage (JOBS/SQL/DLT/MODEL_SERVING/DEFAULT_STORAGE/...). No closed enum; blank means unattributed, not zero. |
| usage_type | Nature of the metered consumption (COMPUTE_TIME/STORAGE_SPACE/TOKEN/GPU_TIME/...). Kept as a group dimension so unit families are not blended. |
| usage_unit | Unit of net_usage_quantity (DBU, STORAGE_SPACE bytes, hours, TOKEN, ...). Grouped so different unit families are never summed together. |
| currency_code | Currency of net_list_cost, sourced from the list_prices side of the join. NULL when no price window matched (unpriced row). |
| net_usage_quantity | SUM(usage_quantity) across all record_types for the group: net metered consumption in usage_unit (DBUs/bytes/hours/tokens). This is NOT dollars. |
| net_list_cost | SUM(usage_quantity * list_rate): net consumption valued at the point-in-time LIST rate. Dollars, but pre-discount, DBU-only, and UNVERIFIED (list_rate path unconfirmed). NULL where no price matched. |
Inventory / reference query — it returns state to read, not a pass/fail band.
| usage_date | cloud | sku_name | billing_origin_product | usage_unit | net_usage_quantity | net_list_cost |
|---|---|---|---|---|---|---|
| 2026-07-01 | AWS | ENTERPRISE_ALL_PURPOSE_COMPUTE | JOBS | DBU | 1234.5000 | 678.9750 |
| 2026-07-01 | AWS | ENTERPRISE_SQL_COMPUTE | SQL | DBU | 4200.0000 | 2940.0000 |
| 2026-07-01 | AZURE | ENTERPRISE_JOBS_SERVERLESS_COMPUTE | JOBS | DBU | 800.0000 | NULL |
Use net_list_cost as the pre-discount, list-price dollar view for headline cost and anomaly charts, but do not report it as billed spend: cross-check the list_rate against pricing_list_prices_raw (dollarize in-engine off the raw JSON) before trusting any figure, and remember it excludes cloud infra/egress and the account's negotiated discount.
Feeds into: cost totals (dollarized); dollarization (list-price × discount_factor); credit/usage anomalies (dollar series); chargeback dollar rollups
The full per-SKU price history from system.billing.list_prices — one row per price change — kept raw so downstream logic can price each usage record in its own validity window. NOTE: this environment has no account_prices table; this collects list_prices.pricing.default (the list rate), while the effective/negotiated rate lives in pricing.effective_list.default.
system.billing.list_pricesOne row = a SKU's price at a point in time. The columns that matter are pricing_default (the list rate, cast to STRING because pricing.default is a high-precision decimal) and price_end_time (NULL means this is the currently active price for that SKU/cloud/currency).
RequiresSELECT on system.billing; GA
Pricing every historical usage record correctly requires the full per-SKU rate history in force at the time each row was billed — that is what this raw dump provides, one row per price change, so the engine can pick the exact active window rather than mis-dating spend around a rate change. In this environment there is no account_prices table, so the price basis comes from system.billing.list_prices: this query collects pricing.default (the list rate), while the effective/negotiated rate lives in pricing.effective_list.default. It feeds the actual-vs-list and discount-realization findings — confirm on-workspace which of the two list_prices rates should stand in for the negotiated rate before promoting any derived saving to a headline.
SELECT price_start_time, price_end_time, account_id, sku_name, cloud, currency_code, usage_unit,
CAST(pricing.default AS STRING) AS pricing_default
FROM system.billing.list_prices
ORDER BY sku_name, cloud, currency_code, price_start_timepricing_default (list_prices.pricing.default), the list rate; the effective/negotiated rate lives in pricing.effective_list.default and is not collected here.cloud, currency_code, usage_unit) so rates are never blended across clouds or currencies.| Column | How to read it |
|---|---|
| price_start_time | When this rate became effective. Use it as the lower bound of the price window when matching a usage record to its rate. |
| price_end_time | When this rate stopped being effective. `NULL` means this is the currently-active price — you MUST treat NULL as active, never as expired or zero. |
| account_id | The Databricks account the rate belongs to. Constant for a single-account pull; confirms scope. |
| sku_name | The billing SKU the rate applies to. Join on this together with cloud + currency_code + usage_unit, never on sku_name alone. |
| cloud | The cloud provider (AWS/AZURE/GCP) this rate is for. Part of the composite price key; multi-cloud accounts have several rows per SKU. |
| currency_code | The currency the rate is denominated in. Part of the composite key; never compare or sum rates across currencies. |
| usage_unit | The unit the rate is priced per (typically DBU). Part of the composite key; ensures a DBU rate is only applied to DBU usage. |
| pricing_default | The per-unit rate itself, from list_prices.pricing.default and returned as a STRING (CAST AS STRING). This is the LIST rate — the effective/negotiated rate is pricing.effective_list.default, not collected here. On list_prices, pricing.default is decimal, so the numeric cast is safe; confirm which rate should feed the negotiated-discount finding. |
Inventory / reference query — it returns state to read, not a pass/fail band.
| price_start_time | price_end_time | account_id | sku_name | cloud | currency_code | usage_unit | pricing_default |
|---|---|---|---|---|---|---|---|
| 2025-01-01T00:00:00Z | 2025-06-30T00:00:00Z | a1b2c3d4-5e6f-7890-abcd-ef1234567890 | ENTERPRISE_ALL_PURPOSE_COMPUTE | AWS | USD | DBU | 0.44 |
| 2025-06-30T00:00:00Z | NULL | a1b2c3d4-5e6f-7890-abcd-ef1234567890 | ENTERPRISE_ALL_PURPOSE_COMPUTE | AWS | USD | DBU | 0.42 |
| 2025-03-15T00:00:00Z | NULL | a1b2c3d4-5e6f-7890-abcd-ef1234567890 | ENTERPRISE_SQL_COMPUTE | AZURE | EUR | DBU | 0.19 |
Confirm on your own workspace that pricing_default casts cleanly to a number, then join this list_prices history to system.billing.usage (on cloud + currency_code + usage_unit + sku_name, matching each usage record to its active price window) to price usage at list; decide whether pricing.default (list) or pricing.effective_list.default (effective/negotiated) should feed actual-vs-list discount-realization, since there is no separate account_prices/negotiated-rate table here.
Feeds into: actual-vs-list negotiated pricing (cost_actual_vs_list_by_sku); negotiated-discount realization %; per-SKU list/effective rate basis
Net metered consumption over the trailing window, broken out by Databricks product line, unit of measure, and cloud, with a record count per group.
system.billing.usageOne row = a product line + usage unit + cloud's total usage for the window. The columns that matter are billing_origin_product (where the DBUs/bytes/tokens went - JOBS, SQL, MODEL_SERVING, DLT, and so on) and net_usage_quantity (the summed volume in that row's native unit).
RequiresSELECT on system.billing; GA
This is the product-mix Pareto for the entire account bill: it tells an admin which product lines (JOBS, SQL, DLT, MODEL_SERVING, VECTOR_SEARCH, DEFAULT_STORAGE, ...) actually dominate consumption, so cost-optimization effort lands on the 20% of products driving 80% of spend rather than on noise. Because the net figure sums across all billing corrections, the number is trustworthy and won't double-count restatements. A blank product line surfaces unattributed consumption that would otherwise hide in the total, and keeping each unit family on its own row prevents the classic error of adding DBUs, storage bytes, and tokens into a single meaningless sum.
SELECT billing_origin_product, usage_unit, cloud,
SUM(usage_quantity) AS net_usage_quantity,
COUNT(*) AS record_count
FROM system.billing.usage
WHERE usage_date >= dateadd(day, -:period_days, current_date())
AND usage_date < current_date()
GROUP BY billing_origin_product, usage_unit, cloud
ORDER BY billing_origin_product, usage_unit, cloud:period_daysdefault 30rolling window in daysJOBS / SQL / DLT / MODEL_SERVING / ...) so you can see which products drive the bill.DBU vs storage bytes vs hours vs TOKEN) on its own row, and further splits by cloud — units are never blended.record_count shows how many usage records rolled into each line.| Column | How to read it |
|---|---|
| billing_origin_product | The Databricks product line that generated the usage (e.g. JOBS, SQL, DLT, MODEL_SERVING, DEFAULT_STORAGE). No published closed enum, so treat literals as unverified; a blank/NULL value means 'unattributed product', not zero. |
| usage_unit | The unit that net_usage_quantity is measured in (DBU, STORAGE_SPACE bytes, hours, TOKEN, ...). Rows with different units are on different scales and must never be summed together. |
| cloud | The cloud provider (AWS / AZURE / GCP) the usage was billed on; a product line can appear on more than one cloud. |
| net_usage_quantity | Total metered amount in usage_unit for this product/unit/cloud, summed across all record types so corrections already net out. This is DBUs/bytes/hours/tokens, NOT dollars. |
| record_count | Number of underlying usage records that rolled into this group; a high count with low quantity signals many small slices, useful as a sanity/coverage check. |
Inventory / reference query — it returns state to read, not a pass/fail band.
| billing_origin_product | usage_unit | cloud | net_usage_quantity | record_count |
|---|---|---|---|---|
| JOBS | DBU | AWS | 48213.5 | 12904 |
| SQL | DBU | AWS | 19677.0 | 5321 |
| DEFAULT_STORAGE | STORAGE_SPACE | AWS | 1099511627776 | 842 |
Rank the product lines by net_usage_quantity within each usage_unit to identify the 1-2 products dominating consumption, then drill into those (e.g. cost_by_job for JOBS, cost_by_serving_endpoint for MODEL_SERVING) and dollarize via the list-price join before deciding where to focus optimization.
Feeds into: cost-by-product-line (where the money goes: JOBS / SQL / DLT / MODEL_SERVING / ...) on the Pricing & Allocation tab; product-mix Pareto
A daily, per-workspace breakdown of net DBU consumption attributed to each individual cluster, SQL warehouse, and instance pool, split by product line and serverless-vs-classic.
system.billing.usageOne row = a day + workspace + compute resource's DBU cost. The columns that matter are cluster_id/warehouse_id/instance_pool_id (which resource) and net_usage_quantity (its DBU burn for that day) - a resource that stays above the WARN/CRITICAL band day after day is the one worth right-sizing or decommissioning first.
RequiresSELECT on system.billing; GA
This is the query that turns a vague "you have 149 right-sizing candidates" into "cluster X burned N DBUs a day for two weeks" — it pins DBU spend to the exact compute resource that generated it, so you can dollarize an expensive under-used cluster, spot the zero-event idle warehouses that still cost money, and track warehouse churn and instance-pool reserve. Getting the attribution right protects real money: every mis-attributed or dropped DBU is spend that lands on the wrong team's chargeback or hides waste. Because compute names do not live in billing, this rollup is the keyed foundation you resolve against config tables downstream to name-and-shame the worst offenders.
SELECT usage_date, cloud, workspace_id, billing_origin_product,
usage_metadata.cluster_id AS cluster_id,
usage_metadata.warehouse_id AS warehouse_id,
usage_metadata.instance_pool_id AS instance_pool_id,
product_features.is_serverless AS is_serverless,
SUM(usage_quantity) AS net_usage_quantity,
-- status: magnitude band on daily DBU cost per resource (field heuristic; :warn_resource_dbus_per_day / :crit_resource_dbus_per_day).
CASE
WHEN SUM(usage_quantity) IS NULL THEN 'NOT_ASSESSED'
WHEN SUM(usage_quantity) >= :crit_resource_dbus_per_day THEN 'CRITICAL'
WHEN SUM(usage_quantity) >= :warn_resource_dbus_per_day THEN 'WARN'
ELSE 'OK'
END AS status
FROM system.billing.usage
WHERE usage_date >= dateadd(day, -:period_days, current_date())
AND usage_date < current_date()
AND usage_unit = 'DBU'
AND (usage_metadata.cluster_id IS NOT NULL
OR usage_metadata.warehouse_id IS NOT NULL
OR usage_metadata.instance_pool_id IS NOT NULL)
GROUP BY usage_date, cloud, workspace_id, billing_origin_product,
usage_metadata.cluster_id, usage_metadata.warehouse_id, usage_metadata.instance_pool_id,
product_features.is_serverless
ORDER BY net_usage_quantity DESC:period_daysdefault 30rolling window in days:warn_resource_dbus_per_daydefault 50DBUs/day on a single cluster, warehouse, or instance pool that flags WARN:crit_resource_dbus_per_daydefault 200DBUs/day that flags CRITICALcluster_id, warehouse_id, or instance_pool_id.JOBS / SQL / DLT / …), and flags whether the compute was serverless or classic.| Column | How to read it |
|---|---|
| usage_date | The calendar day the consumption was metered. One row per resource per day; the window is the trailing :period_days days and excludes today. |
| cloud | The cloud provider (AWS / AZURE / GCP) the usage was billed on. |
| workspace_id | Numeric id of the workspace the resource ran in. Resolve to dev/uat/prod via cost_workspace_names. Not name-attributable here. |
| billing_origin_product | The product line that generated the usage (JOBS, SQL, DLT, MODEL_SERVING, …). No published closed enum; a blank value means unattributed, not zero. |
| cluster_id | The classic (all-purpose or jobs) cluster that spent the DBUs, or NULL if this row is a warehouse or pool. Join to classic_clusters_config_current downstream for a name. |
| warehouse_id | The SQL warehouse that spent the DBUs, or NULL otherwise. Join to sql_warehouse_config_current downstream for a name. Populated for serverless SQL warehouses too. |
| instance_pool_id | The instance pool the usage drew from, or NULL otherwise. Identifies pool reserve/idle backing cost. |
| is_serverless | Whether this resource's usage was serverless (true) or classic (false); NULL where the distinction does not apply. Read from product_features.is_serverless. |
| net_usage_quantity | The net DBUs consumed — SUM(usage_quantity) across all record_types, so corrections (RETRACTION / RESTATEMENT) already net out. This is DBUs, NOT dollars; multiply by a per-DBU rate to dollarize. |
net_usage_quantity below :warn_resource_dbus_per_day DBUs/day per resource (field heuristic - tune :warn_resource_dbus_per_day for your account).
net_usage_quantity at/above :warn_resource_dbus_per_day (WARN) or :crit_resource_dbus_per_day (CRITICAL) DBUs/day - field heuristic; a single spike day matters less than the same resource showing up repeatedly.
| usage_date | cloud | workspace_id | billing_origin_product | warehouse_id | is_serverless | net_usage_quantity |
|---|---|---|---|---|---|---|
| 2026-07-04 | AWS | 1234567890123456 | SQL | abc123warehouse01 | true | 512.7 |
| 2026-07-04 | AWS | 1234567890123456 | JOBS | NULL | false | 1843.2 |
| 2026-07-03 | AZURE | 9876543210987654 | SQL | def456warehouse02 | true | 0.0 |
Rank resources by net_usage_quantity over the window, resolve the top cluster_ids and warehouse_ids to names via the config tables, dollarize with a per-DBU rate, and target the expensive under-used clusters for right-sizing and the zero-DBU warehouses for auto-stop or deletion.
Feeds into: per-CLUSTER and per-WAREHOUSE DBU cost -> DOLLARIZES cluster right-sizing (which expensive clusters are under-used, not just "149 candidates"), idle-warehouse waste (the 84 zero-event warehouses), warehouse churn, and instance-pool reserve; per-workspace resource cost
Net DBU consumption per notebook-attached interactive/all-purpose notebook, sliced by day, cloud, workspace, product line, and serverless-vs-classic.
system.billing.usageOne row = a day + workspace + notebook's ad-hoc DBU cost. The column that matters is net_usage_quantity - ad-hoc/interactive spend is normally a small slice of total DBUs, so a notebook that clears the WARN/CRITICAL band is the runaway exception, not the norm.
RequiresSELECT on system.billing; GA
Interactive notebook work is human ad-hoc compute — usually a small slice of the bill (the workload split expects roughly 3% ad-hoc), but a single runaway notebook left attached to an oversized all-purpose cluster can quietly burn DBUs for days. This query puts a dollar-able number on that ad-hoc tier and surfaces the one or two notebooks that dominate it, per workspace. It confirms whether ad-hoc really is negligible or has crept up, and gives you the specific notebook_id to chase down.
SELECT usage_date, cloud, workspace_id, billing_origin_product,
usage_metadata.notebook_id AS notebook_id,
product_features.is_serverless AS is_serverless,
SUM(usage_quantity) AS net_usage_quantity,
-- status: magnitude band on daily DBU cost per notebook (field heuristic; :warn_notebook_dbus_per_day / :crit_notebook_dbus_per_day).
CASE
WHEN SUM(usage_quantity) IS NULL THEN 'NOT_ASSESSED'
WHEN SUM(usage_quantity) >= :crit_notebook_dbus_per_day THEN 'CRITICAL'
WHEN SUM(usage_quantity) >= :warn_notebook_dbus_per_day THEN 'WARN'
ELSE 'OK'
END AS status
FROM system.billing.usage
WHERE usage_date >= dateadd(day, -:period_days, current_date())
AND usage_date < current_date()
AND usage_unit = 'DBU'
AND usage_metadata.notebook_id IS NOT NULL
GROUP BY usage_date, cloud, workspace_id, billing_origin_product,
usage_metadata.notebook_id, product_features.is_serverless
ORDER BY net_usage_quantity DESC:period_daysdefault 30rolling window in days:warn_notebook_dbus_per_daydefault 10DBUs/day on a single notebook that flags WARN:crit_notebook_dbus_per_daydefault 50DBUs/day that flags CRITICALworkspace_id, and product line so you see where and when ad-hoc work happens.is_serverless.notebook_id) are excluded entirely, so this is the ad-hoc tier in isolation.| Column | How to read it |
|---|---|
| usage_date | The calendar day (DATE) the consumption was metered; the trailing window excludes today, and the most recent day is provisional due to billing lag. |
| cloud | The cloud provider (AWS/AZURE/GCP) the usage was billed on; part of the correct price key if you dollarize later. |
| workspace_id | The numeric workspace that ran the notebook; resolve to a dev/uat/prod name via system.access.workspaces_latest downstream. |
| billing_origin_product | The product line that generated the row (typically all-purpose/interactive compute here); blank means unattributed, not zero. |
| notebook_id | The notebook this DBU consumption is attributed to; there is no notebook NAME in billing, so this id is your only handle — resolve it outside billing. |
| is_serverless | Whether the notebook ran on serverless (true) or classic (false) compute; drives which rate applies and flags serverless premium. |
| net_usage_quantity | Net DBUs consumed (SUM of usage_quantity across all record_type corrections) for that notebook/day/slice — DBUs, NOT dollars; multiply by a per-DBU rate to get money. |
net_usage_quantity below :warn_notebook_dbus_per_day DBUs/day per notebook (field heuristic - tune :warn_notebook_dbus_per_day for your account; ad-hoc spend is expected to be a small share of the total).
net_usage_quantity at/above :warn_notebook_dbus_per_day (WARN) or :crit_notebook_dbus_per_day (CRITICAL) DBUs/day - field heuristic for a runaway ad-hoc notebook left running on an expensive all-purpose cluster.
| usage_date | cloud | workspace_id | billing_origin_product | notebook_id | is_serverless | net_usage_quantity |
|---|---|---|---|---|---|---|
| 2026-07-03 | AWS | 1234567890123456 | INTERACTIVE | a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d | false | 48.20 |
| 2026-07-03 | AWS | 1234567890123456 | INTERACTIVE | f9e8d7c6-b5a4-3210-9f8e-7d6c5b4a3210 | true | 6.35 |
| 2026-07-04 | AZURE | 9876543210987654 | INTERACTIVE | a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d | false | 51.90 |
Confirm notebook_id is actually populated, then rank notebooks by net_usage_quantity to verify ad-hoc is the expected small share; chase the top notebook_id (resolved to a name/owner outside billing) if any single notebook is disproportionately large, and check whether it should move off an oversized all-purpose cluster.
Feeds into: per-NOTEBOOK interactive/ad-hoc DBU cost -> which notebooks (human ad-hoc work) cost the most; puts a $ on the "~3% is ad-hoc" workload split; per-workspace ad-hoc cost
A daily breakdown of Model Serving and Vector Search DBU consumption per endpoint, workspace, and usage type, so you can see which AI endpoints drive the bill.
system.billing.usageOne row = a day + workspace + endpoint's serving/vector-search usage. The columns that matter are endpoint_id, usage_type (COMPUTE_TIME / GPU_TIME / TOKEN are different units), and net_usage_quantity in that unit - this is the size map behind the model-serving and vector-search share of spend, not a right-sizing verdict on its own.
RequiresSELECT on system.billing; GA
Model Serving and Vector Search together make up the large AI slice of the account bill (roughly two-thirds plus one-seventh in the reference account, ~78%), yet that spend hides behind opaque endpoint ids. This query sizes that spend endpoint-by-endpoint and day-by-day, so the biggest and fastest-growing endpoints surface for right-sizing first. It is a "where the 78% goes" map, not the fix: the actual right-sizing levers (scale-to-zero, provisioned vs used throughput) live only in the serving-endpoints API, not in any system table.
SELECT usage_date, cloud, workspace_id, billing_origin_product,
usage_metadata.endpoint_id AS endpoint_id,
CASE WHEN usage_metadata.endpoint_name IS NULL THEN usage_metadata.endpoint_name
ELSE concat(substr(usage_metadata.endpoint_name, 1, 2), '****') END AS endpoint_name,
usage_type,
SUM(usage_quantity) AS net_usage_quantity
FROM system.billing.usage
WHERE usage_date >= dateadd(day, -:period_days, current_date())
AND usage_date < current_date()
AND usage_unit = 'DBU'
AND billing_origin_product IN ('MODEL_SERVING', 'VECTOR_SEARCH')
GROUP BY usage_date, cloud, workspace_id, billing_origin_product,
usage_metadata.endpoint_id, usage_metadata.endpoint_name, usage_type
ORDER BY usage_date DESC, workspace_id, endpoint_id:period_daysdefault 30rolling window in daysMODEL_SERVING and VECTOR_SEARCH product lines, in DBUs (not dollars).COMPUTE_TIME vs GPU_TIME vs TOKEN) and keeps workspace and cloud separate.****; the raw endpoint id passes through for correlation.| Column | How to read it |
|---|---|
| usage_date | The calendar day (DATE) the consumption was metered. The window is a trailing `:period_days` days and excludes today, so the most recent day is provisional. |
| cloud | The cloud provider for the row (AWS / AZURE / GCP). Part of the grain so multi-cloud endpoints stay separated. |
| workspace_id | The workspace that generated the usage. NULL means account-level / not workspace-attributable. Resolve to dev/uat/prod names via `cost_workspace_names` downstream. |
| billing_origin_product | Which AI product line the row belongs to — `MODEL_SERVING` or `VECTOR_SEARCH` (the only two in scope). |
| endpoint_id | The stable serving/vector endpoint identifier (passed through unmasked). Use this to correlate to the serving-endpoints API. May be NULL if the metadata field was not populated on a row. |
| endpoint_name | The human endpoint name, masked to its first two characters + `****`. NULL is passed through unchanged (name unavailable), not masked. |
| usage_type | The metered dimension for the DBUs — e.g. `COMPUTE_TIME`, `GPU_TIME`, or `TOKEN` — so CPU serving, GPU serving, and token-metered usage are kept apart. Not filtered by the query; these are the values expected for serving/vector rows. |
| net_usage_quantity | Net DBUs consumed for that endpoint/day/usage_type, summed across all record types (ORIGINAL + RETRACTION + RESTATEMENT already net out). This is DBUs, NOT dollars — multiply by a per-DBU rate to dollarize. |
Inventory / reference query — it returns state to read, not a pass/fail band.
| usage_date | workspace_id | billing_origin_product | endpoint_id | endpoint_name | usage_type | net_usage_quantity |
|---|---|---|---|---|---|---|
| 2026-07-04 | 3419704829384756 | MODEL_SERVING | ep-0a1b2c3d4e5f6789 | ll**** | GPU_TIME | 842.6 |
| 2026-07-04 | 3419704829384756 | MODEL_SERVING | ep-0a1b2c3d4e5f6789 | ll**** | TOKEN | 15320.0 |
| 2026-07-03 | 8820193746501122 | VECTOR_SEARCH | ep-9f8e7d6c5b4a3210 | pr**** | COMPUTE_TIME | 57.3 |
Rank endpoints by `net_usage_quantity` (and by its day-over-day slope) to spot the biggest and fastest-growing serving/vector endpoints, then take the top offenders to the serving-endpoints API to right-size them (enable scale-to-zero, cut provisioned throughput, or retire idle endpoints).
Feeds into: per-ENDPOINT model-serving + vector-search DBU cost & daily trend -> SIZES the 64% MODEL_SERVING + 14% VECTOR_SEARCH bill (78% of spend) by endpoint, so the biggest / fastest-growing endpoints can be right-sized first; per-workspace serving cost
Net DBU consumption rolled up per identity (human user vs service principal, with masked run-as / owner / creator) sliced by day, cloud, workspace, and product line.
system.billing.usageOne row = a day + workspace + product + masked identity's DBU usage. The columns that matter are identity_type (user vs service_principal vs unknown) and identity_run_as (the masked principal) - use this to see who is spending, and how much of the spend has no attributable identity at all.
RequiresSELECT on system.billing; GA
This is the identity-level chargeback cut: it tells you which human user or service principal is actually driving DBU consumption, so spend can be attributed to a person or automated workload even when custom tags are missing. It exposes the service-principal-vs-human split (runaway automation vs interactive human cost) and surfaces untagged-but-attributable spend you can still bill back. Because identity_metadata is sparse and blanked to '__REDACTED__' in FedRamp workspaces, the query deliberately buckets unavailable identities as 'unknown' rather than inventing a principal — telling you honestly how much spend cannot yet be pinned to anyone.
SELECT usage_date, cloud, workspace_id, billing_origin_product,
CASE
WHEN identity_metadata.run_as IS NULL OR identity_metadata.run_as = '__REDACTED__' THEN 'unknown'
WHEN identity_metadata.run_as LIKE '%@%' THEN 'user'
ELSE 'service_principal'
END AS identity_type,
CASE
WHEN identity_metadata.run_as IS NULL OR identity_metadata.run_as = '__REDACTED__' THEN identity_metadata.run_as
WHEN identity_metadata.run_as LIKE '%@%' THEN concat(substr(identity_metadata.run_as, 1, 2), '****@****')
WHEN identity_metadata.run_as RLIKE '^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$' THEN identity_metadata.run_as
ELSE concat(substr(identity_metadata.run_as, 1, 2), '****')
END AS identity_run_as,
CASE
WHEN identity_metadata.owned_by IS NULL OR identity_metadata.owned_by = '__REDACTED__' THEN identity_metadata.owned_by
WHEN identity_metadata.owned_by LIKE '%@%' THEN concat(substr(identity_metadata.owned_by, 1, 2), '****@****')
WHEN identity_metadata.owned_by RLIKE '^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$' THEN identity_metadata.owned_by
ELSE concat(substr(identity_metadata.owned_by, 1, 2), '****')
END AS identity_owned_by,
CASE
WHEN identity_metadata.created_by IS NULL OR identity_metadata.created_by = '__REDACTED__' THEN identity_metadata.created_by
WHEN identity_metadata.created_by LIKE '%@%' THEN concat(substr(identity_metadata.created_by, 1, 2), '****@****')
WHEN identity_metadata.created_by RLIKE '^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$' THEN identity_metadata.created_by
ELSE concat(substr(identity_metadata.created_by, 1, 2), '****')
END AS identity_created_by,
SUM(usage_quantity) AS net_usage_quantity
FROM system.billing.usage
WHERE usage_date >= dateadd(day, -:period_days, current_date())
AND usage_date < current_date()
GROUP BY usage_date, cloud, workspace_id, billing_origin_product,
CASE
WHEN identity_metadata.run_as IS NULL OR identity_metadata.run_as = '__REDACTED__' THEN 'unknown'
WHEN identity_metadata.run_as LIKE '%@%' THEN 'user'
ELSE 'service_principal'
END,
identity_metadata.run_as, identity_metadata.owned_by, identity_metadata.created_by
ORDER BY usage_date DESC, workspace_id, identity_type:period_daysdefault 30rolling window in daysuser vs service_principal vs unknown, cleanly separating human interactive spend from automated / service-account spend.__REDACTED__ passed through.| Column | How to read it |
|---|---|
| usage_date | The calendar day (DATE) the consumption was metered. The window is a trailing :period_days days and excludes today, so the latest day is provisional. |
| cloud | The cloud provider for the usage (e.g. AWS / AZURE / GCP). Part of the chargeback grain. |
| workspace_id | Numeric workspace the usage is attributed to. NULL means an account-level SKU that is not workspace-attributable. Resolve to dev/uat/prod names downstream via cost_workspace_names. |
| billing_origin_product | Product line that generated the usage (JOBS / SQL / DLT / MODEL_SERVING / …). No published closed enum; a blank value is unattributed, not zero. |
| identity_type | Bucket for the run_as principal: 'user' when run_as is an email, 'service_principal' otherwise, and 'unknown' when run_as is NULL or '__REDACTED__' (identity unavailable, not a real principal). |
| identity_run_as | Masked principal the workload executed as — the primary chargeback key. Emails shown as first-2-chars + '****@****', non-UUID names as first-2-chars + '****'; UUIDs and '__REDACTED__'/NULL pass through unchanged. |
| identity_owned_by | Masked owner of the resource (populated for SQL-warehouse usage only; NULL/'__REDACTED__' otherwise). Same masking rules as identity_run_as. |
| identity_created_by | Masked creator of the resource, same masking rules. Sparse and often NULL. |
| net_usage_quantity | SUM(usage_quantity) for this identity/day/cloud/workspace/product, summed across ALL record_types so corrections are already netted out. NOT dollars — multiply by a price rate to dollarize. Caution: usage_unit is NOT in the grouping, so this sums quantity regardless of unit; it is predominantly DBUs but can blend DBU/bytes/hours/tokens where a product line meters more than one unit — split by usage_unit before dollarizing. |
Inventory / reference query — it returns state to read, not a pass/fail band.
| usage_date | workspace_id | billing_origin_product | identity_type | identity_run_as | net_usage_quantity |
|---|---|---|---|---|---|
| 2026-07-04 | 1234567890123456 | JOBS | service_principal | 3f8a9c21-1b2c-4d5e-8f90-a1b2c3d4e5f6 | 842.75 |
| 2026-07-04 | 1234567890123456 | SQL | user | da****@**** | 57.20 |
| 2026-07-04 | 2233445566778899 | DLT | unknown | __REDACTED__ | 410.00 |
Rank identities by net_usage_quantity to build a chargeback / SP-vs-human leaderboard: bill the top consumers back to their team, chase the service principals driving automated spend, and quantify the 'unknown' bucket as the share of usage you cannot yet attribute — then close that gap with tags or de-redaction. Scope to a single usage_unit (e.g. DBU) before dollarizing.
Feeds into: chargeback/tagging (identity-level rollup); untagged-but-attributable spend (identity present, tag absent); service-principal vs human-USER spend split; top human users ("pure users" leaderboard); per-WORKSPACE identity attribution
A daily rollup of estimated billed dollar cost by cloud and currency, derived from DBU usage × list_prices.pricing.default. NOTE: this environment exposes no separate cloud-provider infra/egress cost table (system.billing.cloud_infra_cost does not exist), so the original non-DBU infra-spend intent is not_assessed; this is the closest real, runnable substitute.
system.billing.usagesystem.billing.list_pricesOne row = a day + cloud + currency's estimated billed cost. The column that matters is net_billed_cost, an estimate = usage_quantity x list_prices.pricing.default matched to the price row that was active on that usage row - not a substitute for your cloud provider's own cost export.
RequiresSELECT on system.billing; GA
The original intent here was to surface the 10-25% of platform spend the DBU tables miss — the cloud provider's own instance-hour and network/egress bill. That data has no system table in this environment (system.billing.cloud_infra_cost does not exist), so that non-DBU spend is honestly not_assessed rather than fabricated. What this query CAN do is estimate billed dollar cost directly from metered DBUs priced at list (usage_quantity × list_prices.pricing.default), broken out by cloud and currency — a real, runnable dollar view to sit alongside the DBU rollups. Read it as a directional, list-priced estimate: it is not the negotiated invoice, and it does not include the cloud-infra spend the original query was meant to capture.
SELECT u.usage_date, u.cloud, lp.currency_code,
SUM(u.usage_quantity * lp.pricing.default) AS net_billed_cost,
COUNT(*) AS record_count
FROM system.billing.usage u
LEFT JOIN system.billing.list_prices lp
ON u.sku_name = lp.sku_name
AND u.cloud = lp.cloud
AND u.usage_unit = lp.usage_unit
AND u.usage_end_time >= lp.price_start_time
AND (lp.price_end_time IS NULL OR u.usage_end_time < lp.price_end_time)
WHERE u.usage_date >= dateadd(day, -:period_days, current_date())
AND u.usage_date < current_date()
GROUP BY u.usage_date, u.cloud, lp.currency_code
ORDER BY u.usage_date DESC, u.cloud, lp.currency_code:period_daysdefault 30rolling window in daysusage_quantity × list_prices.pricing.default, matched to each usage row's active price window — the closest runnable dollar view available in this environment.cloud and by currency_code (currency comes from list_prices; system.billing.usage has no currency column), keeping each currency on its own line rather than blending them.record_count alongside each daily total as a coverage/sanity signal for how many usage rows rolled up.:period_days window and deliberately excludes today. IMPORTANT: it does NOT measure the cloud provider's own instance/egress spend — that has no system table here and is not_assessed, never fabricated.| Column | How to read it |
|---|---|
| usage_date | The billing day the usage was metered. The window is the trailing `:period_days` days and excludes today, so the most recent day present may still be filling in. |
| cloud | The cloud provider the usage was billed on (aws/azure/gcp). |
| currency_code | The currency of the estimated cost on this row, taken from list_prices (system.billing.usage carries no currency column). Rows in different currencies are kept separate and must never be summed together. |
| net_billed_cost | The summed estimated billed cost (SUM(usage_quantity × list_prices.pricing.default)) for that day/cloud/currency, in the row's currency. A LIST-price ESTIMATE, NOT a real invoice figure and NOT the cloud provider's infra/egress spend. |
| record_count | How many underlying usage rows rolled into this row — a coverage/sanity signal, not a cost. A count that suddenly drops can indicate collection gaps. |
Inventory / reference query — it returns state to read, not a pass/fail band.
| usage_date | cloud | currency_code | net_billed_cost | record_count |
|---|---|---|---|---|
| 2026-07-04 | AWS | USD | 1284.55 | 312 |
| 2026-07-03 | AWS | USD | 1197.02 | 308 |
| 2026-07-04 | AWS | EUR | 64.10 | 11 |
Add net_billed_cost (per currency) to your other DBU-based cost views for a real, list-priced dollar picture by cloud — but do NOT present it as total platform cost: the cloud provider's own instance/egress spend has no system table here and stays not_assessed. If you need that non-DBU spend, enable a cloud-provider cost export outside Databricks; this query cannot recover it.
Feeds into: estimated billed cost by cloud, on the Pricing & Allocation tab. NOTE: Databricks does NOT expose a separate cloud-provider infra/egress cost system table in this environment (system.billing.cloud_infra_cost does not exist), so the original non-DBU infra-spend intent is not_assessed; this query reports DBU-derived billed cost from usage x list_prices as the closest real, runnable source.
Two labelled daily DBU rollups for SQL-warehouse (DBSQL) usage in one result set — one from raw billing, one from Databricks' fair-split attribution — so you can difference them to size unattributed / cross-subsidized shared-pool DBUs.
system.billing.usagesystem.billing.attributed_usageOne row = either the raw or the attributed DBSQL DBU total for a day + cloud, labeled by source_kind. Difference the two source_kind rows for the same day/cloud yourself: raw minus attributed is the DBU volume Databricks' fair-split allocation could not attribute back to a consuming entity - a large, persistent gap points at cross-subsidized shared SQL-warehouse pools.
RequiresSELECT on system.billing; GA
Shared SQL-warehouse pools quietly cross-subsidize teams: one group's queries run on a pool another cost center pays for, so the raw bill and the fair-split attribution diverge. The difference between the two rollups is the DBSQL DBU volume that raw billing shows but attribution can't tie to a consuming entity — the pool of spend you cannot fairly charge back. Sizing that gap tells you how much of your SQL-warehouse bill is currently unattributable, and whether shared pools are masking who is really driving cost.
SELECT 'raw' AS source_kind,
u.usage_date, u.cloud, u.billing_origin_product, u.usage_unit,
SUM(u.usage_quantity) AS net_usage_quantity
FROM system.billing.usage u
WHERE u.usage_date >= dateadd(day, -:period_days, current_date())
AND u.usage_date < current_date()
AND upper(u.usage_unit) = 'DBU'
AND u.billing_origin_product = 'SQL' -- DBSQL scope ONLY (attributed_usage doesn't cover jobs/DLT)
GROUP BY u.usage_date, u.cloud, u.billing_origin_product, u.usage_unit
UNION ALL
SELECT 'attributed' AS source_kind,
a.usage_date, a.cloud, a.billing_origin_product, a.usage_unit,
SUM(a.active_usage_quantity) AS net_usage_quantity
FROM system.billing.attributed_usage a
WHERE a.usage_date >= dateadd(day, -:period_days, current_date())
AND a.usage_date < current_date()
AND upper(a.usage_unit) = 'DBU'
AND a.billing_origin_product = 'SQL' -- same DBSQL scope on both sides
GROUP BY a.usage_date, a.cloud, a.billing_origin_product, a.usage_unit
ORDER BY usage_date DESC, cloud, billing_origin_product, source_kind:period_daysdefault 30rolling window in days| Column | How to read it |
|---|---|
| source_kind | Which rollup the row belongs to: 'raw' (from system.billing.usage) or 'attributed' (from system.billing.attributed_usage). Difference the two for the same usage_date/cloud to get the allocation gap; never row-join them. |
| usage_date | The calendar day of consumption (excludes today, which is still incomplete). |
| cloud | Cloud provider for the usage (e.g. AWS/AZURE/GCP). Line raw up against attributed within the same cloud when differencing. |
| billing_origin_product | Product line — always 'SQL' here, since both sides are scoped to DBSQL. Confirm 'SQL' is the literal your account uses for SQL warehouses (check cost_by_billing_origin_product). |
| usage_unit | The metering unit — always 'DBU' here (filtered). Confirms the figure is DBUs, not dollars. |
| net_usage_quantity | Net DBUs consumed for that day/cloud, summed across all record_types so RETRACTION/RESTATEMENT corrections are already netted. The 'raw' side sums system.billing.usage.usage_quantity; the 'attributed' side sums system.billing.attributed_usage.active_usage_quantity (its equivalent quantity column). Compare the 'raw' value against the 'attributed' value to size the gap. |
Inventory / reference query — it returns state to read, not a pass/fail band.
| source_kind | usage_date | cloud | billing_origin_product | usage_unit | net_usage_quantity |
|---|---|---|---|---|---|
| raw | 2026-07-04 | AWS | SQL | DBU | 1840.5 |
| attributed | 2026-07-04 | AWS | SQL | DBU | 1612.0 |
| raw | 2026-07-04 | AZURE | SQL | DBU | 730.0 |
Difference the raw and attributed net_usage_quantity for each usage_date/cloud: a persistent positive gap flags DBSQL DBUs that can't be attributed to a consumer — i.e. cross-subsidized shared SQL-warehouse pools. Track the unattributed % over time, and split or tag heavily shared warehouses so their spend becomes chargeable to the teams actually driving it.
Feeds into: attributed-vs-raw allocation gap for DBSQL (finds cross-subsidized shared SQL-warehouse pools); unattributed DBU % on the Pricing & Allocation tab
Net default-storage (DSU) usage broken out per day, cloud, SKU, storage API tier (TIER_1 vs TIER_2), and catalog.
system.billing.usageOne row = a day + cloud + SKU + storage-API-type + catalog's default-storage usage. The columns that matter are storage_api_type (TIER_1 vs TIER_2 API operations) and net_usage_quantity - this is Unity Catalog default/managed storage cost, not a customer-managed external location.
RequiresSELECT on system.billing; GA
Default (managed) storage and its per-API-operation charges are easy to overlook because they show up as bytes and API operations rather than headline compute DBUs, yet they accrue continuously across every catalog. Splitting the usage by TIER_1 vs TIER_2 API operations shows whether a workload is hammering the more expensive tier, and the per-catalog cut points at which managed catalog is driving the growth. This is the signal an admin uses to catch a runaway ingestion or listing pattern before it compounds into a material line item.
SELECT usage_date, cloud, sku_name, usage_type, usage_unit,
usage_metadata.storage_api_type AS storage_api_type,
usage_metadata.catalog_id AS catalog_id,
SUM(usage_quantity) AS net_usage_quantity
FROM system.billing.usage
WHERE usage_date >= dateadd(day, -:period_days, current_date())
AND usage_date < current_date()
AND usage_metadata.storage_api_type IS NOT NULL -- confirmed default-storage signal (safer fallback)
GROUP BY usage_date, cloud, sku_name, usage_type, usage_unit,
usage_metadata.storage_api_type, usage_metadata.catalog_id
ORDER BY usage_date DESC, cloud, sku_name:period_daysdefault 30rolling window in dayscloud, sku_name, usage_type, and usage_unit so each storage flavour (stored bytes vs API operations) stays in its own unit-correct bucket.storage_api_type, and attributes every slice to the owning catalog_id.| Column | How to read it |
|---|---|
| usage_date | The calendar day the storage usage was metered. The most recent day in the window is provisional due to billing populate lag. |
| cloud | The cloud provider for the row (AWS/AZURE/GCP). Same catalog on different clouds bills as separate rows. |
| sku_name | The billing SKU for this default-storage charge — the pricing basis; dollarize it against a price table downstream, not here. |
| usage_type | The kind of metered activity, e.g. STORAGE_SPACE (bytes at rest) or API_OPERATION (per-operation storage calls). Never blend the two. |
| usage_unit | The unit net_usage_quantity is measured in for this row (e.g. STORAGE_SPACE bytes vs API operation counts). Rows with different units are never summed together. |
| storage_api_type | The default-storage API tier — typically TIER_1 vs TIER_2 — indicating the operation class; the presence of this value is what marks the row as default storage. |
| catalog_id | UUID of the Unity Catalog whose managed storage generated the usage; use it to attribute cost to a specific catalog. |
| net_usage_quantity | Net usage in usage_unit (bytes or API-operation count — NOT dollars), summed across all record_type corrections so retractions/restatements already net out. |
Inventory / reference query — it returns state to read, not a pass/fail band.
| usage_date | cloud | sku_name | usage_type | usage_unit | storage_api_type | catalog_id | net_usage_quantity |
|---|---|---|---|---|---|---|---|
| 2026-07-04 | AWS | STANDARD_STORAGE | API_OPERATION | API_OPERATION | TIER_1 | c1a2b3c4-5d6e-7f80-9012-abcdef012345 | 184320 |
| 2026-07-04 | AWS | STANDARD_STORAGE | API_OPERATION | API_OPERATION | TIER_2 | c1a2b3c4-5d6e-7f80-9012-abcdef012345 | 5120 |
| 2026-07-04 | AWS | STANDARD_STORAGE | STORAGE_SPACE | STORAGE_SPACE | TIER_1 | d2b3c4d5-6e7f-8091-a234-bcdef0123456 | 9663676416 |
Rank catalogs by net_usage_quantity within each usage_type, watch the TIER_1 vs TIER_2 API-operation split for a spike, and dollarize the top catalogs/SKUs against the list-price table to decide whether a catalog's ingestion or access pattern needs tuning.
Feeds into: DEFAULT_STORAGE/DSU storage cost; Default-storage TIER_1 vs TIER_2 API operations (storage_api_type)
Net TOKEN / GPU_TIME / ANSWER consumption per day, broken out by SKU, product line, usage type, serving type, and serving endpoint.
system.billing.usageOne row = a day + cloud + SKU + usage type's GenAI usage. The columns that matter are usage_type (TOKEN vs GPU_TIME vs ANSWER are different units) and net_usage_quantity in that unit - price each usage_type against its own list_prices SKU row, never the DBU rate.
RequiresSELECT on system.billing; GA
GenAI and model-serving usage is billed in tokens and GPU-time on their own SKUs, not in DBUs, so it is invisible to any dollarization that assumes a per-DBU rate — this query is how an admin sees that spend at all. It isolates which serving endpoints and SKUs are burning tokens or GPU-hours, so a runaway pay-per-token endpoint or an always-on provisioned-throughput deployment shows up as a growing line before it lands as a bill shock. Because it is sliced by day, it doubles as the input to AI-cost anomaly detection. Each row must be priced against its own SKU's list-price row; multiplying these quantities by a DBU rate produces a meaningless number.
SELECT usage_date, cloud, sku_name, billing_origin_product, usage_type, usage_unit,
product_features.serving_type AS serving_type,
CASE WHEN usage_metadata.endpoint_name IS NULL THEN usage_metadata.endpoint_name ELSE concat(substr(usage_metadata.endpoint_name, 1, 2), '****') END AS endpoint_name,
usage_metadata.endpoint_id AS endpoint_id,
SUM(usage_quantity) AS net_usage_quantity
FROM system.billing.usage
WHERE usage_date >= dateadd(day, -:period_days, current_date())
AND usage_date < current_date()
AND usage_type IN ('TOKEN', 'GPU_TIME', 'ANSWER')
GROUP BY usage_date, cloud, sku_name, billing_origin_product, usage_type, usage_unit,
product_features.serving_type, usage_metadata.endpoint_name, usage_metadata.endpoint_id
ORDER BY usage_date DESC, cloud, usage_type:period_daysdefault 30rolling window in daysTOKEN, GPU_TIME, and ANSWER usage types — and hides everything DBU-denominated.net_usage_quantity) per day for each combination of SKU, product line, usage type, serving type, and serving endpoint, already net of billing corrections.endpoint_name masked, endpoint_id intact), which populates only for model-serving and vector-search rows.usage_unit on every row so tokens, GPU-time, and answer counts are never accidentally added together — they are different units on different SKUs.| Column | How to read it |
|---|---|
| usage_date | The metered day (DATE). The window is the trailing :period_days days and excludes today; treat the most recent day as provisional due to billing populate lag. |
| cloud | The cloud provider for this usage slice (AWS / AZURE / GCP). Part of the key you would price on. |
| sku_name | The specific billing SKU that generated the usage — this is the SKU you must look up in list_prices/account_prices to price the row, never a DBU rate. |
| billing_origin_product | The product line that emitted the usage (e.g. MODEL_SERVING, VECTOR_SEARCH). No published closed enum; a blank is 'unattributed', not zero. |
| usage_type | Which GenAI meter this is: TOKEN, GPU_TIME, or ANSWER. Determines what usage_unit and net_usage_quantity mean. |
| usage_unit | The unit net_usage_quantity is counted in (tokens, GPU-time hours, answers, etc.). Varies by usage_type — do not sum across different units. |
| serving_type | The product_features.serving_type sub-classification of the serving workload; NULL where the choice doesn't apply. |
| endpoint_name | The serving/vector-search endpoint name, masked to its first two characters plus '****'. NULL when the row is not endpoint-attributable (populates only for model-serving / vector-search). |
| endpoint_id | The endpoint's stable id (passed through unmasked) — the reliable join/grouping key when the masked name collides or is NULL. |
| net_usage_quantity | Summed usage_quantity in usage_unit for the group — tokens / GPU-time / answers, NOT dollars and NOT DBUs. Already net across all record_type corrections. |
Inventory / reference query — it returns state to read, not a pass/fail band.
| usage_date | sku_name | billing_origin_product | usage_type | usage_unit | endpoint_name | net_usage_quantity |
|---|---|---|---|---|---|---|
| 2026-07-04 | MODEL_SERVING_FOUNDATION_MODEL_TOKENS | MODEL_SERVING | TOKEN | TOKEN | ll**** | 4820100 |
| 2026-07-04 | MODEL_SERVING_GPU_INFERENCE | MODEL_SERVING | GPU_TIME | GPU_HOUR | cu**** | 36.5 |
| 2026-07-03 | VECTOR_SEARCH_SERVING | VECTOR_SEARCH | ANSWER | ANSWER | pr**** | 1240 |
Rank endpoints and SKUs by net_usage_quantity within each usage_unit, price each against its own SKU's list-price row (not the DBU rate), and chase the largest or fastest-growing token/GPU consumers — right-size or throttle a runaway pay-per-token or provisioned endpoint before it becomes a bill shock.
Feeds into: GenAI/token spend (usage_type TOKEN/GPU_TIME); model-serving cost attribution; AI-cost anomaly detection
One row per usage-date, cloud, networking SKU, region pair, client, and Delta Sharing recipient, giving the net billed networking volume (bytes or hours) over the trailing window.
system.billing.usageOne row = a day + cloud + SKU + usage type's billed networking usage. The columns that matter are usage_type (NETWORK_BYTE vs NETWORK_HOUR are different units) and net_usage_quantity - this is the closest billed-egress signal available, not a full network cost reconciliation.
RequiresSELECT on system.billing; GA
Cross-region and cross-cloud data egress is a real, recurring line on the bill that DBU-based cost views miss entirely, and it is the closest in-account signal for what Delta Sharing to external recipients is actually moving. Breaking the networking volume out by region pair, client, and recipient shows an admin which flows and which sharing partners drive egress, so a chatty pipeline or an over-broad share can be caught before it compounds. Because true egress is billed largely on the cloud side, this is a directional signal to reconcile against the cloud cost export, not the final dollar figure.
SELECT usage_date, cloud, sku_name, usage_type, usage_unit,
usage_metadata.source_region AS source_region,
usage_metadata.destination_region AS destination_region,
usage_metadata.networking_client AS networking_client,
usage_metadata.recipient_id AS recipient_id,
SUM(usage_quantity) AS net_usage_quantity
FROM system.billing.usage
WHERE usage_date >= dateadd(day, -:period_days, current_date())
AND usage_date < current_date()
AND usage_type IN ('NETWORK_BYTE', 'NETWORK_HOUR')
GROUP BY usage_date, cloud, sku_name, usage_type, usage_unit,
usage_metadata.source_region, usage_metadata.destination_region,
usage_metadata.networking_client, usage_metadata.recipient_id
ORDER BY usage_date DESC, cloud, usage_type:period_daysdefault 30rolling window in daysNETWORK_BYTE and NETWORK_HOUR) and reports the net volume with restatements already accounted for, so no manual correction handling is needed.sku_name, and further by source/destination region pair and networking client to show where traffic flows.recipient_id, so volume attributable to a specific external sharing partner stands on its own row.usage_unit) — never DBUs or dollars.| Column | How to read it |
|---|---|
| usage_date | The calendar day the networking consumption was metered. The window excludes today, so treat the most recent day as provisional due to billing populate lag. |
| cloud | The cloud provider (AWS / AZURE / GCP) the charge was billed on. |
| sku_name | The specific networking SKU that generated the row; identifies the kind of egress/networking charge. |
| usage_type | Either NETWORK_BYTE (volume-based egress) or NETWORK_HOUR (time-based networking), the only two types this query keeps. |
| usage_unit | The unit net_usage_quantity is expressed in — bytes for NETWORK_BYTE, hours for NETWORK_HOUR. Never DBUs; do not price at a DBU rate. |
| source_region | Origin region of the traffic. ALWAYS NULL on GCP — read a GCP null as 'not reported by the cloud', not as 'no egress'. |
| destination_region | Destination region of the traffic; the pair with source_region reveals cross-region flows. Also ALWAYS NULL on GCP. |
| networking_client | The client/component that generated the networking usage; NULL when not attributable to a specific client. |
| recipient_id | The Delta Sharing recipient the egress is attributable to; populated only for share-driven egress, otherwise NULL. |
| net_usage_quantity | Net metered networking volume for the row (SUM of usage_quantity across all record types), in the units given by usage_unit — bytes or hours, not dollars. |
Inventory / reference query — it returns state to read, not a pass/fail band.
| usage_date | cloud | usage_type | usage_unit | destination_region | recipient_id | net_usage_quantity |
|---|---|---|---|---|---|---|
| 2026-07-04 | AWS | NETWORK_BYTE | bytes | us-west-2 | 3f9a2c14-8b6e-4d21-9c07-1a2b3c4d5e6f | 48213004112 |
| 2026-07-04 | AWS | NETWORK_BYTE | bytes | eu-central-1 | (null) | 9120334455 |
| 2026-07-04 | GCP | NETWORK_HOUR | hours | (null) | (null) | 168 |
Rank the region pairs, clients, and Delta Sharing recipients by net_usage_quantity to find the top egress drivers, then convert those bytes to dollars by reconciling against the cloud provider's cost export (regions unavailable on GCP) and tighten the chattiest cross-region flow or over-broad share.
Feeds into: data egress (NETWORK lines); credit/usage anomalies (networking slice); Delta Sharing egress (recipient_id)
Per cloud, the net billed usage alongside its original, retracted, and restated components plus the latest ingestion date, quantifying how much consumption was later corrected and proving the net figure never double-counts those corrections.
system.billing.usageOne row = a cloud's usage totals for the window, split by record_type. The columns that matter are net_usage_quantity (the true net, corrections already applied) versus original_usage_quantity/retracted_abs_quantity/restatement_usage_quantity (how much of that net was corrected after the fact) - this is a trust/QA check on the billing data itself, not a cost or waste signal.
RequiresSELECT on system.billing; GA
Databricks silently corrects prior billing by appending RETRACTION and RESTATEMENT rows rather than editing history, so any rollup that filters to `ORIGINAL` overstates spend while a naive re-net downstream can understate or double-count it. This query gives an admin a hard, per-cloud trust number: how many DBUs of a period's usage were later restated, and confirmation that summing across all record types nets corrections out exactly once. It also surfaces the most recent `ingestion_date` so the admin knows how fresh the billing data actually is before quoting a cost figure to finance.
SELECT cloud,
SUM(usage_quantity) AS net_usage_quantity,
SUM(CASE WHEN record_type = 'ORIGINAL' THEN usage_quantity ELSE 0 END) AS original_usage_quantity,
SUM(CASE WHEN record_type = 'RETRACTION' THEN ABS(usage_quantity) ELSE 0 END) AS retracted_abs_quantity,
SUM(CASE WHEN record_type = 'RESTATEMENT' THEN usage_quantity ELSE 0 END) AS restatement_usage_quantity,
MAX(ingestion_date) AS max_ingestion_date
FROM system.billing.usage
WHERE usage_date >= dateadd(day, -:period_days, current_date())
AND usage_date < current_date()
GROUP BY cloud
ORDER BY cloud:period_daysdefault 30rolling window in daysnet equals original minus retracted_abs plus restatement on every row.| Column | How to read it |
|---|---|
| cloud | The cloud provider (e.g. `AWS`, `AZURE`, `GCP`) the usage was billed on; one row per cloud present in the window. |
| net_usage_quantity | The trustworthy net metered amount (DBUs/bytes/hours/tokens, NOT dollars) summed across ALL record types — corrections already netted out. This is the figure to quote. |
| original_usage_quantity | The metered amount from ORIGINAL rows only — the pre-correction gross. Do not use this as a net total. |
| retracted_abs_quantity | The absolute magnitude of usage pulled back by RETRACTION rows (sign-flipped to positive so it reads as 'how much was clawed back'). |
| restatement_usage_quantity | The usage added back by RESTATEMENT rows — the corrected re-charge that replaces a retraction. Restated % of net = restatement / net. |
| max_ingestion_date | The most recent load date for this cloud's billing rows — the freshness signal; a stale value here means the period's numbers are still settling. |
Inventory / reference query — it returns state to read, not a pass/fail band.
| cloud | net_usage_quantity | original_usage_quantity | retracted_abs_quantity | restatement_usage_quantity | max_ingestion_date |
|---|---|---|---|---|---|
| AWS | 999500.00 | 1000000.00 | 12000.00 | 11500.00 | 2026-07-05 |
| AZURE | 500000.00 | 500000.00 | 0.00 | 0.00 | 2026-07-05 |
| GCP | 199800.00 | 200000.00 | 5000.00 | 4800.00 | 2026-07-04 |
Compute restated % as `restatement_usage_quantity / net_usage_quantity` per cloud: if it is small and `max_ingestion_date` is current, quote `net_usage_quantity` (dollarized) to finance with confidence; if it is large or ingestion is stale, hold the number as provisional and re-run once the feed catches up.
Feeds into: % restated (record_type); no-double-counting trust guarantee; data freshness/lag note
Per-endpoint model-serving consumption over the trailing window, broken out by billed signal (serving type, usage type, and scale-from-zero LAUNCH flag) so each endpoint's cost mode can be inferred, with a bounded, unverified list-dollar figure.
system.billing.usagesystem.billing.list_pricesOne row = an endpoint + day + usage_type's model-serving usage with an inferred cost mode. The columns that matter are is_launch_sku (a TRUE-heavy endpoint is repeatedly cold-starting from scale-to-zero, which is itself a cost signal) and net_list_cost (est_usd_list, the estimated dollar exposure that drives the band below).
RequiresSELECT on system.billing; GA
Model serving is one of the fastest-growing and most opaque lines on a Databricks bill, and the single biggest lever - how an endpoint is configured (pay-per-token, provisioned throughput, or scale-from-zero) - is NOT recorded in any system table, only in the serving API. This query recovers that cost mode from the billed signals themselves, so an admin can spot a provisioned GPU endpoint that should be pay-per-token, or an endpoint racking up scale-from-zero cold-start LAUNCH charges. Because the LAUNCH SKU is billed separately, it makes cold-start waste visible per endpoint. The attached dollars are list and unverified, so they size the opportunity but must not be quoted as the actual invoice.
SELECT
u.usage_metadata.endpoint_id AS endpoint_id,
CASE WHEN u.usage_metadata.endpoint_name IS NULL THEN u.usage_metadata.endpoint_name ELSE concat(substr(u.usage_metadata.endpoint_name, 1, 2), '****') END AS endpoint_name,
u.cloud AS cloud,
u.sku_name AS sku_name,
u.usage_type AS usage_type,
u.usage_unit AS usage_unit,
u.product_features.serving_type AS serving_type,
CASE WHEN upper(u.sku_name) LIKE '%SERVERLESS_REAL_TIME_INFERENCE_LAUNCH%'
THEN TRUE ELSE FALSE END AS is_launch_sku,
SUM(u.usage_quantity) AS net_usage_quantity,
SUM(u.usage_quantity * lp.list_rate) AS net_list_cost,
-- status: est_usd_list/day band per endpoint + usage_type (field heuristic; :warn_endpoint_usd_per_day / :crit_endpoint_usd_per_day).
CASE
WHEN SUM(u.usage_quantity * lp.list_rate) IS NULL THEN 'NOT_ASSESSED'
WHEN SUM(u.usage_quantity * lp.list_rate) >= :crit_endpoint_usd_per_day THEN 'CRITICAL'
WHEN SUM(u.usage_quantity * lp.list_rate) >= :warn_endpoint_usd_per_day THEN 'WARN'
ELSE 'OK'
END AS status
FROM system.billing.usage u
LEFT JOIN (
SELECT sku_name, cloud, usage_unit, price_start_time, price_end_time,
CAST(pricing.effective_list.default AS DOUBLE) AS list_rate -- UNVERIFIED path; see caveats
FROM system.billing.list_prices
) lp
ON u.sku_name = lp.sku_name
AND u.cloud = lp.cloud
AND u.usage_end_time >= lp.price_start_time
AND (lp.price_end_time IS NULL OR u.usage_end_time < lp.price_end_time)
WHERE u.usage_date >= dateadd(day, -:period_days, current_date())
AND u.usage_date < current_date()
AND u.billing_origin_product = 'MODEL_SERVING'
GROUP BY
u.usage_metadata.endpoint_id,
u.usage_metadata.endpoint_name,
u.cloud,
u.sku_name,
u.usage_type,
u.usage_unit,
u.product_features.serving_type,
CASE WHEN upper(u.sku_name) LIKE '%SERVERLESS_REAL_TIME_INFERENCE_LAUNCH%' THEN TRUE ELSE FALSE END
ORDER BY net_list_cost DESC NULLS LAST:period_daysdefault 30rolling window in days:warn_endpoint_usd_per_daydefault 50estimated list-price $/day on a single endpoint + usage_type that flags WARN:crit_endpoint_usd_per_daydefault 250$/day that flags CRITICALnet_usage_quantity) per serving endpoint over the trailing :period_days window, netting out billing corrections.serving_type (foundation/GPU/model/feature), usage_type (token vs GPU-time vs compute-time), and whether the spend is a scale-from-zero cold-start (is_launch_sku).net_list_cost) by pricing each usage row at its point-in-time list rate - shown as list/unverified, and left blank where the price path is unavailable rather than guessed.cloud and sku_name alongside so multi-cloud endpoints and the exact billed SKU stay distinguishable.| Column | How to read it |
|---|---|
| endpoint_id | The serving endpoint's UUID, passed through unchanged - the stable key to correlate with the serving-endpoints API for the true workload config. |
| endpoint_name | The endpoint name masked to its first two characters plus '****' (a NULL name stays NULL); a readability hint, not a reliable identifier - use endpoint_id to join. |
| cloud | The cloud provider (AWS/AZURE/GCP) the usage was billed on; part of the price-join key, so the same endpoint on two clouds appears as separate rows. |
| sku_name | The exact billed SKU string; the '%SERVERLESS_REAL_TIME_INFERENCE_LAUNCH%' pattern here is what drives is_launch_sku. |
| usage_type | The metered activity - TOKEN (pay-per-token inference), GPU_TIME (GPU throughput), COMPUTE_TIME (CPU serving), ANSWER, etc. - a primary tell of the cost mode. |
| usage_unit | The unit net_usage_quantity is counted in (DBU, TOKEN, GPU-seconds, ...); rows in different units are NOT comparable or summable. |
| serving_type | The serving product feature - FOUNDATION_MODEL, GPU_MODEL, MODEL, FEATURE, or null - distinguishing foundation-model APIs from custom/GPU-provisioned endpoints. |
| is_launch_sku | TRUE when the row is a scale-from-zero cold-start LAUNCH charge; concentrated TRUE spend on an endpoint flags cold-start churn that a warm minimum replica would remove. |
| net_usage_quantity | Net metered consumption (SUM of usage_quantity across all record_types) in usage_unit - DBUs / tokens / GPU-seconds, NOT dollars. |
| net_list_cost | net_usage_quantity priced at the point-in-time LIST rate - a pre-discount, UNVERIFIED dollar estimate; NULL means the price path/join was unavailable (list cost unavailable), never $0. |
net_list_cost below :warn_endpoint_usd_per_day est_usd_list/day per endpoint + usage_type (field heuristic - tune for your account).
net_list_cost at/above :warn_endpoint_usd_per_day (WARN) or :crit_endpoint_usd_per_day (CRITICAL) est_usd_list/day (field heuristic); or net_list_cost is NULL (NOT_ASSESSED - the list-price join found no matching price row, not $0). A high is_launch_sku share alongside a high band is the strongest signal of scale-to-zero churn.
| endpoint_id | endpoint_name | cloud | sku_name | usage_type | usage_unit | serving_type | is_launch_sku | net_usage_quantity | net_list_cost |
|---|---|---|---|---|---|---|---|---|---|
| 4a1f9c22-0e7d-4b3a-9c11-2f8e6d0a1b34 | ll**** | AWS | STANDARD_FOUNDATION_MODEL_TOKEN | TOKEN | TOKEN | FOUNDATION_MODEL | false | 4520000 | 316.40 |
| 7e3b8d10-5a92-41c6-bf4e-9d0c2a7f1e88 | gp**** | AZURE | PREMIUM_GPU_MODEL_SERVING | GPU_TIME | DBU | GPU_MODEL | false | 1280.5 | 89.64 |
| c9d4e2a1-8b30-4f77-a6e2-1c5b9f0d3e21 | re**** | AWS | PREMIUM_SERVERLESS_REAL_TIME_INFERENCE_LAUNCH | COMPUTE_TIME | DBU | MODEL | true | 42.0 | NULL |
Rank endpoints by `net_usage_quantity` within each `serving_type`/`usage_type` family, then act on the inferred cost mode: for `is_launch_sku = TRUE` rows with heavy launch DBUs, set a minimum provisioned replica (scale-from-zero cold-starts are burning spend); for `FOUNDATION_MODEL` + `TOKEN` rows, cap or route high-token endpoints; for `GPU_MODEL` provisioned rows, confirm the endpoint is actually driving throughput before renewing the GPU reservation. Because scale-to-zero/workload-size config is NOT in system tables, cross-check the shortlist against the serving-endpoints API before changing anything.
Feeds into: cost_serving_cost_mode_efficiency (gov-7) — per-endpoint model-serving spend with inferred cost mode (pay-per-token vs provisioned vs scale-from-zero LAUNCH) + bounded list cost for dollarization
Net metered consumption (DBUs/bytes/tokens/hours) per day, cloud, workspace, SKU, product line, usage type and serverless flag, with the correction-record breakdown that proves the net figure is trustworthy.
system.billing.usageOne row = a day + cloud + workspace + SKU + product + usage type's net usage. The columns that matter are net_usage_quantity (the corrected net) and workspace_id (NULL means an account-level SKU, not a missing value) - this is the finest-grain total this repo collects, and most other cost cuts are a slice of it.
RequiresSELECT on system.billing; GA
This is the foundational rollup every other cost view is built on: it is where an admin sees how much metered consumption the account actually incurred and can trust that billing corrections are not double-counted. Getting the net wrong here (for example by filtering to ORIGINAL records and missing later retractions/restatements) silently inflates every downstream dollar figure. The per-workspace and serverless-vs-classic cuts let FinOps allocate spend to dev/uat/prod and spot the serverless mix, while the restatement split surfaces how much of the bill was later revised. Note the amounts are DBUs/units, not dollars — dollarizing happens in a separate priced query.
SELECT usage_date, cloud, workspace_id, sku_name, billing_origin_product, usage_type, usage_unit,
product_features.is_serverless AS is_serverless,
SUM(usage_quantity) AS net_usage_quantity,
SUM(CASE WHEN record_type = 'ORIGINAL' THEN usage_quantity ELSE 0 END) AS original_usage_quantity,
SUM(CASE WHEN record_type = 'RETRACTION' THEN usage_quantity ELSE 0 END) AS retraction_usage_quantity,
SUM(CASE WHEN record_type = 'RESTATEMENT' THEN usage_quantity ELSE 0 END) AS restatement_usage_quantity,
COUNT(*) AS record_count
FROM system.billing.usage
WHERE usage_date >= dateadd(day, -:period_days, current_date())
AND usage_date < current_date()
GROUP BY usage_date, cloud, workspace_id, sku_name, billing_origin_product, usage_type, usage_unit,
product_features.is_serverless
ORDER BY usage_date DESC, workspace_id, sku_name:period_daysdefault 30rolling window in daysbilling_origin_product), usage type and unit, and whether the compute was serverless.net_usage_quantity) alongside the original, retracted, and restated pieces, so you can see how much of a line was later corrected.usage_unit — DBUs, storage bytes, tokens, hours), never dollars, and never blends different unit families together.workspace_id is empty) as consumption that is not attributable to a single workspace.| Column | How to read it |
|---|---|
| usage_date | The calendar day the consumption was metered (the recommended date-partition column). The window is a trailing :period_days days and excludes today, whose billing is still incomplete. |
| cloud | The cloud provider for the usage (e.g. AWS, AZURE, GCP). Part of the grain because prices and SKUs differ by cloud. |
| workspace_id | The workspace that generated the usage; empty/NULL for account-level SKUs (some MODEL_SERVING/account services) — keep those rows as 'not workspace-attributable'. Names are not here; resolve id to dev/uat/prod separately. |
| sku_name | The billed SKU (the priced product unit). The finest product identifier and the key you would later join to a price table on cloud + currency + unit + sku_name. |
| billing_origin_product | The product line that originated the charge (JOBS/SQL/DLT/MODEL_SERVING/DEFAULT_STORAGE/…). No published closed enum, so specific literals are unverified; a blank value means 'unattributed', not zero. |
| usage_type | What kind of metering this is (COMPUTE_TIME, STORAGE_SPACE, NETWORK_BYTE, TOKEN, GPU_TIME, …). Determines which unit family the amount belongs to. |
| usage_unit | The unit of the amounts on this row — DBU, STORAGE_SPACE (bytes), TOKEN, hours, etc. Never sum amounts across different units. |
| is_serverless | Whether the compute behind the row was serverless (true) or classic (false); NULL where the distinction does not apply. Drives the serverless-vs-classic mix. Sourced from product_features.is_serverless. |
| net_usage_quantity | The trustworthy figure: total usage_quantity summed across ALL record types, so retractions and restatements already net out originals. This is DBUs/units, not dollars. |
| original_usage_quantity | The portion from ORIGINAL records only — the first-reported amount before any correction. Do not use this alone as the net. |
| retraction_usage_quantity | The portion from RETRACTION records (negative corrections that reverse a prior charge). Already included in net_usage_quantity. |
| restatement_usage_quantity | The portion from RESTATEMENT records (revised re-postings of a charge). Already included in net_usage_quantity; a large share signals heavy billing restatement. |
| record_count | How many raw usage rows collapsed into this group — a density/volume signal, not a cost. |
Inventory / reference query — it returns state to read, not a pass/fail band.
| usage_date | workspace_id | sku_name | usage_unit | is_serverless | net_usage_quantity | restatement_usage_quantity | record_count |
|---|---|---|---|---|---|---|---|
| 2026-07-03 | 1234567890123456 | ENTERPRISE_SQL_COMPUTE | DBU | true | 412.50 | 0.00 | 96 |
| 2026-07-03 | 9876543210987654 | ENTERPRISE_JOBS_COMPUTE | DBU | false | 128.75 | 12.25 | 144 |
| 2026-07-02 | NULL | PREMIUM_MODEL_SERVING | DBU | true | 57.00 | 0.00 | 24 |
Use this as your base consumption ledger: pivot net_usage_quantity by workspace_id and is_serverless to see the dev/uat/prod and serverless-vs-classic mix, watch restatement_usage_quantity for days with heavy corrections, then feed the same SKU/day grain into cost_dollarized_by_sku_day to turn units into list dollars.
Feeds into: cost totals; per-WORKSPACE cost split (dev/uat/prod); per-workspace product & serverless mix; credit/usage anomalies (time series); % restated (record_type); GenAI/token spend (usage_type slices); DEFAULT_STORAGE/DSU storage cost (billing_origin_product slice)
Net DBU consumption bucketed by whether a usage policy is attached (usage_policy / legacy budget_policy / none) and whether custom tags are present, with is_serverless exposed as a dimension (not a filter) so coverage % can be computed over serverless spend, sliced per day, cloud, workspace, and product line.
system.billing.usageOne row = a day + workspace + product's serverless usage cut by policy and tag coverage. The columns that matter are policy_coverage ('none' on a serverless row is the uncovered gap) and is_serverless (coverage is only meaningful for serverless spend) - tag_coverage is tracked separately, so a warehouse can be tagged yet still show 'none' on policy.
RequiresSELECT on system.billing; GA
Serverless usage-policy and budget-policy IDs are what tie serverless spend to a cost-control policy and a chargeback owner; any serverless DBUs landing in the `none` bucket are spend nobody has budgeted or attributed. Measured against serverless spend only, this is the account's usage-policy coverage gap — the slice of serverless billing that can run uncapped and unallocated. The workspace and product breakdown turns that gap into a punch list: uncovered interactive/notebook usage needs a usage policy attached, while uncovered SQL warehouses need to be tagged instead, so the same fix is not misapplied. It also flags reliance on the deprecated `budget_policy_legacy` path, which should be migrated to `usage_policy_id`.
SELECT usage_date, cloud, workspace_id, billing_origin_product,
product_features.is_serverless AS is_serverless,
CASE WHEN usage_metadata.usage_policy_id IS NOT NULL THEN 'usage_policy'
WHEN usage_metadata.budget_policy_id IS NOT NULL THEN 'budget_policy_legacy'
ELSE 'none' END AS policy_coverage,
CASE WHEN cardinality(map_keys(custom_tags)) > 0 THEN 'tagged' ELSE 'untagged' END AS tag_coverage,
SUM(usage_quantity) AS net_usage_quantity,
-- status: yes/no coverage-gap flag on serverless spend (field heuristic).
CASE
WHEN product_features.is_serverless IS NULL THEN 'NOT_ASSESSED'
WHEN product_features.is_serverless = true
AND (CASE WHEN usage_metadata.usage_policy_id IS NOT NULL THEN 'usage_policy'
WHEN usage_metadata.budget_policy_id IS NOT NULL THEN 'budget_policy_legacy'
ELSE 'none' END) = 'none'
THEN 'WARN'
ELSE 'OK'
END AS status
FROM system.billing.usage
WHERE usage_date >= dateadd(day, -:period_days, current_date())
AND usage_date < current_date()
GROUP BY usage_date, cloud, workspace_id, billing_origin_product, product_features.is_serverless,
CASE WHEN usage_metadata.usage_policy_id IS NOT NULL THEN 'usage_policy'
WHEN usage_metadata.budget_policy_id IS NOT NULL THEN 'budget_policy_legacy'
ELSE 'none' END,
CASE WHEN cardinality(map_keys(custom_tags)) > 0 THEN 'tagged' ELSE 'untagged' END
ORDER BY status DESC, net_usage_quantity DESC:period_daysdefault 30rolling window in daysusage_policy (current), budget_policy_legacy (deprecated fallback), or none, with is_serverless carried as a dimension — so you can compute the % of serverless spend with no usage policy.tagged vs untagged) as a separate axis, so a warehouse that is tagged but has no policy is not falsely counted as fully covered.workspace_id and billing_origin_product, letting you close the gap workspace by workspace and route each fix by product (notebook/interactive → attach a policy, SQL warehouse → tag it).net_usage_quantity) per bucket per day, netting billing corrections so the coverage figure is not inflated by restatements.| Column | How to read it |
|---|---|
| usage_date | The consumption day (DATE). The window is a trailing :period_days days and excludes today, so no partial current day is included; the latest included day can still be revised due to billing lag. |
| cloud | Cloud provider for the usage (e.g. AWS/AZURE/GCP). |
| workspace_id | Numeric workspace the usage ran in; the axis you close the coverage gap along. NULL for account-level SKUs (not workspace-attributable). Resolve to dev/uat/prod names via cost_workspace_names downstream. |
| billing_origin_product | Product line that generated the usage (e.g. SQL, JOBS, MODEL_SERVING). Drives the split of the fix — interactive/notebook → policy, warehouse → tag. No published closed enum; a blank value is unattributed, not zero. |
| is_serverless | Whether the row is serverless usage (a GROUP BY dimension, NOT a filter — classic rows are present too). Policy IDs populate only for serverless, so compute coverage % over is_serverless = true rows only; classic (false) rows will always show policy_coverage = 'none'. |
| policy_coverage | Policy attachment bucket: 'usage_policy' (current usage_policy_id present), 'budget_policy_legacy' (usage_policy_id absent but the deprecated budget_policy_id present — migrate these), or 'none' (neither — the coverage gap). |
| tag_coverage | 'tagged' if the row carries any custom_tags key (cardinality(map_keys) > 0), else 'untagged'. Tracked independently of policy_coverage on purpose — a row can be tagged yet still 'none' on policy. |
| net_usage_quantity | Summed usage_quantity for the bucket, in DBUs (not dollars), net of RETRACTION/RESTATEMENT corrections. Multiply by a serverless SKU rate to dollarize. |
is_serverless = true rows show policy_coverage in ('usage_policy', 'budget_policy_legacy') - field heuristic.
is_serverless = true AND policy_coverage = 'none' (WARN) - field heuristic; the fix differs by product, an uncovered notebook/job needs a usage policy attached, an uncovered SQL warehouse needs a tag.
| usage_date | cloud | workspace_id | billing_origin_product | is_serverless | policy_coverage | tag_coverage | net_usage_quantity |
|---|---|---|---|---|---|---|---|
| 2026-07-04 | AWS | 1234567890123456 | SQL | true | none | tagged | 842.5 |
| 2026-07-04 | AWS | 1234567890123456 | JOBS | true | usage_policy | tagged | 1310.0 |
| 2026-07-04 | AZURE | 9876543210987654 | SQL | true | budget_policy_legacy | untagged | 57.25 |
Sum net_usage_quantity where policy_coverage = 'none' and is_serverless = true, divide by total serverless DBUs to get your uncovered-serverless %, then work the per-workspace/per-product rows: attach a usage policy to uncovered interactive/notebook (JOBS/notebook) usage and tag uncovered SQL warehouses, and migrate any 'budget_policy_legacy' rows to usage_policy_id.
Feeds into: usage-policy coverage (% serverless spend with no usage_policy_id); chargeback hygiene for serverless; per-WORKSPACE + per-product triage of uncovered serverless (INTERACTIVE = attach a usage POLICY; SQL = TAG the warehouse); policy-uncovered vs tag-uncovered reconciliation
Daily Vector Search consumption per endpoint, split into serving/ingest DBUs versus DSU storage, with an unverified list-dollar estimate alongside each raw usage figure.
system.billing.usagesystem.billing.list_pricesOne row = a Vector Search endpoint + day + usage type's spend. The columns that matter are usage_type (STORAGE_SPACE is DSU storage, everything else is serving DBUs - different units) and net_list_cost (est_usd_list, the dollarized driver behind the band, which is safe to compare across usage_type because it is already in dollars).
RequiresSELECT on system.billing; GA
Vector Search endpoints bill for serving and ingest compute continuously, so an endpoint left running with little or no query traffic is pure waste that this query is designed to surface (it feeds the idle-endpoint check against access traffic). Because serving DBUs and DSU storage are metered in different units, mixing them produces a meaningless total and hides which lever — right-sizing serving vs. pruning stored vectors — actually cuts the bill. The dollar figure here is list, pre-discount, and rides an unverified price cast, so it sizes relative opportunity between endpoints but must not be quoted as the real invoiced cost.
SELECT u.usage_date, u.cloud, u.sku_name, u.usage_type, u.usage_unit,
CASE WHEN u.usage_metadata.endpoint_name IS NULL THEN u.usage_metadata.endpoint_name ELSE concat(substr(u.usage_metadata.endpoint_name, 1, 2), '****') END AS endpoint_name,
u.usage_metadata.endpoint_id AS endpoint_id,
lp.currency_code,
SUM(u.usage_quantity) AS net_usage_quantity,
SUM(u.usage_quantity * lp.list_rate) AS net_list_cost,
-- status: est_usd_list/day band per endpoint (field heuristic; :warn_endpoint_usd_per_day / :crit_endpoint_usd_per_day).
CASE
WHEN SUM(u.usage_quantity * lp.list_rate) IS NULL THEN 'NOT_ASSESSED'
WHEN SUM(u.usage_quantity * lp.list_rate) >= :crit_endpoint_usd_per_day THEN 'CRITICAL'
WHEN SUM(u.usage_quantity * lp.list_rate) >= :warn_endpoint_usd_per_day THEN 'WARN'
ELSE 'OK'
END AS status
FROM system.billing.usage u
LEFT JOIN (
SELECT sku_name, cloud, currency_code, price_start_time, price_end_time,
CAST(pricing.effective_list.default AS DOUBLE) AS list_rate -- <-- UNVERIFIED path (same caveat as cost_dollarized_by_sku_day)
FROM system.billing.list_prices
) lp
ON u.sku_name = lp.sku_name
AND u.cloud = lp.cloud
AND u.usage_end_time >= lp.price_start_time
AND (lp.price_end_time IS NULL OR u.usage_end_time < lp.price_end_time)
WHERE u.billing_origin_product = 'VECTOR_SEARCH'
AND u.usage_date >= dateadd(day, -:period_days, current_date())
AND u.usage_date < current_date()
GROUP BY u.usage_date, u.cloud, u.sku_name, u.usage_type, u.usage_unit,
u.usage_metadata.endpoint_name, u.usage_metadata.endpoint_id, lp.currency_code
ORDER BY net_list_cost DESC NULLS LAST:period_daysdefault 30rolling window in days:warn_endpoint_usd_per_daydefault 25estimated list-price $/day on a single Vector Search endpoint that flags WARN:crit_endpoint_usd_per_daydefault 100$/day that flags CRITICALusage_type/usage_unit, so the two units are never blended.net_list_cost) from the matching time-windowed price — pre-discount and unverified.endpoint_id so serving rows can be cross-checked against query traffic to spot idle endpoints.| Column | How to read it |
|---|---|
| usage_date | The calendar day (DATE) the consumption was metered; the window excludes today, so the latest day is provisional. |
| cloud | The cloud provider (AWS/AZURE/GCP) — also part of the price-join key, so rates match the right cloud. |
| sku_name | The billed Vector Search SKU; distinguishes serving/ingest compute SKUs from the DSU storage SKU. |
| usage_type | Confirmed enum tag for the row's nature; `STORAGE_SPACE` = DSU storage, any other value (e.g. `COMPUTE_TIME`) = serving/ingest DBUs. Do not sum across these. |
| usage_unit | The unit `net_usage_quantity` is denominated in — `DBU` for serving/ingest rows, `STORAGE_SPACE` for DSU storage rows. The guardrail that keeps units unmixed. |
| endpoint_name | The Vector Search endpoint's name, masked to its first 2 characters + `****` (NULL is passed through as NULL); for human identification of the endpoint, unmasked only if the mask CASE is dropped. |
| endpoint_id | The endpoint's UUID, passed through unmasked — the stable key to join back to access/traffic tables and resolve the real name. |
| currency_code | The currency of `net_list_cost` (from the price row); NULL when no price row matched the SKU/window. |
| net_usage_quantity | Net metered usage in `usage_unit` (DBUs or DSU storage units), `SUM(usage_quantity)` across all record types so corrections already net out — NOT dollars. |
| net_list_cost | `SUM(usage_quantity * list_rate)` — an estimated LIST/pre-discount dollar amount on an unverified price path; NULL when the SKU/window had no matching price. Never a billed headline figure. |
net_list_cost below :warn_endpoint_usd_per_day est_usd_list/day per endpoint (field heuristic - tune for your account).
net_list_cost at/above :warn_endpoint_usd_per_day (WARN) or :crit_endpoint_usd_per_day (CRITICAL) est_usd_list/day (field heuristic); or net_list_cost is NULL (NOT_ASSESSED - the list-price join found no matching price row, not $0).
| usage_date | sku_name | usage_type | usage_unit | endpoint_name | net_usage_quantity | net_list_cost | currency_code |
|---|---|---|---|---|---|---|---|
| 2026-07-05 | VECTOR_SEARCH_SERVING | COMPUTE_TIME | DBU | cu**** | 1200.00 | 84.00 | USD |
| 2026-07-05 | VECTOR_SEARCH_STORAGE | STORAGE_SPACE | STORAGE_SPACE | cu**** | 512.00 | 102.40 | USD |
| 2026-07-04 | VECTOR_SEARCH_SERVING | COMPUTE_TIME | DBU | se**** | 340.00 | 23.80 | USD |
Rank Vector Search endpoints by `net_usage_quantity` (and, provisionally, `net_list_cost`), cross-reference the serving-side spend against endpoint traffic (via `access_vector_search_traffic`, joined downstream in-engine) to find endpoints that are billing serving/ingest DBUs but getting little or no query traffic, and target those idle endpoints for consolidation or teardown — keeping the STORAGE_SPACE (DSU) rows evaluated separately since they are a different unit.
Feeds into: Vector Search spend by endpoint (serving vs ingest vs DSU storage); idle-endpoint opportunity (joined to access_vector_search_traffic in-engine)
A tiny reference table that resolves each numeric workspace ID to its human name and active/deleted status, one row per workspace.
system.access.workspaces_latestOne row = a workspace. The columns that matter are workspace_id (the join key every other cost/identity query keys on) and workspace_name (the human label to show instead of the numeric id) - status distinguishes an active workspace from a deleted one.
RequiresSELECT on system.access; GA
Every per-workspace cost, identity, and provenance figure in this library is keyed on a bare numeric `workspace_id`, which is meaningless to a human reviewing a bill or a chargeback report. This lookup is what lets those figures read as `dev / uat / prod` so an admin can actually assign spend and act on it. It is kept as a separate, tiny query on purpose: if the access table is disabled or errors, only the friendly names are lost and every dollar figure keyed on `workspace_id` still works, falling back to the numeric id.
SELECT workspace_id, workspace_name, status
FROM system.access.workspaces_latest
ORDER BY workspace_name, workspace_idworkspace_id to its human workspace_name so downstream cost cuts read as dev / uat / prod.status, so you can tell live spend from spend attributed to a decommissioned workspace.| Column | How to read it |
|---|---|
| workspace_id | The numeric workspace identifier. This is the exact key every per-workspace billing rollup joins on; pass it through unchanged. |
| workspace_name | The human-readable name of the workspace (e.g. dev / uat / prod). Use this to label per-workspace cost and chargeback output. |
| status | Whether the workspace is currently active or has been deleted; lets you separate live workspaces from decommissioned ones that may still carry historical spend. |
Inventory / reference query — it returns state to read, not a pass/fail band.
| workspace_id | workspace_name | status |
|---|---|---|
| 1234567890123456 | prod | ACTIVE |
| 2345678901234567 | uat | ACTIVE |
| 3456789012345678 | legacy-dev | DELETED |
Use this as the label lookup for every per-workspace cost, identity, and provenance report: join `workspace_id` to attach `workspace_name`, falling back to the raw id when a name is missing, and use `status` to flag spend still attributed to deleted workspaces for cleanup.
Feeds into: workspace_id -> name lookup, so every per-workspace cut (cost, identity, provenance) shows "dev / uat / prod" instead of an opaque numeric id
The full history of Databricks public list (pre-discount) prices per SKU, one row per price change, collected raw so the engine can price each usage row in its correct time window.
system.billing.list_pricesOne row = a SKU's price at a point in time, with the full pricing struct preserved as JSON. The columns that matter are pricing_default (the list rate) and price_end_time (NULL means this is the currently active price) - pricing_effective_list_json and pricing_promotional_json carry the raw structs for you to parse yourself.
RequiresSELECT on system.billing; GA
This is the rate book that turns raw DBU consumption into dollars. Without it, every cost figure falls back to a single hardcoded $/DBU guess that mis-prices most SKUs and ignores that prices change over time. Because it captures the full [price_start_time, price_end_time) history rather than only today's price, historical spend gets dollarized at the rate that was actually in effect on each usage day, and the account's real discount can be measured against a trustworthy list baseline. Getting this basis right is the difference between a defensible chargeback and a number nobody trusts.
SELECT price_start_time, price_end_time, account_id, sku_name, cloud, currency_code, usage_unit,
CAST(pricing.default AS STRING) AS pricing_default,
CAST(pricing.effective_list AS STRING) AS pricing_effective_list_json,
CAST(pricing.promotional AS STRING) AS pricing_promotional_json
FROM system.billing.list_prices
ORDER BY sku_name, cloud, currency_code, price_start_timeprice_start_time to price_end_time) so a usage row can be matched to the price that was live on its day; a NULL end time marks the currently-active price.pricing.default, effective_list, promotional) as raw JSON strings rather than pre-computed dollars, leaving the actual DBU-to-dollar arithmetic to be done in-engine.| Column | How to read it |
|---|---|
| price_start_time | Timestamp this list price became effective. The start edge of this row's validity window. |
| price_end_time | Timestamp this list price stopped being effective; the end edge of the window. **NULL means this is the currently-active price.** When matching usage, the predicate must be `(price_end_time IS NULL OR usage < price_end_time)` or recent usage silently prices to zero. |
| account_id | The Databricks account the price row belongs to (UUID, passed through). |
| sku_name | The billing SKU this price applies to (e.g. a specific jobs-serverless or SQL-serverless compute SKU). Join key back to usage — always paired with cloud + currency_code + usage_unit, never used alone. |
| cloud | Cloud provider this price is for (AWS / AZURE / GCP). Part of the composite join key; multi-cloud accounts have several rows per SKU. |
| currency_code | Currency the price is quoted in (e.g. USD). Part of the composite join key. |
| usage_unit | The unit the price is per (typically DBU). Part of the composite join key; keeps DBU rates from being applied to non-DBU units. |
| pricing_default | The `pricing.default` field cast to a string — the headline per-unit list rate for this SKU/window. Typed STRING in the docs; confirm it casts cleanly to a number before doing arithmetic with it. |
| pricing_effective_list_json | The `pricing.effective_list` object serialized to a JSON string. The intended list-dollarization path is the nested `effective_list.default` scalar inside this JSON, but that path and its numeric cast are **unverified** on-workspace — parse defensively. |
| pricing_promotional_json | The `pricing.promotional` field serialized to JSON — any promotional/temporary pricing detail, if present. Also parsed defensively downstream. |
Inventory / reference query — it returns state to read, not a pass/fail band.
| sku_name | cloud | currency_code | usage_unit | price_start_time | price_end_time | pricing_default |
|---|---|---|---|---|---|---|
| ENTERPRISE_JOBS_SERVERLESS_COMPUTE | AWS | USD | DBU | 2024-01-01T00:00:00Z | 2025-03-01T00:00:00Z | 0.35 |
| ENTERPRISE_JOBS_SERVERLESS_COMPUTE | AWS | USD | DBU | 2025-03-01T00:00:00Z | NULL | 0.30 |
| ENTERPRISE_SQL_SERVERLESS_COMPUTE | AZURE | USD | DBU | 2024-06-01T00:00:00Z | NULL | 0.70 |
Use this as the authoritative per-SKU rate basis: parse `pricing_default` (or the `effective_list.default` path) in-engine and multiply it against net DBUs from `system.billing.usage`, matching each usage row to its correct price window, to replace any hardcoded $/DBU and produce list-dollarized spend. Validate the STRING-to-number cast on your workspace before trusting the resulting dollars.
Feeds into: dollarization (list-price × discount_factor); cost totals; per-SKU rate basis for the aggregator (replaces the hardcoded $0.55/DBU)