Databricks Pricing: DBU Rates and Costs (2026 Guide)

You will not find a monthly plan price for Databricks.

Databricks Pricing Is Per DBU, Not Per Plan

You pay a per-DBU rate that depends on the compute product, from $0.10 to $0.75 on AWS Premium, checked October 2026 against the Databricks pricing page, which means your product choice significantly affects your DBU costs.

What a DBU is and how it is metered

Per second, while compute is running: that is how Databricks meters a DBU (Databricks Unit), a unit of processing capability. Multiply the DBUs consumed by that product's rate and you have your bill.

Whether a run starts on a schedule or Activepieces triggers it, the rate stays whatever the compute product sets, $0.10 to $0.75 on AWS Premium, so the trigger method won't reduce your hourly cost.

The rate on the page is therefore only half the sum; how many DBUs a job burns is the other half.

Databricks DBU Rates by Compute Type

Seven and a half times: that is how much more the same DBU costs on one product than another, and that spread is the point. The table lists the five AWS Premium rates confirmed by DBU Watch.

Compute product	Rate per DBU (AWS Premium)	Inclusions	Limits	Discounts
Jobs Light	$0.10	Databricks software only; AWS instances billed separately	Meant for simple scheduled jobs	Committed-use contract
SQL classic	$0.22	Databricks software only; AWS instances billed separately	You manage cluster sizing	Committed-use contract
Jobs Serverless	$0.35	Underlying compute bundled into the rate	Higher rate per DBU	Committed-use contract
SQL Serverless	$0.70	Underlying compute bundled into the rate	Higher rate per DBU	Committed-use contract
Interactive Serverless	$0.75	Underlying compute bundled into the rate	Highest rate listed here	Committed-use contract

Prices and plan limits checked against community.databricks.com on October 31, 2026.

Read the inclusions column before the rate column. Jobs Light at $0.10 excludes the EC2 bill, while Jobs Serverless at $0.35 folds it in, so the cheaper rate isn't automatically the cheaper job.

Before signing anything, you can measure your own DBU consumption on the free edition or the trial. Databricks publishes no percentage for committed-use discounts, so you negotiate the figure in a contract.

That makes a measured baseline the only thing that gives you leverage in that conversation.

A Monthly Bill Worked Out for One Workload

About $253 a month: that is what a nightly ETL job on classic Jobs compute comes to, and roughly two-thirds of it goes to the cloud VM, not to Databricks, so Databricks costs roughly one-third or about $84 a month. Cloud infrastructure's the cost driver.

I assume 8 nodes running 3 hours a night for 30 nights, which is 720 node-hours a month, which is the basis for the cost calculations below, meaning your costs are proportional to your actual node-hours.

The list below shows the order of the calculation, and its result's what you compare against a serverless quote.

1. Cluster size × hours per night × nights = 720 node-hours, so you can plug in your own values to calculate the node-hours for your workload.
2. Node-hours × the Jobs DBU rate = the Databricks charge.
3. Node-hours × the EC2 hourly price = the VM charge, so the VM cost is calculated by simply multiplying these two numbers.
4. Add storage, which the cloud bills on your data volume.
5. Total, then compare with the serverless quote for the same job.

The next two sections work through steps 2 and 3.

DBU charges line by line

At $0.114 per node-hour, per Datapace, the Databricks DBU charge across 720 node-hours is $82.08 a month, or about $985 a year, which is separate from what you pay for cloud infrastructure, making it essential to account for this line item when projecting total costs.

From 6% at 25k DBCU through 11% at 100k, 14% at 200k, 20% at 500k, 27% at 1M and 33% at 2M: those are the commitment discounts, per Acrovision.

At $985 a year this job's far below the lowest tier, so on its own it earns no discount. The discounts only matter once many jobs share one commitment.

Cloud Infrastructure Costs on Top of DBUs

$0.2373 per node-hour is what the EC2 instance costs, so 720 node-hours cost $170.86. That's about 68% of the $0.3513 combined node-hour. A DBU discount therefore trims only the smaller part of the bill.

Take a 33% discount on $82.08: it saves $27, around 11% of the $252.94 total. Storage's the same under either model, so I leave it out of the comparison. Add your own figure to both totals.

Classic vs Serverless Databricks Total Cost

Add $82.08 and $170.86 and classic comes to $252.94 a month, before storage. Serverless folds the VM into its DBU rate, so the comparison's one multiplication: your quoted serverless rate times the DBUs the job consumes, set against $252.94.

If the quote comes in lower, you're paying less for the same job. If it comes in higher, the premium is what you pay to stop managing clusters.

Clusters that sit idle between runs shift the answer toward serverless, and a tuned 3-hour run shifts it toward classic.

Hidden Costs and Limits That Change the Bill

Whichever way the compute-type question falls, the per-DBU rate covers only part of what you pay, and other units on other invoices cover the rest.

A DBU is the unit Databricks meters for processing; the VM hours, gigabytes moved, gigabytes stored and support percentage around it come on separate bills.

Below, the chart sorts those omissions by where they show up:

• The Databricks invoice
• The cloud provider's invoice
• Neither until you hit a wall

Read it as a checklist of line items to estimate before you compare any two list prices. A line you leave out of one vendor's quote but keep in another's makes the comparison meaningless.

(chart placement)

Cloud charges billed outside Databricks

On classic compute, the DBU rate pays for the Databricks software only. Your cloud provider bills the virtual machines that run your cluster, per instance-hour, on a separate invoice.

So the Databricks line can look modest while the VM line beside it is as large or larger, and anyone who reads only the rate card sees a fraction of the total.

Move on to storage and network and the pattern repeats. Your data sits in your own cloud storage account, billed by the gigabyte stored and by requests.

If data leaves a region or a cloud, to a BI tool or another team's account, the provider bills egress per gigabyte. If your pipeline reads across regions, that transfer cost recurs on every run.

On serverless, one bill replaces two, because the VM cost is folded into the DBU price. It doesn't remove your storage or egress charges.

Idle compute and autoscaling surprises

Metered for as long as they're running, not for as long as they're working: that is how classic clusters bill. A cluster waiting for the next job, or held open by an interactive notebook someone forgot, accrues both DBUs and VM hours.

Metered for as long as they're running, not for as long as they're working: that is how classic clusters bill.

You can cap that waste with auto-termination, but only if it's set, and a short setting trades savings for slower restarts.

Then there is autoscaling, a second variable. A cluster that scales up for one heavy stage and scales down slowly keeps paying for workers it no longer needs. Many tiny jobs hit a minimum far more often than a few long ones.

When work stops, serverless stops billing, but it can carry its own minimums and startup behavior, so check the documented floor for each serverless product against how short your jobs are.

Features and limits that depend on tier or compute type

Not every feature is available on every plan or compute type. Some governance, security and networking capabilities are gated to higher tiers, and some features run only on serverless or only on classic.

If a requirement such as network isolation or fine-grained access control is mandatory for you, price the tier that includes it, not the cheapest one.

Budget for support too, since paid support plans are typically a share of spend or a set fee, so they scale with your bill.

Finally, quotas and concurrency limits cap how many clusters, jobs or SQL queries run at once. Hitting one doesn't raise the bill; it queues your work or forces a quota request.

That delay is a cost your estimate should include before you commit to a term.

DBU pricing's case and alternatives

Pay for metered work rather than a seat or a plan, and a quiet month costs less: that is the honest defense of DBU pricing. Your estimate should price the delay from quotas and queues rather than assume it away.

The strongest argument for DBU pricing

You never pay for capacity you didn't run under usage billing, and that's a real advantage over a flat tier. Serverless compute narrows the usual complaint, because the cloud machines are folded into the per-DBU rate and you stop reconciling two invoices.

For teams with steady demand, committed-use discounts then lower the rate.

Taken together, the claim's that you pay for metered work rather than a seat or a plan, so a quiet month costs less. Your estimate should price the delay from quotas and queues rather than assume it away.

Why Databricks Rate Cards Understate the Bill

What the rate card prices is one DBU, but your bill's DBUs multiplied by hours, plus whatever sits outside that rate.

On classic compute, your cloud provider bills virtual machines, storage and network, so the Databricks invoice's only part of the total. A cluster left running idle keeps accruing both charges.

The split goes away on serverless, but the multiplication does not: you still pay for every hour a job runs, at a rate that reflects the bundled infrastructure.

A discount also cuts the rate only if you commit to a volume, and a commitment you under-use is a cost you pay without receiving work.

To test it fairly, price your own job hours, idle time and commitment, and don't compare the headline rate.

Databricks, Snowflake and BigQuery side by side

Before you compare any rates, note which charge lands on you. The table shows all three bill by usage, but each meters a different unit and assigns infrastructure and idle cost differently.

	Pricing unit	Who pays infrastructure	Idle billing	Entry cost	Commitments
Databricks	DBUs per hour, by compute type	You on classic compute; bundled on serverless	Classic clusters bill until stopped; serverless stops billing when work ends	Pay as you go, no required minimum	Committed-use contracts lower the DBU rate
Snowflake	Credits per hour, by warehouse size	Bundled into the credit price	Running warehouses bill until they suspend	Pay as you go, no required minimum	Capacity purchases lower the credit price
BigQuery	Data scanned, or reserved slots	Bundled into the price	On-demand queries leave nothing idle; reserved slots bill whether used or not	Pay as you go, no required minimum	Slot commitments lower reserved capacity cost

Because the units differ, a comparison of list rates isn't a comparison of bills. Price the same workload in each unit first, then add the idle hours and commitment terms.

Triggering Databricks Jobs and Spend Alerts with Activepieces

If all you need's a price comparison, you can skip this section. Activepieces, whose core is MIT-licensed and whose Free plan costs $0, doesn't lower your Databricks bill; it only decides when a job starts and who hears about the spend.

That narrow role still matters, because the cost drivers above (compute type, idle hours, commitment terms) are often set by how jobs get launched.

Kick a job off by hand, or by a schedule nobody revisits, and it tends to run whether or not anyone needs the result.

A job started by a real business event runs when there's work to do, which makes your DBU count easier to predict and easier to tie to a cause.

That flow, which counts as 1 credit per run however many steps it holds, calls a Databricks job and also sends a budget alert to Slack and email.

The thing to take from it's that the triggers sit upstream of Databricks and the alerts sit downstream, so the flow touches your spend only at those two points.

Triggering a Databricks Job from a Business Event

Think of Activepieces as an automation tool with 746 integrations that connects apps through flows: a trigger fires, and steps run after it, giving you built-in support across most platforms.

Here the trigger can be a submitted form, a changed record in your CRM (the system where sales contacts and deals are kept), or an incoming webhook from another service.

The next step calls Databricks and runs a job you have already defined there.

For pricing, the consequence is that the job's compute's still whatever you configured in Databricks. If the job runs on a cluster you sized for something larger, the flow will faithfully start that larger cluster each time.

Define the job on the compute type you priced in the previous section, then let the event decide when it runs.

Activepieces meters its own usage separately from your DBUs, and the unit is simple: a run costs 1 credit however many steps it has, and the Free plan includes 1,000 credits a month.

Its pricing page lists "unlimited flows" on Free, Plus, Team and Ultimate alike, whereas Zapier's pricing bills a task per action and Make's a credit per module, so one flow per event type adds nothing to the bill beyond the runs themselves.

MoneyGram, Moneypenny, Alan and FundingSocieties run Activepieces in production.

Sending Databricks Spend Alerts to Slack and Email

End the same flow with a message to Slack, the team chat, and an email. Use it to report that a job started, or to carry a spend warning when a threshold you defined is crossed.

The flow only relays the message. It doesn't measure cost, so the threshold, say the $252.94 monthly classic total worked out above, has to come from Databricks or your cloud billing, and a flow that relays nothing's a silent failure.

How to Estimate Databricks Pricing Before You Commit

Price one real job end to end, in this order, and only then compare rate cards:

1. Estimate DBU hours: the Databricks Units a job consumes per hour, multiplied by how long it runs and how often.
2. Price those hours with rates you have verified for your cloud, region and compute type.
3. Set budget policies and auto-termination so idle clusters stop billing.
4. Run the same job on serverless and on classic compute, and compare the bills.
5. Request committed-use quotes against the baseline you now have.

Measure Databricks Cost on One Real Job

Pick a production pipeline, not a demo notebook. Record cluster size, runtime and run frequency, then multiply by the DBU rate for that compute type. Add the cloud provider's virtual machine and storage charges on classic compute, because Databricks bills those separately from DBUs.

Price a job this way and you get a unit cost you can scale to the whole workload. A list rate gives you nothing to scale.

Cap idle compute

Since you pay for compute that does no work, idle time's the cheapest saving to capture. Set auto-termination on every interactive cluster, and attach budget policies so spend is tagged and capped by team. Then run the same job on serverless and on classic.

On short, bursty jobs serverless tends to win, since it bundles infrastructure into the DBU rate and starts quickly. Classic with tuned sizing can win on long, steady ones. Only your own comparison settles which applies to you.

Negotiate after you have a baseline

Commitment discounts reward predictability.

With steady workloads you can commit with confidence. Bursty ones risk paying for capacity that sits unused, which erases the discount.

Ask for quotes at your measured baseline, then again at a lower level, and compare what each leaves you exposed to if usage dips.

Ask what happens to unused commitment at term end, and whether it rolls over. With your unit cost, idle policy and serverless result in hand, you can judge a quote against numbers you trust.

Frequently asked questions

Is there a free version of Databricks? Yes, Databricks has a free edition aimed at learning and prototyping.

Its compute is restricted, so treat it as a place to test notebooks and queries, not as a way to run a production workload for nothing. Once you need larger compute or production support, you move onto metered DBU billing.

Do I pay Databricks and my cloud provider separately? On classic compute, yes. Databricks bills the DBUs, and your cloud provider bills the virtual machines, storage and network traffic underneath.

That means the DBU rate's only one line of the total. Serverless compute folds the infrastructure into the DBU rate, so you get one invoice but a higher per-DBU price.

Does Databricks charge when a cluster is idle? On classic compute, a running cluster is billed whether or not a query is executing, for both the DBUs and the cloud machines.

An idle cluster left on is therefore a cost you chose, and an auto-termination setting's the cheapest fix. Serverless and auto-stopping SQL warehouses shift that risk, because billing follows use rather than uptime.

Can I get a discount on Databricks pricing?

Yes, through commitment contracts. You agree to a spend level over a set term, and Databricks lowers your DBU rate in return.

The size of the discount depends on how much you commit and for how long, so quote the same workload at several commitment levels before you sign.

If you buy through a cloud marketplace, the spend may also count toward a commitment you already hold with your cloud provider.

Put three questions the body leaves open to Databricks sales directly:

• the exact discount at each commitment level and term
• how Databricks Apps are metered and priced
• what consulting and onboarding help costs

Is Databricks more expensive than Snowflake? It depends on the workload, and the two aren't metered in the same unit.

Databricks charges DBUs plus cloud infrastructure on classic compute, while Snowflake charges its own credits. A list-price comparison therefore says little.

Price one real workload on both platforms, with the same data volume, run frequency and commitment terms, and compare the monthly totals.

Related reading

• Snowflake Pricing Explained for 2026 Data Teams

References

• DBU Watch
• Datapace
• Acrovision