Your Databricks cluster cost arrives on two bills. Databricks bills you for DBUs, and AWS, Azure or GCP bills you for the machines. Most teams watch only the first one, their Databricks DBU cost. When one of our customers right-sized a scheduled job, the Databricks bill showed $575 saved. The same fix saved $2,121 on the cloud bill, and a DBU-only report never showed it.
We tracked both bills across customer environments in different industries. The goal was to find which workloads hide the most cost on the second bill, and how you can check your own split.
Four facts explain the gap:
- DBU and cloud infrastructure are two separate billing legs. Serverless SKUs combine both into one number. Classic and provisioned compute bill them separately.
- The infra leg ranged from zero to nearly four times the DBU leg. The size of the gap tracked the workload type, not the company.
- The same right-sizing fix that trims a job's DBU cost also trims its infra cost.
- Most tenants do not measure the second leg today. Reading it means configuring access to tables that Databricks and the cloud provider already expose.
What Is Included in Databricks Cluster Cost?
A classic compute Databricks bill has two parts. The first is the DBU charge. A DBU is Databricks' metering unit for its platform. The Databricks pricing page lists its price for each compute type and tier. The second is the cost of the virtual machines the workload ran on, billed by AWS, Azure or GCP on a separate invoice. On serverless, Databricks runs the machines and folds their cost into the DBU price.
Pricing guides from Flexera, CloudZero and Cloudchipr put the second leg at 50 to 100 percent on top of DBUs. They suggest budgeting two to three times the DBU-only estimate. That figure is an average across many customers, and an average hides how much the second leg changes from one workload to the next.
So we measured it directly. Auto Tune is our right-sizing engine. It records what each cluster change saved on both legs, for every run. We pulled those records for customers in different industries and split them by compute type.
| Compute type | How it runs | Who pays for the machines | Where its waste lands |
|---|---|---|---|
| Job clusters | Created for one scheduled run, then torn down | You, on the cloud bill | Size: an oversized VM fleet, billed in infra |
| All-purpose clusters | Long-lived, shared and used from notebooks | You, on the cloud bill | Duration: idle runtime, billed in DBUs |
| Serverless | One bundled rate | Databricks, inside the DBU price | Nothing to split |
For a closer look at the first two, see how job compute and all-purpose compute differ in cost.
How Big Is the Infra Half of Your Databricks Bill?
The infra half depends on what you run. We broke one tenant's realized savings data out by compute type. Infra ran 3.7x the DBU cost on job clusters. It ran 0.4x on all-purpose clusters and zero on serverless.
A single rule of thumb, "infra is roughly 2x DBU", is close on average and wrong for every compute type above. The gap comes from how each cluster type wastes money. Databricks provisions a job cluster fresh for every run. A policy default sets its size, not what the run needed. So a job cluster wastes money on size. An all-purpose cluster is already the size someone picked and sits idle between uses, so its waste is duration.
We checked the pattern in other customer environments, each in a different industry. It held. In one, job-cluster infra cost ran as high as 2.5x the DBU cost. In another, it stayed under 1x. All-purpose clusters stayed under 0.2x everywhere. Databricks job clusters always carried more infra cost than all-purpose clusters.
Two teams with the same DBU bill can therefore have very different infra bills. A team running mostly job clusters has far more cost going uncounted than one running mostly serverless warehouses.
Why Does a Smaller Job Cluster Cut Both Bills?
Job-cluster waste comes from the size of the cluster. So the fix that trims the DBU line also trims the infra line on the same run. Both bills follow from one number, the size of the cluster.
One job in the first customer environment shows this. It is the largest single contributor to the 3.7x figure above, and roughly 80 percent of that tenant's job-cluster savings. Auto Tune applied one recommendation to it, then kept applying it automatically across roughly 9,960 later runs of the same job. The realized total from that one decision was $575 in DBU savings and $2,121 in infra savings, tracked in the same ledger against the same runs.
That split lands almost exactly on the tenant's 3.7x job-cluster average. Nobody went looking for infra savings separately. A smaller cluster meters fewer DBUs and rents fewer VM-hours at the same time. The DBU-side fixes your team has already shipped are likely buying infra savings that nobody counts. Where the ratio runs two to four times, that is two to four uncounted dollars for every dollar claimed. How Auto Tune right-sizes job clusters covers the right-sizing side in detail.
How to Track Databricks Infra Cost Next to DBUs
Most Databricks tenants do not measure the infra leg yet. The cost is measurable, and reading it means turning something on. The DBU side already sits in the system.billing.usage system table. The machine side sits in your cloud provider's billing export, such as the AWS Cost and Usage Report. Reading both takes one account-level configuration step, because Databricks and the cloud provider already expose the tables.
That configuration step is the gap we close. We walk a customer through the account-side setup once and ingest the infra-cost tables next to their DBU billing. The two then sit side by side, per job and per cluster, in one platform, so nobody reconciles two exports by hand. From there the customer gets one total cost of ownership number and tracks and forecasts DBU and infra separately. The same right-sizing levers that already pull DBU savings then show their effect on the infra number too.
Another customer environment connected its infra cost data. One job there showed $782 in DBU savings and $1,740 in infra savings. Both numbers landed in the platform's savings log automatically.
How to Check Your Own DBU and Infra Split
You can run three checks on your own Databricks cluster cost this week.
- Split DBU from infra by compute type. Pull your cost or savings data and break job clusters out from all-purpose clusters before you trust one blended ratio. Leave serverless out. Databricks bundles its infra cost into the DBU rate. Expect the widest gap on job clusters.
- Check whether infra cost is tracked at all. Look for the actual-cost table that your cloud provider and Databricks expose. An empty or missing table means nobody turned on an account-level configuration step. It is not a hard limit.
- Find the infra delta of one fix you already shipped. Pick a right-sizing change on a job cluster and look for its infra-cost change on those same runs. Tooling that reports only DBUs will not show it. That saving goes uncounted.
Why Do You Need Both the DBU and the Infra Leg?
Savings work that measures only DBUs measures half the bill. On job clusters, a fix that shows a DBU saving very likely produces an uncounted infra saving too. Wire in the infra leg and you get one total cost of ownership number for Databricks cluster cost. You can track and forecast it per job and per cluster. Each fix then gets credit for what it saved on both meters. Altimate for Databricks puts both legs in one place, per job and per cluster.
See your own DBU and infra split. We will show how this gap surfaced in other Databricks tenants and what the setup takes in yours. There is no cost and no obligation.
Frequently Asked Questions
Does Databricks cluster cost include the cloud VMs?
It does on classic and provisioned compute, which has two parts. Databricks charges for DBUs, priced by compute type and tier. AWS, Azure or GCP charges separately for the virtual machines the workload ran on. On serverless, Databricks runs the machines and folds their cost into the DBU price.
How much does cloud infrastructure add to the DBU bill?
It depends on the compute type. Pricing guides put it at 50 to 100 percent on top of DBUs on average. In one tenant's realized savings, infra ran 3.7x the DBU cost on job clusters, 0.4x on all-purpose clusters and zero on serverless.
Why do Databricks job clusters carry the most infra cost?
A job cluster is provisioned fresh for every run and sized from a policy default rather than from what the run needed. Its waste is size, an oversized VM fleet, and that lands on the cloud bill. An all-purpose cluster's waste is idle duration, which lands mostly in DBUs.
Does right-sizing a cluster reduce both DBU and infra cost?
Right-sizing reduces both. A smaller cluster meters fewer DBUs and rents fewer VM-hours on the same runs. One Auto Tune recommendation ran across roughly 9,960 runs of one job. It saved $575 in DBUs and $2,121 in infra.
