Databricks DBU cost: where it goes and how to cut it

Guides · 25 September 2026 · 8 minute read

A Databricks bill is two bills. Databricks charges in DBUs, a unit of processing billed per second at a rate that depends on the workload type and your tier, and your cloud provider separately charges for the virtual machines, storage and network underneath. Most Databricks cost optimisation work is about the first bill, because the DBU rate is where the same job can cost several times more depending on how it is run.

Where DBUs go

All-purpose compute for scheduled work

All-purpose (interactive) clusters carry the highest DBU rate. Jobs compute is priced well below it for the same hardware. A scheduled pipeline that runs on an all-purpose cluster because that is where it was developed is the single most common leak, and moving it to a job cluster changes nothing about the code.

Clusters that never stop

An interactive cluster with auto-termination off, or set to hours, bills DBUs and VM hours while its notebook sits idle. The same applies to SQL warehouses with a long auto-stop. Idle time is invisible in the job history and very visible in the bill.

Oversized drivers and fixed-size clusters

Drivers sized like workers when the driver does little; clusters fixed at their peak size rather than autoscaling; and a large minimum worker count that autoscaling never goes below.

Photon everywhere

Photon accelerates SQL and DataFrame workloads and carries a higher DBU rate. On the workloads it speeds up, it usually pays for itself; on Python UDF-heavy or streaming code it can simply cost more. It should be a per-job decision.

Serverless without a budget

Serverless SQL and serverless jobs remove cluster management and start fast, and they bill from the first second. Without auto-stop, warehouse sizing and a query-cost review, they make spend easier to create than to see.

The second bill

On the cloud side: on-demand instances where Spot would do, cross-region data transfer, storage never tiered, and small-file explosions that make every query read more than it should.

How to cut it

• Move scheduled work to jobs compute. Same code, lower rate. Start with the longest-running schedules.
• Set auto-termination everywhere. Minutes, not hours, for interactive clusters; short auto-stop on SQL warehouses.
• Enforce cluster policies. Policies cap instance types, worker counts, auto-termination and Photon by team, so the defaults are the cheap ones and exceptions are deliberate.
• Autoscale, and set the minimum honestly. Then check the driver size separately.
• Use Spot for workers on fault-tolerant jobs, with an on-demand driver and a fallback.
• Decide Photon per job, by measuring the same job with and without it.
• Fix the data, not only the compute: compaction and file sizing on Delta tables, Z-ordering or liquid clustering where queries filter, and lifecycle rules on the storage account.

How to see it

Databricks system tables, in particular the billing usage table, give DBU consumption per workspace, SKU, cluster and job, with the tags you set. Join that to your cloud bill by cluster tag and you have a cost per job. Tag clusters and jobs by team and pipeline from the start; a tag added later explains nothing about last quarter. Set budget alerts in the account console on top of that.

A note on Unity Catalog

Governance and cost meet in Unity Catalog. Lineage tells you which tables a job reads, which is how you find the pipeline recomputing something nobody uses. It is also where access controls live, so the cost review and the security review can share one map of the workspace.

Our Databricks Platform engagement covers setup, Unity Catalog governance and Databricks cost optimisation as fixed-scope work, and a free cloud cost audit is the usual starting point.