How to Reduce Databricks Costs: DBUs, Photon, and Spot Clusters

You reduce Databricks costs by attacking the things that drive DBU consumption: the compute type you run, how long clusters sit idle, how big they are, and which engine they use. A Databricks bill is the number of DBUs consumed times a per-DBU rate, plus the underlying cloud VM cost. The rate depends heavily on compute type: Jobs Compute runs at roughly 0.15 dollars per DBU, while All-Purpose Compute for interactive notebooks costs several times more, per the Databricks pricing page. Most overspend is scheduled pipelines left on All-Purpose Compute, interactive clusters that never auto-terminate, and oversized clusters running on full on-demand capacity. Fix those and the DBU count falls without touching the work itself.

This guide is part of our complete guide to SaaS and data platform cost optimization, the cluster pillar it links up to. For the warehouse-versus-lakehouse cost trade-off, see its sibling, Snowflake vs Databricks: a 2026 cost comparison.

What is a DBU in Databricks?

A DBU, or Databricks Unit, is the normalized unit of processing Databricks bills per hour. Your compute bill is DBUs consumed multiplied by a per-DBU rate, on top of the cloud VM cost for the instances themselves. The rate is not fixed: it depends on the compute type and tier, which is why two clusters doing similar work can cost very differently. Jobs Compute, used for automated pipelines, is the cheapest at around 0.15 dollars per DBU. All-Purpose Compute, used for interactive notebook development, costs roughly two to three times more per DBU. Understanding that the rate is set by compute type is the key to the largest saving, because it means moving a workload to the right compute type cuts cost with no change to the logic.

How do you cut a Databricks bill, step by step?

Cut the bill by attributing DBUs first, then fixing the largest driver. The sequence below is the one we run on a data platform cost engagement, and the early steps deliver most of the saving.

1. Attribute DBUs to workloadsUse system tables and cluster tags to attribute DBU consumption to jobs, teams and clusters. The result is a ranked map of where the spend actually goes, so you cut the heavy workloads rather than guessing.
2. Move scheduled work to Jobs ComputeRun every scheduled pipeline on Jobs Compute rather than All-Purpose Compute, which costs several times more per DBU. The result is the single largest saving, because it lowers the rate on your highest-volume work without changing it.
3. Right-size clusters and auto-terminateMatch cluster size to the job rather than the largest job, and set auto-termination so idle interactive clusters stop instead of burning DBUs while nobody runs anything. The result is no DBUs paid for idle time.
4. Use spot workers and autoscalingRun worker nodes on spot or preemptible instances with an on-demand driver, and enable autoscaling so the cluster grows for the heavy stage and shrinks for the rest. The result is a much cheaper VM bill on fault-tolerant jobs.
5. Enable Photon where it paysTurn on the Photon engine for large SQL and dataframe workloads where its speedup outweighs its higher DBU multiplier, and leave it off where it does not. The result is faster jobs that finish cheaper, not just faster.
6. Govern it so it stays cutSet budgets and anomaly alerts per workspace and tag so a new oversized cluster or a job moved back to All-Purpose Compute is caught the same week. The result is a bill that holds instead of drifting back up.

Does Photon make Databricks cheaper?

Photon makes Databricks cheaper when its speedup outweighs its higher DBU multiplier, and not otherwise. Photon is a vectorized query engine that runs SQL and dataframe workloads faster, so a job completes in fewer minutes. But Photon clusters consume DBUs at a higher rate, so each minute costs more. The net effect depends on the workload: for large SQL queries and heavy ETL, the runtime reduction usually beats the rate increase, and the job is cheaper overall. For small jobs, streaming, or code that Photon cannot accelerate, you pay the higher rate without the speedup, and it costs more. The rule is to enable Photon selectively, measure the before-and-after on real jobs, and keep it where the total cost falls.

How much can spot instances save on Databricks?

Spot or preemptible worker nodes can cut the cloud VM portion of a Databricks cluster substantially, often well over half on the worker fleet. The DBU charge is separate, but the underlying compute is a real part of the bill, and spot capacity is heavily discounted against on-demand. The trade is reliability: a spot node can be reclaimed mid-job, so this suits fault-tolerant work such as batch ETL and model training that can restart a task, not latency-sensitive interactive sessions. The standard pattern is to keep the driver on demand for stability, run the workers on spot with on-demand fallback, and combine it with autoscaling so the cheap, elastic worker fleet does the heavy lifting. Confirm current spot discounts in your cloud provider's documentation before sizing the saving.

The short version

Reduce Databricks costs by attributing DBUs, moving scheduled work to Jobs Compute, auto-terminating idle clusters, running workers on spot, and enabling Photon only where it pays, then governing with budgets. Compute type is the largest lever, so fix that first. Weigh the platform choice itself in Snowflake vs Databricks and return to the SaaS and data platform cost pillar for the rest of the stack.