Databricks CDN questions, answered

A feature of the Airbrx Gateway that sits in front of your Databricks SQL warehouse, the way a CDN sits in front of a website. Your tools connect to a gateway address instead of your workspace hostname. Repeat reads are answered from cache, so the warehouse only runs for questions it has not already answered. Everything else passes through to Databricks unchanged.

The result cache lives inside the warehouse, so serving a hit still needs a running warehouse, and any update to an underlying table invalidates the entry. The gateway answers before Databricks is involved, so a hit does not keep the warehouse awake, and you decide what invalidates each result. Keep both: anything that reaches the warehouse still benefits from its own caches. Full comparison.

No. The gateway speaks Databricks' own protocols, Thrift over HTTP and the JSON statement API, so the Databricks ODBC, JDBC and Python connectors and the tools built on them work as they are. You change the server hostname. The HTTP path, token and SQL stay the same.

Yes. Each caller's own token passes through to Databricks, so Unity Catalog grants decide access exactly as they do now. The gateway holds no warehouse credentials of its own; there is not even a field for one.

They keep running in Databricks. When people see different rows, key that rule's results by user (userId). Each person then gets answers Databricks computed under their own row filters and masks, and nobody is served someone else's rows. The app flags rules that would share results across users on tables that need per-user keys.

Anything you can point at a Databricks server hostname: Tableau, Power BI, Excel, DBeaver, dbt, the Python connector, JDBC applications, internal apps and AI agents. Work that runs inside Databricks, like AI/BI dashboards, notebooks and jobs on workspace compute, does not use a hostname you control and stays direct.

No. It is opt-in per connection. Your workspace hostname keeps working. Most teams start with the one dashboard that keeps the warehouse awake and leave everything else direct until they have checked the numbers.

Every rule says. A TTL for data on a schedule. Invalidation when specific writes land, the moment they land. Or a call to the markers API at the end of a pipeline, which makes that rule's cache stale everywhere at once. Nothing is cached until you write a rule.

Yes. Deny rules match on client IP range, time of day, user, catalog, schema, tables or statement text, and refuse the statement before anything runs, as a permissions error in the client's own protocol. They are checked before any cache decision.

Cached results, under keys your rules define, and one record per statement, written to your own bucket. Raw credentials are never recorded. Cached answers do not appear in Databricks' query history, because Databricks did not run them; they are in the gateway's record instead.

Databricks SQL warehouses in any region on any cloud. The gateway needs your workspace hostname, and an HTTP path only if you want to pin one warehouse.

Nothing, on the Starter plan, for as long as you like: one tenant, no card to sign up, no trial clock. Usage caps may apply. Larger plans raise the caps and add tenants, governance and automation. Pricing.

Point the hostname back at your workspace. There is no driver to uninstall and no copy of your tables on our side to retrieve.

Run the scan. It reads 30 days of system.query.history with a read-only token you supply, counts the repeats, prices them, and suggests the rules that would capture them. The token is used once and never stored. For a quick estimate first, try the SQL warehouse cost calculator. Scan my Databricks query history.

No. Databricks CDN is built and run by Airbrx. It is not affiliated with or endorsed by Databricks, Inc.; it works with Databricks SQL the same way any compatible client does.