One address in front of your Databricks SQL warehouse.

The path of one query

Every statement goes through the same steps, in the same order:

1. Parse. The gateway reads the SQL: which tables and columns, what kind of statement, which user is asking.
2. Check deny rules. If a deny rule matches, the statement is refused right there, as a permissions error in the client's own protocol. Databricks is never contacted.
3. Match a cache rule. Rules are evaluated in priority order. With no rule, the query simply passes through and is logged.
4. Build a predictable key. A deterministic hash of what the rule says matters: the standardized statement, the user, the tenant, sometimes the parameter values. No lookup table, so it stays fast however much is cached.
5. Check the cache. A result that exists, is not invalidated and is inside its TTL is returned directly, usually in a few milliseconds. The warehouse does nothing.
6. Forward, store, return. Otherwise the query goes to your warehouse with the caller's own token, and the answer is stored under the key for the next caller.

Connect your Databricks workspace

Log in with Google or Microsoft and you get a tenant and your own three-word gateway hostname, something like calm-river-otter.gateway.airbrx.ai. Then tell it where your workspace is:

• Server hostname. Your workspace hostname, for example dbc-1234567890.cloud.databricks.com. Not the account console: open a workspace and copy that address. Any region, any cloud.
• HTTP path (optional). The path of one SQL warehouse, like /sql/1.0/warehouses/abc123, from its Connection details tab. Set it to pin every query to that warehouse. Leave it empty and each connection keeps choosing its own, which is usually what you want.

There is no field for a Databricks password or token. The gateway never holds warehouse credentials; each caller's own token passes through to Databricks for that session only, and is never logged. What is stored, and where, is in the FAQ.

Point Tableau, Power BI, dbt, Python or JDBC at it

In every case the change is the server field. The HTTP path, the token and the driver stay as they are.

Tableau

Open the data source, and on the Databricks connector replace Server Hostname with your gateway address. Live connections benefit on every render. Extracts only pass through the gateway when they refresh.

Power BI

Get Data, then the Databricks connector (older builds show it as Azure Databricks, which works for any cloud). Replace Server Hostname. DirectQuery gains the most, because every visual interaction sends a query. Import models go through the gateway at refresh time.

dbt

# profiles.yml
my_project:
  target: prod
  outputs:
    prod:
      type: databricks
      host: calm-river-otter.gateway.airbrx.ai   # was dbc-1234567890.cloud.databricks.com
      http_path: /sql/1.0/warehouses/abc123  # unchanged
      token: "{{ env_var('DBT_DATABRICKS_TOKEN') }}"
      catalog: main
      schema: analytics

Route dbt's writes through the gateway as well as its reads. Then an invalidation rule can fire when a MERGE lands, and cached reads on that table refresh on the next request instead of waiting out a TTL.

Python

from databricks import sql

conn = sql.connect(
    server_hostname="calm-river-otter.gateway.airbrx.ai",  # the only change
    http_path="/sql/1.0/warehouses/abc123",
    access_token=os.environ["DATABRICKS_TOKEN"],
)

JDBC, ODBC, DBeaver and everything else

Replace the host in the JDBC URL, or the Host field of an ODBC DSN, and keep the rest. If you are kicking the tires, use DBeaver: it shows the gateway's response headers in its session log, so you can watch a repeat query come back as a hit.

Check that queries are being cached

Run a query twice through a tool that shows response headers, such as DBeaver or the Python connector:

X-Airbrx-Cache-Status: MISS   # first run: Databricks executed it
X-Airbrx-Cache-Status: HIT    # second run: it did not
X-Airbrx-Cache-Rule: dashboard-reads

For tools that hide headers, like Tableau and Power BI, the traffic page in the app shows every statement with its timing, its cache outcome and the rule it matched. If traffic appears there, the address resolves, the workspace connection works and credentials are passing through.

Keep the cache in step with your pipelines

A cache is only as good as its freshness story, so there are three, and you can mix them per rule:

• Time. A TTL that matches how often the data actually changes.
• Writes. DML through the gateway invalidates the rules it names, the moment it lands. Where it is critical, a failed invalidation blocks the write itself.
• Markers. Data that arrives some other way, from a Lakeflow job or an ingestion tool, can end with one call to the markers API, and that rule's cache is stale everywhere immediately.

Previous versions of cached results are kept, so if a bad load gets through, you can serve yesterday's answer while you investigate.

What it does not do

Full reference: how the gateway works, getting started and the rule schema on airbrx.ai.