Quick Answer
Databricks system tables are read-only tables in the system catalog that record platform activity. For cost governance, the key pair is system.billing.usage, which logs every unit consumed with its SKU and tags, and system.billing.list_prices, which holds list prices over time. Join them, group by tag, and you have spend by team, project or environment.
- Cost: the tables themselves are part of the platform; querying them uses ordinary SQL warehouse compute.
- Effort: a working showback dashboard takes days; a tagging standard people follow takes weeks of policy work.
- Risk: list prices ignore negotiated discounts, and billing data can lag by up to a day.
- Fit: any lakehouse with more than one team sharing a workspace, or any finance team asking who spent what.
Every consumption platform eventually hits the same meeting. Finance asks why the bill went up, engineering says usage grew, and nobody in the room can say whose usage. On a lakehouse shared by several teams, that meeting repeats monthly until someone builds attribution.
The spend involved is not trivial. In its December 2025 Series L announcement, Databricks reported more than 700 customers consuming at over $1 million in annual run-rate. At that scale, “usage grew” is not an answer a CFO will accept, and a showback report built by hand in a spreadsheet does not survive the second reorganization.
The good news is that the data already exists inside the lakehouse platform itself. This guide covers which system tables matter for cost, how to design tags that survive contact with real engineers, what budgets do and do not do, and how to turn the result into a chargeback model finance will sign off.
The Two Tables That Carry Cost Governance
Databricks exposes platform telemetry as system tables governed by Unity Catalog. Several schemas exist, but cost work starts with two tables in the billing schema.
system.billing.usage
The billable usage reference documents one record per slice of consumption. The columns that matter most are usage_quantity (units consumed), usage_unit, sku_name, custom_tags (a map of the tags on the compute that ran the work) and usage_metadata, a struct that identifies the resource: job_id, job_run_id, warehouse_id, cluster_id, notebook_id, endpoint_name and a policy identifier for serverless work.
That metadata is what makes attribution possible without tags. Even an untagged job run can be traced to its job, and the job to its owner. Tags then add the business dimensions the platform cannot infer: cost center, product, environment.
system.billing.list_prices
The pricing table keeps a history of SKU prices by cloud and currency, with a price_start_time and price_end_time for each row. The pricing struct carries a default list price, a promotional price and an effective_list price used for cost calculation. The documentation is direct that these are published list prices and “do not reflect negotiated discounts.”
Turning Usage Into Dollars
The cost monitoring guide describes the join. Match on sku_name, then keep only the price row that was in effect when the usage ended: usage_end_time on or after price_start_time, and either no price_end_time or a usage_end_time before it. Multiply usage_quantity by pricing.effective_list.default and sum.
From that one query you can group by almost anything. Three views cover most governance needs:
- By tag. Filter or group on a key in custom_tags, such as cost_center or env. This is the chargeback view.
- By resource. Group on usage_metadata.job_id or warehouse_id to find the five workloads that drive most of the bill.
- By SKU over time. Group on sku_name by week to see whether serverless, jobs or SQL is growing fastest.
Account admins can also import the pre-built usage dashboards Databricks provides and customize them, which is the fastest way to a first view. Most teams outgrow the default within a month, because the default does not know their tag standard.
Designing Tags That Survive Real Use
A tag standard is a process decision before it is a technical one. Agree on three to five keys, their allowed values and who owns each, then enforce them in code. The usage tags documentation sets the mechanics.
| Tag key | Example values | Owner | Enforced by |
|---|---|---|---|
| cost_center | finance-ops, supply-chain | Finance | Compute policy allowed values |
| env | dev, test, prod | Platform team | Separate policies per environment |
| product | gold-sales, security-lake | Data product owner | Job and pipeline definitions in bundles |
| owner | team alias, not a person | Team lead | Compute policy, reviewed quarterly |
Compute policies can require specific custom tags, and cluster creation fails if a required tag with an allowed value is missing. That single control does more for chargeback accuracy than any dashboard. Databricks also adds default tags such as Vendor, Creator, ClusterName and ClusterId, and SQL warehouses carry a SqlEndpointId tag, so some attribution exists even before your standard lands.
Serverless needs its own path, because there is no cluster for a policy to tag. Databricks handles this with serverless policies assigned to users and groups; tags from those policies flow into custom_tags so serverless notebooks, jobs and pipelines stay attributable.
What Breaks Chargeback in Practice
The query is the easy part. These five problems are what stop most chargeback programmes from reaching finance.
Tags that never reach the pool or the old cluster
Tag changes on a cluster apply after a restart, so a long-running cluster keeps billing under its old labels. Pools add a second trap. The documentation notes that when a cluster is created from a pool, its instances inherit the custom and default workspace tags and the pool tags, not the cluster tags. Tag the pools themselves, and schedule restarts after any tag rollout.
Collisions and the 20-tag ceiling
A workspace resource accepts no more than 20 tags, and keys and values accept only letters, numbers and a short list of symbols, with no spaces or slashes. When a custom tag collides with a default key, it is prefixed with x_ during propagation, which silently splits one dimension into two. Collisions added through compute policies fail cluster creation outright. Keep the standard short and test it in dev first.
List price versus the invoice
Cost computed from list_prices will not match an invoice once a committed-use discount applies. That is acceptable for comparing teams, because every team is measured on the same basis. It is not acceptable for reconciliation. Publish the dashboard as “list-price cost” and apply the contractual discount as a single, documented factor if finance needs invoice-level figures.
Late data and month-end timing
Billing data can arrive with up to a day of delay, so a report run on the first of the month is short. Close the month two or three days late, the way finance already closes other ledgers, and state the cut-off on the dashboard.
Shared costs nobody owns
Shared SQL warehouses, platform jobs and ingestion that feeds everyone do not belong to one team. Decide the allocation rule up front, whether proportional to query time, even split or central overhead, and write it down. Without a written rule, every chargeback review turns into a negotiation.
Budgets: Early Warning, Not a Substitute for Policy
Account admins can create budgets that watch spend and send email notifications when thresholds are crossed. Budgets can be scoped by workspace and by custom tags, and recipients do not need to be Databricks users, which lets a finance partner receive the alert directly.
Treat budgets as an alarm. Notifications for standard budgets can arrive up to 24 hours after the spend, so a runaway cluster can burn through a day of cost before anyone reads the email. The controls that prevent spend are compute policies, auto-termination, serverless policies and sensible warehouse sizing. Budgets tell you those controls were not enough.
A practical pattern is one budget per cost center at 80% and 100% of the monthly plan, plus one budget on untagged usage. That last budget is the most useful of all: it tells you where the tag standard is leaking.
From Showback to Chargeback
Start with showback. Publish spend by cost center for two or three months without billing anyone. Teams correct their own tags quickly once they see their name next to a number, and the allocation rules get tested before money moves.
Move to chargeback once untagged spend is small and stable and finance agrees the method. This is a Lean Six Sigma problem as much as a data problem: define the measure, fix the process that produces bad data, then control it. Our piece on Lakeflow and Lean Six Sigma covers that discipline for pipelines, and the same logic applies to cost data. The governance side, meaning who can see which cost data and who owns tag values, fits inside the wider work described in our data governance consulting guide.
Once attribution works, the savings conversation becomes specific. You stop asking “how do we cut Databricks cost” and start asking why one job costs four times its peer. The levers for that second question are in our Databricks cost optimization guide.
Score Your Cost Governance Readiness
Give yourself one point for each statement that is true today. Be strict: “mostly” counts as no.
- Every production workload runs on job compute, serverless or a SQL warehouse, not an all-purpose cluster.
- A written tag standard exists with three to five keys, allowed values and an owner for each.
- Compute policies reject clusters that lack the required tags.
- Serverless usage carries tags through a serverless policy.
- A dashboard joins system.billing.usage to list prices and is reviewed monthly.
- Untagged spend is tracked as its own line with a budget on it.
- Finance has agreed how shared warehouses and platform jobs are allocated.
- Budget alerts go to someone who can act on them within a day.
Scoring 7 or 8 means you are ready for chargeback. Scoring 4 to 6 means run showback for a quarter and close the gaps it exposes. Scoring 3 or below means start with the tag standard and compute policies before building any dashboard. If you want help setting that foundation, our Databricks consulting team can run this assessment with you as the first step of a lakehouse cost engagement.
Frequently Asked Questions (FAQs)
What are Databricks system tables?
They are read-only tables in the system catalog that record activity across your account, including billing, compute and access. They are governed by Unity Catalog, so access is granted like any other table.
How do I calculate cost from system.billing.usage?
Join it to system.billing.list_prices on sku_name, keep the price row in effect when the usage ended, and multiply usage_quantity by pricing.effective_list.default. The result is cost at list price.
Does system.billing.list_prices include my discount?
No. The table holds published list prices and does not reflect negotiated discounts. Apply your contractual discount separately if you need invoice-level numbers.
How current is the billing data?
Expect a delay of up to 24 hours. Close monthly reports a few days after month end so late records are included.
Can Databricks tags be enforced?
Yes. Compute policies can require specific tags with allowed values, and cluster creation fails when they are missing. Serverless work is tagged through serverless policies assigned to users and groups.
Do Databricks budgets stop spending?
Treat them as alerts. Standard budget notifications can lag by up to a day, so use compute policies, auto-termination and warehouse sizing to prevent spend and budgets to flag when those controls fall short.
What is the difference between showback and chargeback?
Showback reports each team’s spend without billing it. Chargeback moves the cost into each team’s budget. Run showback first so tags and allocation rules are proven before money changes hands.