Databricks Cost Is DBU + VM (Not DBU Alone)
Post · Core differentiation · List estimates · Rates file 2026-09-24
For classic Databricks clusters, the useful company cost model is DBU platform charges plus cloud virtual machine (or equivalent) charges for every hour the nodes exist. Showing only DBU is how teams under-forecast and how many public calculators quietly diverge from the invoice.
Databricks Cost Lab exists to keep both lines visible: DBU $ and rough VM $, labeled as list-price estimates, never as guaranteed savings.
Two vendors, one workload
When you launch a Jobs or All-Purpose cluster on AWS/Azure/GCP, you typically pay:
- Databricks — DBUs × $/DBU for the SKU
- Cloud provider — instances, disks, sometimes networking and public IPs
Those appear on different bills or different lines of a consolidated invoice. Finance partners who only receive a “Databricks estimate” from a DBU-only tool will still see EC2/Azure VM/GCE charges land elsewhere. Implying the DBU number is “the cost of Databricks” is incomplete for classic compute.
Where official / most calculators fall short
Vendor pricing pages and many community spreadsheets excel at explaining $/DBU and SKU differences. They may omit or minimize the infrastructure leg, or assume you will “add cloud cost yourself” without giving a scaffold. Result: screenshots circulating in Slack show a tidy DBU monthly figure that is systematically low versus total spend.
Our stance is narrow and practical: always present two columns. Even a rough VM band (small / medium / large) beats a silent zero. The calculator loads illustrative bands from rates.json (updated 2026-09-24) so education demos are reproducible.
Example: same job, two headlines
AWS Jobs, 4 medium workers, 160 hours/month, 1.5 DBUs per node-hour, idle 0. Illustrative list: $0.15/DBU, $0.50/node-hour VM.
- Node-hours = 4 × 160 = 640
- DBUs = 640 × 1.5 = 960 → DBU $ ≈ 960 × 0.15 = ~$144
- VM $ ≈ 640 × 0.50 = ~$320
- Total rough ≈ ~$464 / month
A DBU-only slide says “about $144.” A TCO slide says “about $464 list estimate, rates as of 2026-09-24.” Neither is a contract quote; the second is harder to misuse.
Run the same inputs in /tools/cost/ and compare the KPI row. Then try the retail_orders TCO walkthrough to connect sample data → job → estimate.
When VM math changes
- Spot / preemptible — lower VM $, more failure handling
- Reserved / savings plans — lower effective VM $
- Photon / heavier instance families — different DBU ratings and VM list prices
- Serverless — infrastructure is packaged differently; do not blindly add classic EC2 bands (read current docs; still expect a bill)
- Idle interactive clusters — both DBU and VM continue until terminate/auto-stop
None of these justify hiding the infrastructure discussion. They change the numbers you type into the model.
Communication template
When you paste estimates into email or Notion, use fixed labels:
DBU $ (list estimate): … VM $ (rough band estimate): … Total rough: … Rates as of: 2026-09-24 Not contract pricing. Not a savings guarantee.
That four-line stamp prevents the most common executive misread.
What belongs in each column
DBU column: platform SKU usage × $/DBU (list or contract override). Include Jobs, All-Purpose, or SQL according to the workload — do not blend SKUs in one line without labeling.
VM column: on-demand, spot, or reserved instance cost for drivers and workers, plus attached disks if material. Use a coarse band for early planning; replace with cloud pricing calculator exports when the audience is finance-ready.
Out of scope until asked: object storage growth, Private Link, NAT egress, Delta Sharing partner costs, support plans. Mention them as exclusions so stakeholders do not assume the total is all-in.
This discipline is the differentiation versus DBU-only widgets: you train readers to expect two meters on classic compute, every time, with dates and “estimate” labels attached.