Databricks cost monitoring

Catch a job running on the wrong Databricks cluster

CostMon reads Databricks' own system.billing.usage table daily and normalizes DBU consumption by SKU and workspace, so a scheduled job left running on a pricier all-purpose cluster instead of a jobs cluster shows up in days rather than buried in next month's two separate cloud bills.

Start free See how it works

Databricks SQL warehouse usage — live today

Databricks bills in DBUs, but the DBU rate isn't one number. Jobs compute and SQL warehouses are priced well below the same size of interactive all-purpose compute, and it's easy for a scheduled pipeline to end up running on an all-purpose cluster simply because it's already on. On top of that, DBU charges from Databricks and the underlying cloud VM, storage, and network cost from AWS or GCP arrive as two separate invoices for the same workload, so normalizing what a pipeline cost means reconciling two vendors, not one, and Databricks' own billing usage table reports exact DBUs but only estimated dollars against list price.

Cost anatomy

What actually drives your Databricks bill

DBUs, priced by workload type: Databricks bills in DBUs, and the DBU rate differs materially by compute type. Jobs compute and SQL warehouses are priced well below the same size of interactive all-purpose compute.
Scheduled jobs on the wrong cluster: A scheduled or automated job pointed at an existing interactive all-purpose cluster, because it's already running, pays the higher all-purpose DBU rate for work a cheaper jobs cluster would have handled.
Two bills, one workload: On AWS and GCP classic compute, DBU charges from Databricks and the underlying EC2 or GCE instance, storage, and network cost from the cloud provider arrive as two separate invoices for the same workload.
Serverless bundles the VM cost: Serverless SQL and serverless compute fold the underlying infrastructure into a single DBU rate, with no second cloud-provider bill, which changes the math versus classic compute.
system.billing.usage is exact, dollars are estimated: Databricks' own usage tables report DBU consumption exactly; the dollar estimate derived from list price won't match a negotiated or discounted invoice, so usage, not the dollar figure, is the number to trust for anomaly detection.

Why CostMon

Built for Databricks spend, from day one

DBUs broken out by workload type

CostMon reads system.billing.usage daily, so DBU consumption breaks down by SKU (jobs, all-purpose, SQL warehouse, serverless) instead of one blended Databricks total.

Catch a job on the wrong cluster

A scheduled pipeline billing at the all-purpose rate instead of the cheaper jobs-cluster rate shows up as a per-SKU anomaly in the daily view, not buried in a monthly DBU total.

One view, next to the cloud bill it also moves

Databricks spend lands in the same normalized daily table as the AWS or GCP account underneath it, so a workload's real total cost, DBUs plus infrastructure, sits in one place instead of two invoices.

Read-only, cost-scoped credentials

CostMon connects with a token that only runs a read-only query against system.billing.usage via the Statement Execution API. It never touches your clusters, jobs, or data.

DBUsthe unit, priced differently for jobs, all-purpose, and SQL warehouse compute
2 billsDBU charges from Databricks, cloud VM charges from AWS/GCP, for one workload
Dailysync cadence, not monthly

Getting started

Connect, sync, see — for Databricks

01
Connect a read-only token and SQL warehouse
Add a Databricks personal access token or service-principal token and point CostMon at a SQL warehouse to run the query. CostMon only ever runs a read-only SELECT against system.billing.usage.
02
CostMon syncs and normalizes
Daily DBU consumption is joined against Databricks' own list-price table and rolled up by day, SKU, and workspace, then reconciled into the same normalized model as every other provider you connect.
03
See the line before the invoice does
Open a daily, SKU-level view of Databricks spend and catch a job on the wrong cluster type weeks before it lands on two separate bills.

FAQ

Common questions about the Databricks connector

How does CostMon connect to Databricks?

Through a read-only personal access token or OAuth service-principal token that runs a single SELECT-style statement against system.billing.usage via the Statement Execution API. CostMon never requests access to your clusters, jobs, or notebooks.

Are the dollar amounts CostMon shows for Databricks exact?

DBU consumption is exact, sourced directly from system.billing.usage. Dollar amounts are estimated against Databricks' list price, not your negotiated or invoiced rate. Usage is the number to trust for anomaly detection; treat dollars as directional.

Can CostMon tell me if a job is running on the wrong cluster type?

system.billing.usage records the SKU for every row, which distinguishes jobs, all-purpose, and SQL warehouse compute. CostMon surfaces that breakdown so an all-purpose SKU behind a scheduled pipeline is visible, though it doesn't move the job for you.

Does CostMon also track the cloud VM cost underneath Databricks?

On classic (non-serverless) AWS and GCP compute, the underlying VM, storage, and network cost is billed separately by the cloud provider. Connect that provider alongside Databricks to see both halves of the same workload's cost in one place.

What does the Databricks connector cost?

A flat monthly rate per plan. It's never a percentage of your Databricks spend or the savings CostMon helps you find. Free includes 2 connectors; Professional and Enterprise include unlimited connectors.

Connectors

Cloud, AI, and SaaS: all in one place

AWS, GCP, and Azure for cloud; Anthropic, OpenAI, Amazon Bedrock, Vertex AI / Gemini, and Helicone for AI and LLM spend; Snowflake and Databricks for the data cloud; Datadog, GitHub, and Vercel for the rest of the stack. Add CSV import for any tool without a native connector. That's 14 connectors, all normalized into the same unified view.

Connect a provider. See one number.

Connect your first provider and CostMon normalizes it alongside everything else you run. Your team gets one number everyone can check.

Start free See how to connect a provider