Rates last reviewed: June 2025.
How Databricks Pricing Works
Databricks pricing is built around Databricks Units (DBUs), which represent abstract compute consumption across jobs, interactive clusters, and SQL warehouses. Storage (object storage) is billed separately by the cloud provider (S3/GCS/ADLS). This guide explains DBUs, common cluster shapes, and cost drivers to watch.
What is a DBU?
A DBU is a unit of processing capability used to meter Databricks compute. Different workloads and cluster types consume DBUs at different rates (Jobs compute, All-Purpose, SQL endpoints). The vendor lists DBU prices per hour; typical public examples use jobs DBU rates around $0.10–$0.15/DBU, but actual prices vary by cloud and contract.
Cluster sizes and compute
Databricks clusters are sized by instance type and number of nodes. A cluster’s DBU/hr is computed from the instance types it uses and Databricks’ published DBU rates. Key differences from Snowflake:
- Instance variety: You choose the exact VM or instance family (e.g., AWS m5, r5), which affects raw cost and performance.
- Node count: Cost scales with node count; auto-scaling can add or remove nodes based on workload.
- Runtime types: Jobs compute and interactive clusters have different DBU profiles.
Storage costs
Storage for Databricks is the cloud provider object storage (S3/GCS/ADLS). Typical list prices model storage at around $0.023/GB-month on AWS, but your cloud bill reflects the provider’s storage rates and any committed discounts.
Unity Catalog and metadata overhead
Unity Catalog adds governance, data discovery, and fine-grained access controls. It also introduces additional metadata and compute overhead, especially for large catalog operations and frequent table scans. Many teams underestimate this cost when they migrate to Unity Catalog, so account for both the DBU usage and the additional catalog management activity.
Databricks hidden costs: SQL Warehouse, serverless, and Unity Catalog
1. Large autoscaling clusters
Auto-scaling helps performance but if configured with high max nodes, transient spikes can scale to expensive cluster sizes. Limit max nodes and use conservative scaling policies.
2. Long-lived interactive clusters
Keeping interactive clusters running for convenience consumes DBUs continuously. Use short-lived clusters for notebooks and schedule interactive time windows.
3. Inefficient Spark jobs
Poorly tuned Spark jobs (wide shuffles, inadequate partitioning) can consume orders of magnitude more DBUs. Profile and optimize Spark jobs, use data skipping and caching where helpful.
4. High-frequency small jobs
Many small jobs starting clusters repeatedly incur startup overhead. Batch small tasks, reuse clusters for multiple jobs, or use higher-concurrency job clusters.
Practical tips to control Databricks spend
- Use cluster policies and autoscaler limits to restrict growth.
- Prefer spot/preemptible instances for non-critical workloads to reduce cloud compute cost.
- Monitor DBU consumption and set budget alerts with cloud cost tools.
- Consolidate small jobs where possible or use job clusters to amortize startup cost.
- Right-size instance types for memory vs CPU needs to avoid wasted vCPU hours.
Example: quick cost snapshot
Illustrative: a small jobs cluster that consumes 4 DBUs/hr at $0.12/DBU running 8 hours/day for 22 days:
4 DBU/hr × 8 hr/day × 22 days × $0.12/DBU = $844.80 / month (compute)
Storage (5 TB at $0.023/GB-month): ~ $117.50 / month. Total (example): ≈ $962.30 / month.
Estimate your own Databricks bill
Use real job runtimes, average node counts, SQL Warehouse usage, and storage to estimate your costs accurately.
Estimate your Databricks bill with SQL Warehouse and DBU usage
Note: DBU prices and storage rates vary by cloud provider, region, and contract. Always verify prices in your Databricks account and cloud bills.
Compare platforms
Read the other guides to compare compute, storage, and real-world cost behavior: