Excel

Excel is where most analysts actually live. Point its Power Query connector at your gateway address and every refresh that re-issues a previously seen query comes back from cache — without anyone learning a new tool, switching workbooks, or rewriting a single PivotTable.

Find the connector

Excel doesn't keep Snowflake and Databricks under From Database — that submenu is for SQL Server, Oracle, MySQL, etc. The data-warehouse connectors live elsewhere, and where exactly depends on your Excel version and which cloud your Databricks runs in:

• Snowflake — Data → Get Data → From Online Services → Snowflake on modern Excel (Microsoft 365). On older builds it may appear under From Other Sources → Snowflake instead.
• Databricks — Data → Get Data → From Azure → From Azure Databricks. The connector is named "Azure Databricks" for historical reasons but accepts a Databricks workspace on any cloud (AWS, GCP, or Azure). If you don't see it, fall back to ODBC.

If you don't see the connector under Get Data, two more places to look before falling back to ODBC:

• Office Add-ins. Insert → Get Add-ins opens the Office store. The Databricks connector is sometimes published there as an installable add-in for Excel builds where it isn't part of the base Get Data list.
• Excel edition. The Snowflake and Databricks Power Query connectors require Microsoft 365 (Business / Enterprise) or a recent Excel for Business desktop install. Excel Home & Student / Excel Personal don't have them at all, even via the add-ins gallery — for those editions, use the ODBC fallback.

Change the Server field

Once you've opened the connector dialog, the change is one field — the Server (or Server Hostname on the Databricks connector). Warehouse, database, and the other fields stay the same.

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

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

For Databricks, fill in the Server Hostname field with your gateway address; HTTP Path stays unchanged — the Gateway forwards that part of the request through.

ODBC fallback (older Excel, or no built-in connector)

If the built-in connector doesn't exist for your warehouse:

1. Install the Snowflake or Databricks ODBC driver from the warehouse vendor.
2. In Excel: Data → Get Data → From Other Sources → From ODBC.
3. Configure a DSN (or paste the connection string inline); use the gateway address as the Host / Server parameter.

The ODBC path works on every Excel version that supports Power Query and on every cloud Databricks runs on. The Gateway is wire-compatible with the standard Snowflake and Databricks ODBC drivers.

If you sign in to Databricks with SSO

ODBC drivers need a credential they can pass with each request. If your Databricks login is SSO-only (Google, Microsoft, Okta, etc.) you don't have a Databricks password to give the driver — generate a Personal Access Token (PAT) in Databricks and use that instead:

1. In the Databricks workspace, click your profile (top-right) → User Settings.
2. Developer → Access tokens → Generate new token. Name it (e.g. excel-odbc), pick a lifetime your security policy allows.
3. Copy the token now — Databricks shows it once.

In the ODBC DSN, set Authentication mechanism to Token and paste the PAT into the Token field. On older drivers without an explicit Token mode, use User Name and Password with token as the username and the PAT as the password.

The same PAT can authenticate Tableau, Power BI, Python, dbt, and any other client that asks for a Databricks credential — generate one, store it in your password manager, reuse.

Authentication

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

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

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

Verify the cache is doing work

Excel doesn't surface HTTP response headers in any of its UIs. Use the App traffic page to watch queries flow through with their cache outcomes — Excel's pattern is recognizable in seconds (the same aggregations and filters, repeated on every refresh).

Full header list: response headers reference.

Notes worth knowing

• Refresh All. Every Power Query connection in the workbook re-runs on Refresh All. Cached queries return quickly; uncached or cache-busted queries hit the warehouse. The mix is exactly what your cache rules say it should be.
• PivotTables and PivotCharts. They sit on top of Power Query's data, so the cache layer benefits them too. Refreshing a pivot doesn't re-issue the underlying query unless the source range changes; when it does re-issue, that's where the Gateway comes in.
• Power Pivot model. The Power Pivot data model caches inside the workbook itself once loaded. Subsequent refreshes re-fetch through the Gateway and benefit from cache hits; the in-workbook model then rebuilds.
• Excel for Mac. Power Query support exists but is more limited than Windows. The Snowflake and Databricks connectors where available work the same — change the Server field, save the workbook.
• Excel on the web / SharePoint / OneDrive. Refreshes executed by Excel Server-side or by Excel for Web also flow through the Gateway, since they use the connection string saved in the workbook. No extra setup per copy.

Where to go next

• Rules as the differentiator — how to write cache rules that match Excel's repeated-aggregation pattern.
• Response headers reference — the headers the App's traffic page exposes per request.
• Other connection recipes.