Ship your first cache rule

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

Open the rules workshop

From the tenant page, open the Rules workshop — the page where you author and edit rules for this tenant. It starts empty. On the right side you'll see the rules analyzer; it'll start flagging warnings as you write rules.

The rule, in plain language

Cache SELECT statements for one hour, keyed per user.

"Keyed per user" matters: if your warehouse uses Row-Level Security or column masking, each user sees a different result for the same query — and a shared cache would let one user's results leak to another. Per-user keying isolates them. The rules analyzer flags this on every cache rule that doesn't include user identity in its key.

The rule, as JSON

For the App's rules workshop you'll fill in a form, but if you ever export the rule (or import one from another tenant) it looks like this:

{
  "id": "first-cache-rule",
  "name": "Cache SELECTs for an hour, per user",
  "description": "Walkthrough rule — see /docs/get-started/",
  "enabled": true,
  "priority": 50,
  "mode": "all",
  "conditions": {
    "statementType": { "equals": "SELECT" }
  },
  "actions": {
    "cache": { "ttlSeconds": 3600 },
    "cacheKeyElements": ["userId", "warehouse", "standardizedSql"]
  }
}

Field-by-field:

• priority: 50 — middle of the road. Specific rules with smaller numbers (1, 5, 10) get evaluated first. 50 is a fine default for a broad rule like this.
• mode: "all" — every condition must match (here there's only one). The other option is "either", for OR logic.
• statementType.equals: "SELECT" — only SELECT statements get this treatment. INSERTs, UPDATEs, and DELETEs pass through.
• ttlSeconds: 3600 — one hour. After that, the next read re-executes against the warehouse and re-caches.
• cacheKeyElements: ["userId","warehouse","standardizedSql"] — the cache key includes the user, the warehouse, and the normalized SQL. Per-user isolation, per-warehouse isolation, deterministic key.

For the full schema (every condition, every action, every cache key element), see the rule schema reference.

Save and run a query twice

Save the rule. Then go back to your BI tool from step 4 and run a SELECT. Run the same SELECT again. The two runs differ:

That difference — 412ms down to 8ms, with no warehouse compute on the second run — is what every other rule on the tenant is going to do for some slice of your traffic. The rest of the Airbrx product is just deciding which queries to apply this to, with what TTLs, and how to invalidate them when underlying data changes. That story is in Rules as the differentiator.

What you should see in the App

• The traffic page now shows mixed cache outcomes — the same query shows up as MISS the first time and HIT on subsequent runs.
• The dashboard's cache hit rate ticks up as you re-run queries.
• Bytes-served-from-cache starts climbing on the dashboard tile.