For the engineer in the room

The whole product, front to back.

Airbrx speaks the protocols your applications already speak, transactional and analytical alike. One data path, any workload.

Your applications BI · dbt · JDBC · apps · AI agents direct — not routed CONTROL · OFF THE QUERY PATH REST API Rules, config, entitlements MCP server The same controls, for agents Airbrx Gateway one data path, any workload YOUR DATA Databricks OLAP Thrift protocol Snowflake OLAP REST protocol PostgreSQL OLTP Native wire protocol Your storage cache · logs · rollups
The engines share one row on purpose: Airbrx does not care whether what it is talking to is transactional or analytical. The API and the MCP server are the control surface — the gateway pulls policy from them, and they never sit between a query and an engine. Routing is per connection string, so the applications you haven’t pointed at the gateway keep reaching the engines directly.

The core

Six things, and nothing else on the path.

Rules engine

Serve it, or turn it away — by caller, by time of day, by identity, before it reaches the engine. Eight rules, worked through — in the exact schema the gateway runs.

Deterministic keys

Same inputs, same key. A hit returns byte-identical bytes, not a re-derivation.

Surgical invalidation

One rule’s results, never the whole cache. A pipeline call, a schedule, a rule edit or a write — each busts the subtree it should and nothing else.

Stale-while-revalidate

Answer now, refresh behind — where you have declared that trade acceptable.

Credential pass-through

The caller’s own token. Your row-level security and masking apply exactly as they do today.

Audit and rollups

One record per query, in a fixed shape, written to your own bucket.

Where it runs

Two deployment models. The same guarantees in both.

Hosted by Airbrx

Nothing to run, and the lower-cost path. Cache, logs and rollups still land in your bucket.

In your own account

The gateway runs inside your perimeter too. Nothing of yours touches our infrastructure.

Either way, queries execute on your engine, under the caller’s own token — and the control plane stays off the query path in both.

Measured

One production run, with its limits named.

A real run against a real Databricks tenant, and an honest account of what it does and does not prove.

0
warehouse executions across the entire run
25/25
served from cache — every arrival, warm-up included
178ms
median, served — 187ms end to end

The run. Databricks gateway tenant, 29 July 2026. Open-loop, 60 queries a minute for 25 seconds, 2 distinct queries, 25 arrivals. 20 measured (5 warm-up excluded), 0 failed, 0 dropped, target rate achieved.

What it does not prove. The 100% hit rate is the workload’s design — two distinct keys — and is not a hit-rate result; do not read it as one. Latency here tracks driver roundtrips rather than cache status: 175ms median at one roundtrip (n=13), 627ms at four (n=7), and every one of those was a hit. With n=20 the tail is meaningless, so we quote the median and the roundtrip split and leave p95 alone. There was no direct-to-Databricks arm, so this is not a before-and-after. The cache was warm at the first arrival, so the run never exercised a miss-and-fill.

Don’t take our run for it. Get your own numbers.

The scan reads your own query history and tells you what the repetition is costing you — on your traffic, against your own bill.