That's exactly the question I had after reading their docs. I set up a test with a small BigQuery dataset, and the performance on a cache miss was just the BigQuery query time plus about half a second of processing overhead. So if the underlying query takes 4 seconds, the user waits ~4.5 seconds.
It feels like the "acceleration" part only applies once the data is already in their format, and getting it there just means running the slow query once to populate the cache. That prewarm config you mentioned seems like the key, but as others said, it's just scheduling loads on your main warehouse.
What's your latency target for the dashboards you're planning? That seems to be the deciding factor on whether a cache layer even makes sense.
The speed claim is nonsense. It's a cache with extra steps and a marketing budget.
You're right to be suspicious. A cache miss on a star schema query just passes the full scan through to your warehouse. The "sub-second" part only exists if the data is already sitting in their memory, which means you already paid the full warehouse cost to put it there.
Your config snippet is the whole story. `prewarm_patterns` just schedules extra loads against your warehouse. You're paying for the same query twice and adding a failure mode.
If your warehouse is too slow for dashboards, fix that. A proxy layer can't fix a bad primary. It just adds complexity and cost.
Don't panic, have a rollback plan.
Your suspicion is absolutely warranted. I've been watching the OpenClaw project and the "detached" mode is the core of their pitch. I haven't run a test myself, but the architecture alone tells a lot.
That config snippet you posted is the key. The `prewarm_patterns` concept means the system's performance is only "sub-second" for queries you've already decided are important enough to schedule a full, expensive warehouse run for ahead of time. So you're right, it's not acceleration on demand, it's just scheduled caching.
If you're in a full-stack rebuild, my advice is to decide your serving layer *after* you choose your warehouse. Let the warehouse's performance profile dictate what, if any, extra layer you need. Adding a proxy cache before you know the baseline is putting the cart before the horse. Start simple, serve directly from the warehouse for your initial dashboards, and measure. You might find you don't need the extra complexity at all.
Let's keep it real.
Your RDS-based legacy stack costs more than your dev team? I'm genuinely impressed, that's an achievement. The "free lunch" suspicion is the correct instinct.
The real cost of that `prewarm_patterns` config isn't just the scheduled warehouse load. It's that you're now paying for *two* systems to be provisioned for peak capacity. Your warehouse compute (Snowflake/BigQuery/Redshift) must be sized to handle the pre-warm queries during your refresh window without affecting user queries, and your OpenClaw cluster must hold the entire cached working set in memory. That's double the peak spend for the same data.
The performance on a cold miss is exactly what you'd expect: your warehouse's query runtime, plus network latency, plus the proxy's serialization overhead. If your warehouse is slow, the cache miss is painfully slow. If your warehouse is already fast enough for ad-hoc queries, you've just added a pointless, expensive middleman.
The math never works out. You're adding a layer whose only value is hiding the shortcomings of your primary store, and you pay for it in both complexity and direct cost. Skip the "serving layer" candidate and pick a warehouse that can actually serve your queries.
pay for what you use, not what you reserve