The Four Pillars

Airbrx is built around four product goals. Each one shows up somewhere concrete — as a feature in the App, an enforcement point in the Gateway, or a guarantee in the API's contract. When a design question gets ambiguous, the Pillars are how we resolve it.

Platform Savings

Reduce warehouse costs through intelligent caching.

Most BI workloads are read-heavy and repetitive: the same dashboards, the same reports, the same exploratory queries — over and over. Every one of them wakes the warehouse and shows up on the bill. The Gateway intercepts those queries, returns cached results when it can, and only forwards to the warehouse when it has to.

How this shows up:

• The Gateway never wakes a warehouse it doesn't have to. Cached responses come from cloud storage in milliseconds, with no compute charged.
• Session and connection management. The Gateway pools and reuses warehouse sessions instead of opening a new one for every request, cutting the chatter that warehouses charge for even when no data is returned.
• Hit-rate visibility. The analytics API exposes per-day, per-user, and per-rule cache hit rates so you can see exactly where the savings come from — and where to push for more.

Consumer Experience

Faster reads without changing how users work.

The people running queries against your warehouse — analysts, business users, BI consumers — shouldn't have to learn a new tool, install a new driver, or rewrite a single dashboard for caching to pay off. Airbrx is transparent on purpose. The only thing that changes for them is that things load faster.

How this shows up:

• Same SQL dialect, same drivers. The Gateway is wire-compatible with Databricks and Snowflake. Tableau, Power BI, dbt, and DBeaver don't know they're talking to Airbrx.
• Cached responses in milliseconds. A dashboard that took 8 seconds to render against a cold warehouse can render in a fraction of a second when its queries hit cache.
• Connection recipes per tool. See the connection recipes for before-and-after settings for each major BI tool.

Granular Control

Fine-grained cache configuration paired with fine-grained rule-busting.

Caching is only useful when you can describe exactly what to cache, how long to keep it, and when to throw it away. Most data platforms give you the first half — configure a cache, set a TTL, hope for the best — and leave invalidation as someone else's problem. Airbrx treats both halves as peers, with the same matching language and the same edit surface. Cache rules and invalidation rules live next to each other in the App's rules workshop; the Gateway evaluates them together, per-query.

That combination — fine-grained cache with fine-grained rule-busting — is the rare thing. It's what makes caching usable in front of a real warehouse, against real workloads, where some data has to be milliseconds-fresh and some can sit for hours.

How this shows up:

• Cache rules and invalidation rules as peers. A cache rule says "cache aggregate queries on orders for one hour, keyed by user." An invalidation rule says "when an INSERT lands on orders, mark anything cached against that table dirty." See Rules as the differentiator.
• Predictable cache keys. Keys are computed deterministically from the elements you specify in the rule. No lookup, no cache database, no surprises about whether two queries collide.
• Rules analyzer. The App flags shadowed rules, priority conflicts, and unreachable conditions before they affect production traffic.

Secure & Compliant

Enterprise-grade security at the gateway layer.

Caching is only safe when it preserves what your warehouse already enforces. Airbrx is built so that adding the Gateway in front of your warehouse changes how fast queries return — not who can see what, or what gets logged.

How this shows up:

• Credentials pass through. The Gateway forwards your warehouse credentials to your warehouse without storing, logging, or inspecting them.
• RLS and masking preserved. Row-Level Security and column masking continue to be enforced by your warehouse, on the warehouse-executed query that produces the cached result.
• Fine-grained tokens. JWTs and Personal Access Tokens both carry a four-axis scope — method, path, tenant, account — so a token for a CI pipeline can read traffic from one tenant and do nothing else. See Security posture.
• Audit trails intact. Every query that reaches the warehouse appears in the warehouse's native audit log. Cached responses are logged separately by Airbrx and exposed through the analytics API.

How they compose

Pillars aren't independent. The same feature usually serves more than one — a cache rule that isolates results per-user lives in Granular Control, but it's also Security (because shared caches across users would defeat RLS) and Consumer Experience (because the user gets their own fast results either way). When in doubt, name which Pillars a design choice serves; if it doesn't serve at least one, it doesn't ship.

Where to go next

• The Gateway, App, and API — which Pillar each resource is responsible for.
• Rules as the differentiator — the Granular Control Pillar in detail.
• Security posture — the Secure & Compliant Pillar in detail.