Before you ask
The five questions everyone asks. All fair.
We would rather answer them here than have you think them quietly for the rest of an evaluation. Most of them come down to one picture.
You’d be sitting between our tools and our most sensitive data.
We would — and we would hold none of it. The caller’s own token passes straight through, so identity resolves from it and your row-level security and masking apply exactly as they do today. Result contents are never read or retained. Cache, logs and rollups are written to storage you own, on your retention terms.
A miss is forwarded untouched. There is no copy of your data on our side to ask us about.
And when you have an outage?
The gateway holds its own policy and keeps serving on the last good copy, so our control plane going dark doesn’t stop your queries.
And a miss is forwarded untouched, which sets a floor: no query can end up slower or costlier than it already is.
If you want out entirely, point the hostname back at the warehouse and you are native again in minutes. Nothing to unwind.
Our security review takes months.
Most of what makes those reviews long doesn’t apply here: no credential custody, no second copy of your data, no new driver on any desktop, no change to your grants or masking. Your users never learn that anything changed.
You are reviewing a network hop, not a new data processor.
Do we have to put everything through you at once?
No — and most accounts shouldn’t. Routing is per connection string, so it is per tool and per team. Point one BI server at the gateway and nothing else in your estate learns that Airbrx exists.
That is usually where the money already is. Repetition concentrates in high-volume BI and agent reads, which are also the easiest thing you own to repoint. Native dashboards, dbt builds, catalog crawlers and admin sessions commonly stay direct on purpose — and can stay that way permanently. What usually stays direct.
Routed is not the same as changed. A query that matches no rule is forwarded untouched and simply recorded, so you can take the visibility first and the caching whenever you want it.
One limit worth saying plainly: the savings arrive at whatever coverage you choose, but the record only covers what you route. That is a reason to start where the volume is — not a reason to route everything on day one.
How would we know it’s actually working?
Hit rate, latency and bytes served from cache are measured per query and land in your own logs — not estimated by us.
Point one dashboard at the gateway and you’ll have the answer the same afternoon, before anyone signs anything.
The record
One row per query. In your bucket, not ours.
Every statement that crosses the boundary is written down once, in a fixed shape, so it is queryable on day one rather than after a parsing project — whether a person or a model wrote the SQL.
Recorded
- Who ran it, and what they ran
- Which rule matched
- Hit or miss, and why it missed
- How long it took, and bytes returned
Never recorded
- Result rows. Contents are never read or retained.
- Raw credentials. The caller’s token passes through; we hold none of it.
The scan
What happens to a token you paste into this site
The scan on this site is separate from the gateway, and it asks for a read-only token. Its whole life with us:
- It is kept in your own browser so you don’t re-enter it on every visit. Disconnect everything clears it, along with any stored scan result.
- That copy survives a restart. On a shared machine, mint a short-lived token — a day is plenty — and disconnect when you are done.
If you would rather not hand over a token at all, don’t. Run the query yourself and paste the results back — nothing connects to us, the analysis runs in your browser, and you get the same number.
This website
What we store on your device
If you are just reading, one thing: your light or dark theme preference, so the site looks the way you left it. That is a setting you chose, it identifies nobody, and it is why you are not reading a cookie banner right now.
If you sign in on the scan page, that changes, and it should. Signing in stores an access token in a cookie and a refresh token in local storage, because that is what keeps you signed in. They identify you, they expire, and signing out clears them. They exist to authenticate you and do nothing else — no profiling, no measurement, and nothing that follows you to another site.
No advertising tags and no third-party analytics, signed in or not.
Two other hosts are contacted, and it is worth naming them. Our icon font is served from a public CDN on every page, and the contact form is hosted by HubSpot and loads on that one page only. Both see the IP address and browser string that every HTTP request carries. Neither is analytics, and neither follows you from page to page.
One caveat we would rather state than have you find: loading the contact form sets a short-lived __cf_bm cookie on HubSpot’s own domain, not ours. It is Cloudflare’s bot check and it lasts about half an hour. Apart from that and the sign-in above, nothing here sets a cookie.
The scan pages additionally keep whatever you connect or paste, as described above.
The fastest way to check any of this is to try it.
Read your own hit rate on your own traffic, before anyone signs anything.