Connect your warehouse to Airbrx

1. Sign up
2. Claim address
3. Connect warehouse
4. Point a tool
5. First rule
6. Verify

In the App, the configuration card looks like this

Paste your connection URL and the App auto-detects the adapter type and pre-fills the fields below. You'll review and save; that's the whole step. The fields are described next so you know what you're confirming.

Pick the adapter

The tenant configuration screen offers three adapter types. Pick the one that matches your engine:

Fill in the fields

Databricks

Server hostname

Your Databricks SQL Warehouse hostname — e.g. dbc-1234567890.cloud.databricks.com. The Gateway forwards requests here when the cache misses.

HTTP path (optional)

The HTTP path of a SQL Warehouse — e.g. /sql/1.0/warehouses/abc123, from the Databricks SQL Warehouse details page under "Connection details." Set it to pin every query to one warehouse. Leave it empty and the Gateway takes the warehouse from each incoming request instead, so your existing connections keep choosing their own — which is usually what you want.

Snowflake

Server hostname

Your Snowflake account host — e.g. your-account.snowflakecomputing.com. The full account identifier including region and cloud, not just the account name.

PostgreSQL

Host

Your database host — e.g. db.internal.example.com, or the hostname your managed provider gave you.

Port and database

Usually 5432 and the database your clients already connect to.

Auth mode

Required — there is no default, and no field anywhere for storing a database username and password. Choose relay for token-based backends like RDS IAM or Azure Entra, verifier-proxy for a real SCRAM exchange against your own database, or cleartext for a password over the mandatory TLS channel. See Supported engines for which to pick.

PostgreSQL tenants listen on port 5432 and require TLS — a client using sslmode=disable is refused rather than downgraded. The PostgreSQL recipe has the connection strings.

What's not on this screen

• Credentials. Whoever connects through the gateway address provides their own warehouse credentials. The Gateway forwards them to your warehouse without storing or inspecting them. See Security posture.
• The warehouse / database / role. Those vary per query and stay on the BI tool's side of the connection. You don't configure a "default warehouse" at the tenant level.
• Cache rules. Step 5. The tenant works fine with no rules — every query just passes through to the warehouse. Caching starts when you author the first rule.

What you should see

After saving, the tenant's status switches from "unconfigured" to "ready." The App shows the live runtime topology — your clients on the left, your gateway address in the middle, your warehouse on the right:

The traffic page is still empty (no BI tool has connected yet) but the Gateway is ready to receive traffic. Step 4 sends some.

If something goes wrong

• The save fails with a validation error. Re-check the server hostname for typos — the form validates the shape but not the reachability of the host.
• You picked the wrong adapter. Switch it. Tenant adapter type is changeable until traffic starts flowing through; once there's cached traffic, switching adapters effectively means starting fresh.
• HTTP path is hard to find. In Databricks, open the SQL Warehouse, look at the Connection details tab; the path looks like /sql/1.0/warehouses/<some-id>.