The control plane for SQL
Is your warehouse bill out of control?
Most of it is questions you already answered — 94% of warehouse statements never change a byte. See what repetition is costing you on Snowflake or Databricks, from your own query history, in minutes.
Read-only · your token is never stored · nothing to install · Starter has no platform fee · how we handle credentials
Illustrative figures for a mid-size Snowflake account — representative shape, not your data. Scan to see your own.
What every other layer has
We stopped running things raw. Except data.
Every class of traffic that mattered eventually earned a layer in front of it — something that answers the repetitive, records the traffic, and gives you one place to set policy. SQL is the exception, and it always has been.
Snowflake, Databricks, Postgres — straight to origin, every time
Nothing on the path
Cloudflare didn’t make the web faster by rewriting websites. It put something on the path.
Where the money goes
You’re renting a supercomputer to re-answer settled questions.
The warehouse is priced like the extraordinary machine it is. Most of what you point at it is routine. Per-second billing is fair; paying it repeatedly for one answer is not — and everyone is about to add AI traffic on top.
Illustrative arithmetic, not a measurement — the shape is the claim, and your own numbers are one scan away.
You don’t have to take our word for what warehouse traffic looks like. Snowflake published it.
A third of it is a machine asking what columns exist. You are running a warehouse to answer that — at $0.13 a try, retries included.
Source. Szlang et al., “Workload Insights From The Snowflake Data Cloud”, PVLDB 18(12): 5126–5138, 2025 — Figure 1, statement types across 667M production queries, October 2024. “94%” is 47 + 31 + 16 and nothing more; it is not a claim that 94% is cacheable, since a SELECT still needs the warehouse unless it is a repeat. Writes here group the paper’s DDL 4%, DML 2% and transactions 0.5% — that grouping is ours, the numbers are theirs. $0.13 per message is Snowflake Cortex Analyst list price: 67 AI credits per 1,000 messages at $2.00 per credit.
The wake-up tax
On many engines the meter starts on connect, not on question. Your BI server logs in each morning and bills you before anyone asks.
We answer the handshake. Nothing wakes up.
Busted for the wrong reason
Last quarter is settled, and the native cache would serve it — until unrelated rows land in the same table and bust an answer that never changed.
You declare it settled; it stays served.
The engines do have a result cache. Snowflake’s own documentation on persisted results is where the limits come from: reuse requires that the table’s micro-partitions have not changed — so unrelated writes, and even background reclustering that changes no values at all, invalidate a still-correct answer. It also requires the query text to match exactly, down to case and table aliases.
That is the published average. The only number that matters is yours — and one read-only scan of your own query history will tell you what it is.
Why it gets worse from here
For thirty years, a query had an author. Then it didn’t.
The crossover already happened one layer up — and it happened eighteen months earlier than the man who measures it predicted.
Nobody reviewed it
The SQL is generated from a sentence someone typed. No colleague read it before it ran.
It explores, then retries
One prompt becomes dozens of queries, most of them near-duplicates of each other.
It answers to a service account
Every agent shares one identity, so nothing traces back to a person or a ticket.
It never gets tired
Machine pace against per-second billing, overnight, at weekends, unattended.
Sources. Cloudflare Radar, 3 Jun 2026 — requests for web pages on one network, not SQL. HUMAN Security, 2026 State of AI Traffic, 26 Mar 2026 — over 1 quadrillion interactions; agent traffic up ~7,851% year over year. Barry McCardel, CEO, Hex, 10 Mar 2026 — agents now create more cells in Hex than people do directly. dbt Labs, 2026 State of Analytics Engineering, 363 practitioners — 57% report warehouse and compute spend rising.
Where to start
Don’t take our numbers. Go and get yours.
Point one read-only scan at your own query history and read your own hit rate, your own dollar figure, and what has actually been asking your data. Nothing you do here is hard to undo.
Nothing else changes
Put one thing on the path. Change one hostname to do it.
Airbrx speaks your engine’s native protocol and reads the SQL itself, so it can answer, rule on, and record a query before the warehouse ever sees it. Everything else we build stays off the path entirely.
The floor is today
A miss is forwarded untouched. No query can end up slower or costlier than it already is.
Our outage is not your outage
The gateway holds its own policy and serves on the last good copy. If our control plane goes dark, your queries don’t.
Leaving is the same move
Point the hostname back at the warehouse and you are native again in minutes. Nothing to unwind.
Start where the volume is
Route what repeats. Leave the rest exactly where it is.
Adoption is per connection string — a per-tool, per-team decision rather than a migration. Your scan ranks every suggested rule by what it alone is worth, so you can see how much of your own total sits behind how few clients, and point only those at the gateway.
One tool is a real answer
Point a single BI server at the gateway and you are done deciding. It is a valid first move and a valid permanent one — nothing else in your estate learns that Airbrx exists.
Routed is not changed
A query that matches no rule is forwarded untouched and simply recorded. Take the visibility first and the caching whenever you want it — or never.
The rest carries on as today
Native dashboards, dbt builds, catalog crawlers, admin sessions. Whatever you never point at the gateway reaches the warehouse exactly as it does now.
The savings arrive at whatever coverage you choose; the record is the part that gets better as you grow it. What usually stays direct, and why.
Never a stale number — unless you want one
The reason you can finally cache a warehouse.
Nobody refuses to cache because it isn’t fast enough. They refuse because an unexpected stale number once landed in front of an executive. So freshness is something you declare — and because most data changes land on the backend, where the gateway never sees the write, every way data changes has its own door to bust exactly what changed, and nothing else.
Your schedule
TTL & date-math windows
Declare the freshness a load schedule implies — entries expire on time, with no call at all.
Your pipeline
The load’s last step calls the bust
ELT, streaming and backend jobs write straight to the warehouse — the gateway never sees it. One API call posts a marker, targetRuleId, and that rule’s cache is stale.
Your rule edit
Publish = re-address
The rule version lives in the cache address, so a published change points reads at a fresh subtree instantly.
Your DML in-band
An INSERT busts its rules
A write through the gateway auto-busts the rules it declares — fire-and-forget, or fail-closed for security-critical writes.
A load finishes
POST /tenants/{tenantId}/invalidation-markers
{"targetRuleId": "customer-reads"}
Cache objects live under rule-{id}/rule-version-{v}/ and the marker is keyed on the same two attributes. However the order arrives — API call, schedule, rule edit or SQL write — it lands on that address and busts one rule’s subtree, nothing else.
Customer queries
rule customer-reads
Finance rollups
nightly aggregates
Product catalog
slow-moving reference
Exec dashboard
hourly refresh
Rule names shown are examples, not a real customer’s rule set. The pipeline door is one call — the markers API.
Byte-identical answers
A hit returns exactly what the warehouse returned. Not a re-derivation, not a re-model, not a rounding.
Freshness you write down
You declare what busts what — a pipeline call, a window, a write — in rules a human can read. Not a heuristic we guessed.
Invalid always beats stale
Staleness is a window you declared; invalidation is a bust that landed. An invalidated result is never served, at any staleness setting. Correctness outranks speed, in that order, in the code.
Or block the write
Where it matters, a failed invalidation stops the write rather than leaving stale rows readable.
See every query you route
The chokepoint you never had — agents included.
Your grants still decide who is allowed to see what. Airbrx is where you finally get to watch it happen — one place, one format, every client you point at it, whether a person or a model wrote the SQL. Coverage is something you grow, and the record gets more complete as you do.
One record per query
Every statement that crosses the boundary, in a fixed shape, so it is queryable on day one rather than after a parsing project. It lands in your own bucket, on your retention terms.
Never recorded: result rows, and raw credentials.
We never hold your credentials
The caller’s own token passes straight through and identity resolves from it — so row-level security and masking apply exactly as they do today.
Agents are just another client
Copilots, text-to-SQL and JDBC scripts speak the same protocol, so they land in the same record. “What has AI been asking our data?” becomes a query, not a project.
Nothing new on any desktop
Native wire protocol, so no driver to roll out and no workbook to re-certify. Your users never learn that anything changed.