The system.billing.usage Deep Dive

Estimated read: 3 min

Every Oracle or Teradata shop eventually built the same report: a query against v$sql or a resource-monitor log, joined against a spreadsheet of chargeback rates, to answer “who spent what.” Databricks gives you that report as a first-class Delta table instead of a bespoke script. The system.billing.usage table, part of Unity Catalog’s built-in system catalog, is the ledger of every billable event in your account: one row per usage record, with the workspace, the SKU, the quantity of DBUs (Databricks Units) consumed, and – critically – a custom_tags map you control.

DBUs alone don’t tell you a dollar figure, because list price varies by SKU, cloud, and changes over time. That’s what system.billing.list_prices is for: a time-versioned table where each row covers a price_start_time/price_end_time window for a given SKU, so a single join reconstructs exactly what a DBU cost on the day it was consumed, not today’s price. The canonical join looks like this:

SELECT
  u.usage_date,
  u.sku_name,
  u.usage_metadata.job_id,
  u.custom_tags,
  u.usage_quantity * p.pricing.default AS list_cost_usd
FROM system.billing.usage u
JOIN system.billing.list_prices p
  ON u.sku_name = p.sku_name
  AND u.cloud = p.cloud
  AND u.usage_start_time >= p.price_start_time
  AND (u.usage_start_time < p.price_end_time OR p.price_end_time IS NULL)
WHERE u.usage_date >= current_date() - INTERVAL 30 DAYS

Two fields do the heavy lifting for FinOps work. usage_metadata is a struct carrying the resource that generated the record – cluster_id, job_id, warehouse_id, notebook_id, and similar identifiers – so you can trace a dollar figure back to the exact job or warehouse that ran it, the same way an Oracle DBA traced a resource spike back to a specific session ID. custom_tags is the map that carries your attribution taxonomy: team, project, cost center, environment – whatever keys you standardize on when tagging clusters, jobs, and SQL warehouses. If a workload isn’t tagged, its cost is unattributable by definition, which is why tag discipline (covered next lecture) has to be enforced before this table becomes useful for chargeback rather than just aggregate spend tracking.

system.billing.usage records DBU quantities, not dollars. Every chargeback query needs the list_prices join – treating usage_quantity alone as a cost figure will silently misprice any SKU whose list price has changed during your reporting window.

Both tables are populated automatically once Unity Catalog is enabled and require no separate ingestion pipeline – Databricks writes to them as usage occurs, typically with a latency of a few hours. Read access is governed by ordinary Unity Catalog grants: SELECT on the system catalog’s billing schema, scoped to account admins or a dedicated FinOps role, exactly like granting read access to a finance schema in your legacy warehouse.

Two more usage-metadata fields are worth knowing before you build anything on top of this table. billing_origin_product tells you which product line generated the record – JOBS, DLT (Lakeflow Declarative Pipelines), SQL (warehouses), MODEL_SERVING, and dozens more – which matters because a migration typically shifts spend mix over time: heavy JOBS usage during initial batch backfills, growing SQL usage as BI tools cut over, and MODEL_SERVING appearing only once downstream ML workloads land. Tracking that mix shift over the parallel-run period is often the first FinOps signal that a cutover phase has actually started consuming production traffic. Record type – ORIGINAL, RETRACTION, RESTATEMENT – exists because billing corrections happen: a usage record can be retracted and restated days later if Databricks identifies a metering error, so a chargeback report that sums usage_quantity without filtering or reconciling record types can double-count or miss a correction. For most dashboards, filtering to ORIGINAL records and re-running historical aggregates periodically is simpler than trying to net RETRACTION/ RESTATEMENT pairs in real time.

Reference: system.billing.usage schema reference and system.billing.list_prices schema reference.

---

| ← Previous: FinOps Engineering: System Tables and Chargeback | Next: Attribution and Chargeback Taxonomy → | |:—|—:|