Power BI

Update one field — the Server on the Snowflake or Databricks connector — and your reports query through the Airbrx Gateway. DirectQuery benefits the most: every interaction that asks a previously seen question gets a cached response in milliseconds.

Naming note. Microsoft's "On-premises data gateway" is a separate product for routing Power BI Service to private networks. The Airbrx Gateway is independent — they don't conflict and you don't need one to use the other.

Change the Server field

In Power BI Desktop, open Get Data → Snowflake (or Databricks; older Power BI builds may only show Azure Databricks, which works with any cloud despite the name) and update the Server field.

Server:    your-account.snowflakecomputing.com
Warehouse: REPORTING_WH
Mode:      DirectQuery

Server:    your-slug.gateway.airbrx.ai
Warehouse: REPORTING_WH
Mode:      DirectQuery

For Databricks, the equivalent field is Server Hostname (or the Server URL on the connector). HTTP Path stays the same — the Gateway is wire-compatible and forwards that part as-is.

Authentication

Use the same auth mode you'd use without the Gateway:

• Snowflake — username/password, key-pair, or OAuth (Snowflake account auth). The OAuth handshake completes against Snowflake; the Gateway forwards the resulting session.
• Databricks — Personal Access Token, OAuth, or (on Azure-hosted workspaces) Azure Active Directory. Whatever auth your workspace accepts, the Gateway just relays.

Power BI never sees an Airbrx-issued credential, and Airbrx never sees usable Power BI credentials at rest.

Verify the cache is doing work

Power BI doesn't surface HTTP response headers in the report UI. Use the App traffic page to watch queries flow through with their cache outcomes — Power BI's pattern is recognizable in seconds (the same aggregations and filters, repeated per visual interaction).

Full header list: response headers reference.

Notes worth knowing

• DirectQuery vs Import. DirectQuery sends queries on every visual interaction — the Gateway sees every one and caches what your rules say to cache. Import datasets pull a one-time snapshot through the Gateway, then Power BI caches it locally; the Gateway shows up at refresh time.
• Dataset refresh. Scheduled refreshes for Import datasets become a great place for invalidation rules — fire a manual marker before the refresh starts so the Gateway pulls fresh data, then Power BI rebuilds its local cache from that.
• Composite models. If you mix DirectQuery and Import, only the DirectQuery side benefits from cache hits. The Import side is warehouse-direct at refresh time.
• Per-user isolation. Power BI's RLS rules push down to the warehouse via DAX. If a cache rule isn't keyed per user, two users with different RLS could see the same cached result. Key per user (or per role) — the rules analyzer in the App flags this.

Where to go next

• Rules as the differentiator — how to author cache rules that match Power BI's query shape.
• Markers API — fire invalidation markers from your refresh pipeline.
• Other connection recipes.