Airbrx / Databricks CDN / Warehouse costs

Why Databricks SQL warehouse costs climb, and how to find your own number

Does an idle Databricks SQL warehouse cost money? Yes: it bills DBUs for every minute it is running, busy or not, until Auto Stop shuts it down. So the question that decides the bill is not how hard your queries are. It is how often something asks.

Cost calculator: one dashboard, one daymove the sliders
Straight to Databricks 9 h 46 min awake · 73 queries
Through the Airbrx Gateway 20 min awake · 2 queries
Per working month, direct$3,610
Through the gateway$123
Back in your budget$3,48797%

Illustrative: one dashboard on its own serverless warehouse, 07:00 to 19:00, 22 working days. Sizes are Databricks' serverless DBU rates;3 $0.70 is a commonly quoted AWS US list price, so put in yours. Pro and classic also bill cloud instances. Measure your real one

How the bill is made

How a Databricks SQL warehouse bills: three numbers, one out of control.

Databricks charges a SQL warehouse in DBUs for every hour it runs, at a rate set by its size, and a warehouse that is running but idle keeps accruing until it stops.1

Hours awake

Set by how often anything asks, plus the Auto Stop tail after the last ask. Nobody owns this number, and every dashboard, workbook and agent adds to it.

DBUs per hour

Set by warehouse size: 4 an hour for 2X-Small, 24 for Medium, 144 for 2X-Large on serverless.3 You chose it once.

Price per DBU

Set by Databricks SQL pricing for your cloud, region and tier, less whatever your contract discounts. Negotiated once a year.

What ends the hours: Auto Stop

Auto Stop is the number of idle minutes before the warehouse shuts down.1 Idle means nothing arrived, not nothing new arrived.

Warehouse typeDefault Auto StopLowest setting
Serverless10 minutes5 minutes in the UI, 1 minute through the API
Pro and classic45 minutes10 minutes

The refresh loop

Why Auto Stop never fires: something asks more often than it waits.

It does not matter whether the query is new, whether Databricks' query result cache answered it, or whether the data under it changed since breakfast. Each arrival resets the clock.

  1. One report

    A Power BI report in DirectQuery refreshes a tile every 15 minutes from 07:00 to 19:00, on a pro warehouse at its default 45-minute Auto Stop.

  2. 49 refreshes, 2 new answers

    The data lands overnight and once at lunch. Two refreshes follow a load. The other 47 ask a question whose answer has not changed.

  3. 12 hours 45 minutes awake

    The warehouse starts at 07:00 and cannot stop until 45 minutes after the last refresh. Every one of those 47 repeats kept the meter running.

Now multiply by every Tableau and Power BI dashboard, every Excel workbook on a refresh timer, every dbt test suite and every agent that polls. Most of them ask for things that were settled hours ago.

The usual fixes

How to reduce Databricks SQL warehouse costs: each fix moves one number.

These are the usual ways to reduce SQL warehouse cost, and all are worth doing where they fit. Look at which term of the bill each one actually moves, and what it trades for it.

moves: the Auto Stop tail

Lower Auto Stop

Trims the idle time after the last query.

Does nothing while queries keep arriving: the clock still resets. More cold starts when they stop.

moves: DBUs per hour

Smaller warehouse

Lowers the rate per hour.

Slower dashboards and queueing at peak, and the same hours awake.

moves: how often it asks

Refresh less often

Fewer arrivals.

Staler numbers, and a conversation with every dashboard owner.

moves: interactive load

Tableau extracts or Power BI Import

Takes interactive queries off Databricks.

A copy of the data outside Databricks, with its own governance and its own refresh to run.

moves: work per query

Materialized views

Cheaper queries.

Still needs a running warehouse to read them, so the hours stay.

moves: hours awake

Airbrx Gateway

Repeats are answered before Databricks sees them, so they never reset Auto Stop.

Nothing on freshness: rules follow your loads, the writes that change a table, or a marker your pipeline sends. How the Airbrx Gateway works

None of the first five stops a repeat question from reaching the warehouse. In the report above, the gateway wakes it for the first refresh after each load instead of all 49. Why Databricks' own caches cannot do this is on result cache vs CDN; questions about rules, freshness and security are in the Databricks CDN FAQ.

Quick answers

Databricks SQL warehouse cost questions

Does an idle Databricks SQL warehouse cost money?

Yes. A running SQL warehouse bills DBUs for every hour it runs, at the rate for its size, whether or not it is executing anything, until Auto Stop shuts it down.1 Pro and classic warehouses also bill the cloud instances underneath.

What is the default Auto Stop for a Databricks SQL warehouse?

Ten minutes for serverless and 45 minutes for pro and classic. Serverless can go down to 5 minutes in the UI or 1 minute through the API; pro and classic can go down to 10.1

Does the Databricks result cache lower SQL warehouse cost?

It saves the work of re-running a repeat query, but a result cache hit still needs a running warehouse, so it does not shorten the hours the warehouse is awake, and hours awake are what you pay for. Result cache vs CDN goes through each of Databricks' caches.

How do I see what my Databricks SQL warehouse costs?

system.billing.usage gives DBUs per warehouse per day, and system.query.history shows who is asking and how often they repeat the same statement. Both queries are below.

Your own number

Measure your own SQL warehouse cost and repeat queries

Two read-only queries get you most of the picture. First, what each warehouse consumed per day over the last 30 days:

SELECT
  usage_metadata.warehouse_id  AS warehouse_id,
  usage_date,
  SUM(usage_quantity)          AS dbus
FROM system.billing.usage
WHERE usage_metadata.warehouse_id IS NOT NULL
  AND usage_date >= current_date() - INTERVAL 30 DAYS
GROUP BY ALL
ORDER BY usage_date, warehouse_id;

Then, what is asking, and how often it asks the same thing, from system.query.history:2

SELECT
  compute.warehouse_id                  AS warehouse_id,
  executed_by,
  COUNT(*)                              AS statements,
  COUNT(DISTINCT statement_text)        AS distinct_statements,
  ROUND(1 - COUNT(DISTINCT statement_text) / COUNT(*), 3) AS repeat_share
FROM system.query.history
WHERE compute.type = 'WAREHOUSE'
  AND statement_type = 'SELECT'
  AND start_time >= current_timestamp() - INTERVAL 30 DAYS
GROUP BY ALL
ORDER BY statements DESC
LIMIT 50;

A service account with thousands of statements, a handful of distinct texts and a warehouse that never reaches zero DBUs in a day is the pattern to look for. The system tables have to be enabled, and both are read by an admin or someone they grant.

Or let the scan do it. The Airbrx scan runs one read-only query over your query history, standardizes the SQL so near-identical statements count as repeats, and gives you a dollar figure and the rules that would capture it. Use a short-lived token; it is never stored. Scan my Databricks query history

Sources
  1. Databricks documentation, SQL warehouse settings, Auto Stop.
  2. Databricks documentation, Query history system table reference.
  3. Databricks documentation, Serverless DBU consumption by SKU.

Free forever

Put the dashboard that keeps your warehouse awake behind it today.

Sign in with Google or Microsoft, get your own gateway hostname, point one Databricks connection at it. No card, no sales call, no trial clock. Usage caps may apply.