In-Memory Cache
Stop Paying Your Data Warehouse to Answer the Same Question Twice.
Fig's in-memory cache sits between your team and your warehouse. Relationship-heavy queries — which accounts drive this metric, what's in the causal chain — are served from cache at sub-second speed. Your warehouse only gets hit when something actually changed.
Why Repetitive Queries Are Silently Expensive
Every relationship query that hits your warehouse has a cost. Most of those queries don't need to.
The same question, billed twice.
Every time someone asks who drives a metric, your warehouse runs the full query again. The data hasn't changed. The compute bill has.
Warehouses weren't built for graph traversals.
Recursive relationship queries hit Snowflake at full compute rates. Graph traversals — which accounts connect to this goal, what's in the causal chain — don't belong on columnar databases. You're paying premium prices for queries these platforms handle inefficiently.
8–12 seconds for an answer that hasn't changed since this morning.
Your team waits. The AI agent waits. Everyone waits — for a result that was already computed hours ago. Slow answers compound into slow decisions, and slow decisions have a cost that doesn't show up on your warehouse bill.
How Fig's Cache Works
Four steps from question to answer — most of the time, the warehouse never sees it.
Query Arrives
A person or an AI agent asks a question that involves relationships: which accounts drive this metric, what's in the causal chain, how does this entity connect to the goal.
Cache Checks First
Fig's in-memory graph store checks if the result is already cached. For most relationship queries during a workday, it is.
Sub-Second Response
Cache hit: result delivered in under 100ms. No warehouse query. No compute cost. The answer arrives before the question finishes rendering.
Smart Invalidation
When your data actually changes — new sync, metric update, entity change — Fig invalidates the affected cache entries. The next query re-fetches from the warehouse, then gets cached again.
What It Means for Your Business
Fewer warehouse queries. Faster answers. Lower costs — as usage grows, not despite it.
Up to 80% fewer warehouse queries
Most relationship lookups in Fig are repetitive. Cache hit rates run 70–85% in steady state — which means 70–85% of those queries never reach your warehouse.
Sub-second answers on complex queries
Causal chain traversals and account-to-metric joins that take 8–12 seconds on Snowflake return in under 100ms from cache. The same answer, 80–100x faster.
Lower warehouse costs, predictably
Each query Fig serves from cache is a warehouse query you didn't pay for. Costs reduce as usage grows — the opposite of how most tools work.
Why Warehouses Aren't Built for This
What Warehouses Are Great At
Snowflake, BigQuery, and Databricks are phenomenal at aggregating large amounts of tabular data. They're built for "sum all sales by region" type questions — columnar storage, vectorized execution, distributed parallelism.
For those workloads, they're exactly the right tool. Don't replace them. Protect them from the queries they weren't designed to handle efficiently.
What Graph Traversals Need
Relationship traversals are a different kind of question: "what causes what, which accounts are connected to this goal, how does this metric relate to that one." These queries involve recursive joins and graph traversals that columnar stores handle inefficiently.
A graph cache is the right tool for the right job — and it means you're not overpaying your warehouse for queries it wasn't designed to answer.
The warehouse handles aggregation. The cache handles relationships. Right tool, right job.
Part of the Modern Data Stack — Not a New Piece of It
Fig's cache isn't a separate product to manage. It's built into Fig's query layer — every causal graph traversal, every relationship lookup, every entity-to-metric join routes through it automatically.
No configuration. No ETL. No new infrastructure to monitor. Just faster answers at lower cost, from the moment your queries start.
Frequently Asked Questions
What is Fig's in-memory cache?+
Fig's in-memory cache stores the results of relationship-heavy queries — causal chain lookups, account-to-metric joins, entity traversals — so they don't hit your data warehouse every time. Cached results are served in under 100ms. The cache invalidates automatically when your data changes.
How much can the cache reduce my warehouse costs?+
In steady-state usage, Fig's cache hit rates run 70–85%. For most business questions that involve relationship traversals, you're not hitting the warehouse at all. Teams typically see 70–80% fewer compute-intensive queries within the first month.
Why are graph queries expensive on data warehouses?+
Snowflake, BigQuery, and Databricks are built for columnar aggregation — summing millions of rows efficiently. Graph traversals (which accounts connect to which metrics, what's in a causal chain) involve recursive joins that columnar stores handle inefficiently. A purpose-built graph cache is the right tool for this type of query.
Does the cache require separate setup or configuration?+
No. Fig's cache is built into the query layer and active by default. Every causal graph traversal routes through it automatically. There's nothing to configure and no separate product to manage.
Explore the Platform
Metric Relationship Tree
Causal map of what drives what in your business
Learn moreMetric Definitions
Versioned, approved metrics for every agent and team
Learn moreBusiness Policies & Rules
Your business logic enforced on every query
Learn moreBusiness Entities
Accounts, customers, products resolved across sources
Learn moreFlows
Signal → Decide → Act automated end-to-end
Learn moreMonitoring
24/7 anomaly detection with automatic root cause
Learn moreDecision Algorithms
12 built-in algorithms for governed analysis
Learn moreRoot Cause Analysis
Automated causal chain tracing
Learn moreFaster Answers. Lower Costs. Same Data.
Fig's in-memory cache is built in — no configuration required. Connect your warehouse and start serving relationship queries from cache in minutes.