The CDN for Databricks SQL
Stop paying Databricks to answer the same query twice.
Dashboards, scheduled refreshes and AI agents ask your SQL warehouse the same questions all day, and it stays awake billing DBUs to re-answer them. The Airbrx Gateway sits in front of it like a CDN: repeats come back from cache, and the warehouse only wakes up for new questions.
- A smaller DBU bill. A cached answer never wakes the warehouse, so Auto Stop finally gets to fire.
- Faster dashboards. Repeats come back in milliseconds, however many people open the report.
- Nothing to migrate. Change one hostname. Same driver, token, SQL and Unity Catalog grants.
Free foreverNo cardLive in about five minutesUsage caps may apply
Server hostname, in the tool you already use
becomes
- Same HTTP path
- Same token
- Same driver
- Same SQL
Run your own numbers
Asking got almost free. Answering didn't.
Scheduled refreshes, a room full of people on Monday morning, and now agents that come in crowds and double-check. Nothing changed all morning, and the warehouse stayed awake to answer the same thing again. Set up a day that looks like yours and see what stays on the bill.
96% of questions answered at the gateway 198 warehouse hours a month it gets to sleep
Illustrative model, not a measured customer result: one serverless warehouse, 07:00 to 19:00, 22 working days. Agents draw from 20 recurring questions and ask each one twice. A question reaches the warehouse the first time it is asked after each data load; repeats are answered at the gateway. $0.70 is a commonly quoted AWS US list price, so put in yours. Get your real number from your query history or follow a single dashboard.
Why this is missing
Every layer got an edge. Except data.
Web pages got CDNs, APIs got gateways, DNS got managed resolvers. Your Databricks SQL warehouse still takes every query raw, and now AI agents are the ones asking. Databricks CDN is that missing edge.
- Web pages and apps CDN, managed
- REST and GraphQL APIs API gateway, managed
- DNS Managed resolvers
- SQL to your warehouse Straight in, unchecked
What it does
Every query, matched to a rule.
The gateway reads each statement before Databricks sees it and decides what reaches the warehouse, and which one. Until you write a rule, everything passes through and is only logged. Watch the rules run
Answered from cache
A repeat. Back in milliseconds, and the warehouse stays asleep. It stays cached until its rule's clock runs out or a write you named expires it.
Blocked by policy
Refused as a native Databricks error that names the rule, before the warehouse wakes. The runaway agent loop, the 3 a.m. full scan.
Routed by rule
Sent to the warehouse its rule names: agents on a small one, finance on its own. Each query is logged with the warehouse and cost center it ran on.
Passed through
A new question. Goes straight to your warehouse with the caller's own token, and Unity Catalog decides, as it does today.
Where the DBUs go
Your SQL warehouse bills for being awake, not for being useful.
Databricks bills a SQL warehouse for the time it runs, and an idle warehouse keeps accruing DBUs until Auto Stop shuts it down. The default timer is 10 minutes on serverless and 45 minutes on pro and classic.1 So a dashboard that refreshes every 15 minutes, plus the people opening it, keeps the warehouse up most of the working day, even when the data under it changed twice. Work out what your own warehouse costs
Why it gets worse from here
Asking got almost free. Answering didn't.
Scheduled refreshes, forty people opening the same dashboard on Monday morning, and now agents that come in crowds and double-check. Nothing changed all morning, and the same answer was billed every time. Nobody reviews SQL an agent writes, and the next one is worded differently.
We asked Claude to build us an internal tool, put our own gateway in front of its database, and watched what it asked for a week.
- 1.3Mqueries in one day, from one person. Not in production.
- 99.92%the same query, the same values, the same answer.
- 161,360runs of one lookup, for three users.
- ~15/sall day long. On a SQL warehouse, Auto Stop never fires.
Measured on Postgres, where it cost $1.51 a day: flat, so nobody noticed. Pointed at a warehouse that never gets to sleep, the same traffic is a different conversation. Read the measurement →
What teams do today
Reducing Databricks SQL costs: the usual fixes are projects, not layers.
Each one helps one report. None of them sits in front of every query. What each fix moves on the bill
Import mode and extracts
✓ The report it was built for.
✗ Everything else. Each extract is a data island on its own refresh schedule, and the refresh still wakes the warehouse.
Materialized views
✓ The queries you predicted.
✗ The ones you didn't, and every agent's. Each one is a pipeline to own.
A bigger warehouse
✓ Queueing, for now.
✗ The bill, which grows with it. More clusters answering the same question faster.
A cache you can't trust is a bug with a TTL on it.
Built-in caching, and its edges
The Databricks result cache already helps. Here is where it stops.
The query result cache is real and you should keep it. It just lives inside the warehouse, so it cannot help with the cost of the warehouse being on.
| Databricks query result cache | Databricks CDN | |
|---|---|---|
| Serving a hit needs a running warehouse | Yes. Even the remote result cache requires a running warehouse.2 | No. A hit is answered at the gateway. The warehouse stays asleep. |
| How long a result lives | Up to 24 hours.2 | As long as your rule says: a TTL, your load schedule, or until a pipeline says otherwise. |
| What throws a result away | Any update to an underlying table.2 | Only the writes and markers your rules name. Unrelated rows landing do not bust settled answers. |
| Who it covers | Queries on that workspace's warehouses. | Every tool you point at the gateway address, with a record of each statement. |
AI/BI dashboards have their own cache that does not start the warehouse, but it covers those dashboards only.3 Tableau, Power BI, Excel, dbt and agents go to the warehouse. The full comparison
Nobody is watching
Today, you find out from the bill.
Nothing sits between the asker and the warehouse, so the first sign of a runaway dashboard or a looping agent is the DBU line on next month's invoice. Put something in front, and you see it Friday, in the first hour.
Point your own assistant at the gateway's logs over MCP and ask what changed. It reads from a separate endpoint on separate compute, never touches the live query path, and never touches your warehouse.
What the gateway sees
- Every statement an agent runs, in the same log as your BI tools.
- Which client, which user, which rule, hit or miss.
- Repeats land on the cache instead of the meter.
- "What has AI been asking our data?" becomes a query, not a project.
What does not change
Unity Catalog, row filters and grants keep working.
The gateway speaks Databricks' own protocol, so to your driver it looks like the warehouse. That is why there is nothing to install and nothing to migrate. Unity Catalog, row filters and masks in the FAQ
Unity Catalog grants
Your caller's own token passes through to Databricks. The gateway holds no warehouse credentials of its own, so permissions are decided where they are today.
Row filters and column masks
Key cached results per user. Each person gets answers Databricks computed under their own row filters and masks, and nobody is served someone else's rows.
Your drivers and tools
Thrift over HTTP and the JSON statement API, the same paths the Databricks ODBC, JDBC and Python connectors use. Change the server field and keep going.
Your HTTP path
Keep pointing at the warehouse you use now, or pin every query to one. Each connection keeps choosing its warehouse unless you say otherwise.
Your audit trail
Every query that reaches Databricks still lands in its query history. Cached answers are recorded too, one record per statement, in your own bucket.
Your way back
Point the hostname back at the workspace and you are native again. No driver to uninstall and no copy of your tables on our side.
Rules, not a switch
You decide what is settled.
A cache that guesses gets turned off the first time an executive sees a stale number. Here every decision is a rule you write, in a schema you can read, live on the next query.
- Follow your load schedule. Expire on a TTL, or have the last task of your Lakeflow job call the markers API and that rule's cache goes stale everywhere at once.
- Writes bust only what they touch. An INSERT or MERGE invalidates the rules it names. Finance rollups stay served.
- Block what should never run. Deny by client IP range, time of day, user or table, answered as a native Databricks error before anything executes.
- Serve while it refreshes. Stale-while-revalidate keeps the first user past expiry off the warehouse's critical path.
// One rule. Cache dashboard SELECTs for an hour, per user.
{
"id": "dashboard-reads",
"enabled": true,
"priority": 50,
"mode": "all",
"conditions": {
"statementType": { "equals": "SELECT" }
},
"actions": {
"cache": { "ttlSeconds": 3600 },
"cacheKeyElements": ["userId", "standardizedSql"]
}
}
# Run it twice from DBeaver or databricks-sql-connector
X-Airbrx-Cache-Status: MISS # warehouse ran it
X-Airbrx-Cache-Status: HIT # it did notUntil you write a rule, queries pass straight through untouched and are only logged. Rule schema reference
Free forever, live in five minutes
Set up a CDN for Databricks SQL in four steps. No install, no driver, no code.
Your workspace, your warehouses and your tokens stay exactly as they are.
Sign in
Go to app.airbrx.ai and sign in with your Google or Microsoft work account. No card, no sales call.
1 minute
Get your gateway
You get your own three-word hostname on the spot, like
calm-river-otter..gateway.airbrx.ai Instant
Connect your workspace
Paste your Databricks server hostname. Add an HTTP path only if you want to pin one warehouse.
2 minutes
Swap the hostname
In one Power BI report, Tableau workbook or dbt target, use the three-word host instead. Same HTTP path, same token.
Same afternoon
To leave, put the old hostname back. Free forever on the Starter plan; usage caps may apply.
A volume knob, not a switch
Route one tool. Leave the rest alone.
Your workspace hostname keeps working. The gateway is an extra path, opt-in per connection. Put the dashboard that keeps the warehouse awake through it first, and let finance stay direct until they have checked the numbers themselves.
High-volume reads
BI dashboards, embedded analytics, Excel refreshes, agents and apps that ask the same thing on a loop.
Everything else, for now
dbt builds, Lakeflow jobs, notebooks, Databricks SQL dashboards and admin work. Move any of it later, or never.
- Databricks documentation, SQL warehouse settings: Auto Stop.
- Databricks documentation, Query caching.
- Databricks documentation, Dashboard caching.