Databricks pricing explained: DBU rates, compute types and what drives your bill

How Databricks pricing works

Databricks charges for compute by the second, with no up-front cost on pay-as-you-go. Three things set the price of any workload: how many DBUs it consumes, what kind of compute consumed them, and which plan your workspace is on.

What a DBU is

A DBU is a normalized unit of processing power per hour. It is not tied to one machine size: a larger instance emits more DBUs per hour than a smaller one, so the same unit can price any cluster. Your DBU charge is simply DBUs consumed × the price per DBU for that compute type.

One bill or two

With classic compute, the clusters run on virtual machines in your own cloud account. Databricks bills you for the DBUs, and AWS, Azure or Google Cloud bills you separately for the machines, storage and network. Databricks’ own pricing pages say it in a line under each classic price: “plus underlying compute costs billed by cloud provider”.

With serverless compute, Databricks runs the machines, and the DBU price includes them. That is why serverless looks expensive per DBU and often is not: you are comparing one all-in price against half of a two-part one.

Plans: Premium and Enterprise

On AWS and Google Cloud, Databricks sells two plans, Premium and Enterprise. The Standard tier that older pricing guides list is gone: Databricks ended it on both clouds and automatically upgraded remaining Standard workspaces to Premium on 1 October 2025, as its subscription documentation describes.

Azure Databricks is sold and billed by Microsoft as a first-party Azure service, and its tiers are named differently. Databricks notes that the Premium tier on Azure corresponds to the Enterprise tier on AWS and Google Cloud.

DBU rates by compute type

The compute type is the largest single factor in the bill. These are Databricks’ list prices per DBU for AWS US East (Northern Virginia), read from its jobs, interactive and SQL pricing pages in October 2026.

Classic rows are DBU charges only; the cloud provider’s bill for the machines is extra. Serverless rows include it. Prices differ by region and cloud, and pipelines, model serving and other products have their own rates on the same pages.

Jobs compute

Jobs compute runs scheduled work with nobody at the keyboard: pipelines, batch processing, production notebooks on a timer. It is the cheapest way to buy a DBU. Anything that runs on a schedule belongs here.

All-purpose compute

All-purpose clusters are for interactive work: notebooks, development, exploration. On Premium a classic all-purpose DBU costs $0.55 against $0.15 for a jobs DBU, close to four times as much for the same processing. The most common avoidable cost in Databricks is a production job still running on the all-purpose cluster it was developed on.

SQL warehouses

SQL warehouses serve SQL queries and BI tools, and they are where reporting costs land. They come in three types. Classic and pro run in your cloud account, so you also pay for the machines. Serverless starts in seconds, stops when idle and includes the machines in its $0.70.

SQL warehouse sizes and what they cost per hour

A SQL warehouse has a size, and the size sets how many DBUs it uses for every hour it is running. Databricks’ pricing calculator lists them for serverless warehouses:

Dollar figures are DBUs × $0.70, the Premium serverless price in AWS US East in October 2026. The number to remember is the hourly one for your size, because a warehouse bills for as long as it is up, not for how many queries it answered. A Small warehouse that stays awake through a ten-hour working day costs $84 that day whether it ran four queries or four thousand.

A worked example: one month, one team

Take a team on Premium in AWS US East, paying list prices. The DBU volumes are assumptions; the prices are from the tables above.

That is $1,478.80 from Databricks, plus an AWS bill for the machines under the first two rows. Reporting is 75% of the Databricks charge, and its size was never chosen: 6 hours a day is simply how long the warehouse was kept awake.

Change one assumption. If dashboards refresh on a timer and the same warehouse is up 12 hours a day, the reporting line becomes 264 hours × 12 DBUs × $0.70 = $2,217.60, with the same data and the same readers.

What else is on the bill

Compute is most of it, but not all.

Cloud infrastructure for classic compute. The virtual machines, their disks and network traffic are billed by your cloud provider. This is the part committed-use discounts from Databricks do not touch, and the part your cloud provider’s own reservations and spot pricing do.

Storage. Your tables live in object storage in your own cloud account (S3, ADLS or Google Cloud Storage) and are billed there. Where Databricks manages storage for you, it meters it in a separate unit, the DSU (Databricks Storage Unit).

Other products. Declarative pipelines, model serving, vector search and AI features each have their own DBU rates, listed product by product on the pricing overview.

Committed use. Pay-as-you-go is the list price. Databricks offers discounts in exchange for committing to a level of usage; the size of the discount is negotiated, not published.

How to see what you are spending

Databricks records billable usage in system tables, and you can query them with SQL. Two tables answer most questions: system.billing.usage holds every billable record, and system.billing.list_prices holds the list price of each SKU over time.

System tables need a workspace enabled for Unity Catalog. Users who are both account admin and metastore admin can read them by default; anyone else needs USE CATALOG on system, plus USE SCHEMA and SELECT on the billing schema. The tables are free to use. You pay only for the compute that runs the query.

Cost by product and day

SELECT
  u.usage_date,
  u.billing_origin_product,
  SUM(u.usage_quantity) AS dbus,
  SUM(u.usage_quantity * p.pricing.default)
    AS list_cost
FROM system.billing.usage AS u
JOIN system.billing.list_prices AS p
  ON u.sku_name = p.sku_name
  AND u.cloud = p.cloud
  AND u.usage_start_time >= p.price_start_time
  AND (p.price_end_time IS NULL
    OR u.usage_start_time < p.price_end_time)
WHERE u.usage_date >=
  DATE_SUB(CURRENT_DATE(), 30)
GROUP BY u.usage_date, u.billing_origin_product
ORDER BY u.usage_date, list_cost DESC;

billing_origin_product separates JOBS, SQL, ALL_PURPOSE and the rest. The cost here is at list price; if you have a committed-use discount, your invoice will be lower by that discount.

Which SQL warehouse is the bill

SELECT
  usage_metadata.warehouse_id AS warehouse_id,
  SUM(usage_quantity) AS dbus
FROM system.billing.usage
WHERE billing_origin_product = 'SQL'
  AND usage_date >=
    DATE_SUB(CURRENT_DATE(), 30)
GROUP BY usage_metadata.warehouse_id
ORDER BY dbus DESC;

The most expensive jobs

SELECT
  usage_metadata.job_id AS job_id,
  SUM(usage_quantity) AS dbus
FROM system.billing.usage
WHERE usage_metadata.job_id IS NOT NULL
  AND usage_date >=
    DATE_SUB(CURRENT_DATE(), 30)
GROUP BY usage_metadata.job_id
ORDER BY dbus DESC
LIMIT 20;

A job that appears here under ALL_PURPOSE rather than JOBS is the mismatch from the rates table: the same work at close to four times the DBU price.

Spend by team

SELECT
  custom_tags['team'] AS team,
  SUM(usage_quantity) AS dbus
FROM system.billing.usage
WHERE usage_date >=
  DATE_SUB(CURRENT_DATE(), 30)
GROUP BY custom_tags['team']
ORDER BY dbus DESC;

This one only works if clusters and warehouses are tagged. custom_tags carries whatever tags you put on the compute, so a team tag has to exist before the usage does. Untagged usage comes back as one large NULL row, which is itself a finding.

What drives a Databricks bill up

Rates are fixed. What moves is how much compute runs, on what, and for how long. Five causes account for most surprises.

• Compute left running. An interactive cluster or a classic SQL warehouse that nobody stopped bills DBUs, and machines, through the night and the weekend.
• The wrong compute type. Production pipelines on all-purpose clusters pay $0.55 per DBU for work that costs $0.15 on jobs compute.
• Oversized clusters and warehouses. Sized for the busiest hour of the quarter and never revisited. Each size up on a SQL warehouse uses 1.5 to 2 times the DBUs per hour.
• Queries that scan everything. No partition filter, SELECT * on wide tables, the same heavy join recomputed by every dashboard. Longer queries keep compute up longer.
• No owner. Without tags and a report that somebody reads, the bill belongs to nobody and nothing changes.

How to bring it down

Each cause has a direct fix, and the first two usually pay for the rest.

Stop compute that is idle. Set auto-termination on interactive clusters and auto stop on SQL warehouses. This is the cheapest change on the list and it applies from the next idle minute.

Move scheduled work to jobs compute. If it runs on a timer, it does not need an interactive cluster. The third query above tells you which jobs to move first.

Start small and size up on evidence. A SQL warehouse can be resized in place. Begin a size below where you think you need to be and raise it only if queries queue.

Prefer serverless for bursty SQL. Reporting and ad hoc analysis arrive in bursts with long gaps between them. A warehouse that starts in seconds and stops when idle fits that shape; a classic warehouse kept warm all day does not.

Tag everything, then publish the report. Tags turn the fourth query into a table of spend by team. It only changes behaviour if the people who own the spend see it, on a schedule, without asking for it.

Databricks pricing compared with Snowflake and BigQuery

The three platforms measure different things, so a price-per-unit comparison says little. What differs is the shape of the bill.

Databricks prices a DBU by compute type and, for classic compute, leaves the machines on your cloud bill. You have the most control over the infrastructure and the most to manage. Snowflake prices a credit by edition and region, with the machines always included; Snowflake pricing walks through its rates the same way this guide does. BigQuery charges either for the data each query scans or for reserved capacity, with no cluster to size at all.

In all three, the part of the bill that grows without anyone deciding it is the same: queries that people and dashboards send all day. The data warehouse comparison covers the architectural differences, and what Databricks is explains the lakehouse design behind the pricing.

One definition, many readers

The reporting line in the worked example is the one to fix by design, not by tuning. Its cost is set by how long a SQL warehouse is awake, and that is set by how many tools and people query it, and when.

OWOX Data Marts does not change what a DBU costs and does not transform your data. It gives each reporting query one definition, one schedule and one record of every run. You connect Databricks as a storage with a host, a personal access token and the HTTP path of a SQL warehouse, so every run goes to a warehouse you chose. The setup guide recommends the same three settings as the section above: auto stop on, start small, serverless where available.

A Data Mart is a SQL query, a table or a view that an analyst publishes under a business name. Reports are built on it and delivered to Google Sheets, Data Studio, Slack or email, on triggers you set.

That is where the arithmetic changes. A report delivered to Google Sheets at 09:00 is one run a day: the warehouse starts, answers and stops. The people who open the sheet afterwards are reading a spreadsheet. The warehouse hours behind that report are a number you can write down in advance, and Run History shows each one.

The spend report itself can be delivered the same way. If the identity behind the storage connection has SELECT on system.billing, the first query in this guide can be published as a Data Mart like any other and sent to finance every Monday. Databricks to Google Sheets is the walk-through for setting up the destination.

DatabricksWhat is Databricks and how does it work?October 1, 2026→DatabricksHow to connect Databricks to Google Sheets, without CSV exportsOctober 1, 2026→DatabricksHow to connect TikTok Ads to Databricks, step by stepOctober 1, 2026→

See all articles →