Databricks now offers two ways to run compute: clusters you manage yourself, and serverless compute that Databricks manages for you. Here is the difference.
Quick definition
Databricks serverless compute is compute that Databricks provisions, manages, and scales automatically on your behalf. You submit a job, query, or notebook, and Databricks runs it against a shared, pre-warmed pool of infrastructure, then bills you only for what your workload actually used, measured in Databricks Units, or DBUs.
How it works
Classic Databricks clusters require you to provision infrastructure yourself: you pick the instance type, set a minimum and maximum worker count, and wait while Databricks spins that up, a process that takes minutes and runs nothing until it finishes. Serverless skips that step. Jobs, queries, and notebooks run against infrastructure Databricks keeps warm and ready, so they start almost immediately.
Autoscaling changes too. With classic clusters, you configure a minimum and maximum worker count yourself, then revisit those settings as workloads shift. Serverless scales up and down automatically based on real-time demand, with no thresholds to set ahead of time.
Billing follows the same shift. Classic clusters bill for uptime, whether or not the cluster is doing useful work. Serverless compute is billed by usage, in DBUs: you pay for what a workload actually consumes, not for capacity sitting idle.
Why teams adopt it
- Instant start. Teams stop waiting on cluster spin-up and get straight to the work.
- No capacity planning. Nobody has to guess at instance types or worker counts ahead of time.
- Pay for what you use. Budgets stop absorbing the cost of idle capacity.
- Less to manage. Time that used to go into tuning cluster configs goes elsewhere.
Adoption has moved well past early-adopter territory: as of Databricks' 2026 Data + AI Summit, half of all Databricks customers have opted into serverless compute for at least part of their workloads.
Serverless compute types at a glance
Serverless compute is available on AWS, Azure, and GCP at the Premium tier baseline. Individual capabilities like Lakebase and serverless GPUs have rolled out to each cloud on their own schedule, so availability varies by workload and region. See Databricks' own documentation (docs.databricks.com/aws/en/compute/serverless/) for the current cloud-by-cloud breakdown.
Frequently asked questions
What is serverless compute in Databricks?
It is compute that Databricks fully manages on your behalf: provisioning, scaling, and infrastructure are handled automatically, and you are billed only for what your workload actually uses, rather than for a cluster you configured and left running.
How is Databricks serverless compute billed?
Usage-based, in Databricks Units (DBUs). You pay for the compute your job, query, or notebook actually consumes. There is no separate cloud infrastructure bill to reconcile, since Databricks bundles that into the DBU rate.
Is serverless compute available on every cloud?
Yes. Databricks serverless compute is available on AWS, Azure, and GCP, though specific compute types, like serverless GPUs or Lakebase, have rolled out to each cloud on their own timeline, so it is worth checking current availability for your workload and region.
How is serverless different from classic (provisioned) compute?
With classic compute, you choose instance types and cluster sizes and configure your own autoscaling policy. You pay for cluster uptime whether or not it is fully utilized. Serverless removes that configuration and bills only for actual usage.
Do I have to choose serverless or classic for my whole workspace?
No. The choice is made at the workload level. You can run some jobs, queries, or notebooks on serverless and others on classic clusters within the same workspace, and most teams end up doing exactly that.
Why Serverless Is Not Automatically Cheaper
Serverless is not a guaranteed win on cost. Because you are billed for actual usage rather than cluster uptime, an inefficient or long running workload can end up costing more on serverless than it did on a classic cluster, even though you have stopped paying for idle capacity. Whether serverless nets out cheaper for a given workload comes down to a balance: the labor and operational time you save by not managing clusters, weighed against the usage cost you take on, which rises fastest for workloads that were never optimized in the first place. A workload that is inefficient on classic compute does not become efficient just because Databricks is now managing the infrastructure. Getting that balance right, workload by workload, is what the decision framework below is for.
Deciding on a specific workload?
If you are deciding whether a specific workload should move to serverless, the full decision framework covers all three phases of that decision:
- Before you move it: Which questions to answer before committing a workload to serverless. (/guides/databricks-serverless-before-stage)
- While you migrate: What to watch for as you migrate a workload over. (/guides/databricks-serverless-during-stage, slug not yet confirmed)
- After you are live: What to monitor once a workload is running on serverless. (/guides/databricks-serverless-after-stage, slug not yet confirmed)
Or see the complete framework, including all three phases, on the Databricks Serverless Compute pillar page. (/guides/databricks-serverless-compute)
How Unravel fits in
Serverless compute takes a lot of manual tuning off your plate, but it also takes away some of the visibility you had with provisioned clusters, since costs and performance now depend on decisions Databricks is making on your behalf. That makes the balance above hard to see clearly on your own. Unravel gives that visibility back: it helps you see which workloads are the best fit for serverless, what they will actually cost against the labor you save, and how they are performing once they are live.
Other Useful Links
- Our Databricks Optimization Platform
- Get a Free Databricks Health Check
- Check out other Databricks Resources