An analytics platform separates storage from compute so many teams can query the same data. How should result caching, per-team compute isolation, concurrency scaling and cost attribution be designed — and what workloads defeat the cache?

What the separation actually buys

One copy of the data, many independent compute clusters. The consequences are structural rather than incremental:

• Workload isolation without data duplication. A finance team's month-end batch cannot slow the product team's dashboards, because they run on different compute against the same storage. In a coupled architecture, isolation requires copying the data, which then diverges.
• Compute scales with demand and can be zero. An idle team costs storage only, which is the economics that makes many small consumers viable.
• Cost attribution becomes natural, because each team's compute is a separate, measurable thing.
• Elastic concurrency: additional clusters spin up for a burst of queries and shut down afterwards.

Result caching, and its layers

• Result cache — an identical query against unchanged data returns the stored result without any compute. Effectively free, and its hit rate is dominated by dashboards, which issue the same queries repeatedly.
• Local disk cache on the compute cluster, holding recently-read data files. Warms over time, which is why a freshly-resumed cluster is slower and why aggressive auto-suspension trades cost for latency.
• Metadata and pruning, using per-file statistics to skip files entirely. The largest single performance factor in practice, and the reason data layout matters more than cluster size.

What defeats the cache

• Queries with current_timestamp or any non-deterministic function, which are never identical.
• Continuously changing tables, since any write invalidates the result cache for that table.
• Ad hoc exploration, where every query differs slightly by construction.
• Aggressive auto-suspension, which discards the local cache — the tuning knob between idle cost and first query latency, and one that is frequently set without measuring the trade.
• Randomised or unique parameters per user in dashboard queries.
• Full-table scans on unpruned layouts, where nothing can be skipped.

Isolation and concurrency design

• A cluster per team or per workload class, sized to that workload, so a heavy job cannot affect an interactive one.
• Separate interactive from batch, always. Interactive queries queued behind a two-hour batch job is the most common complaint in a shared platform, and it is a configuration problem rather than a capacity one.
• Multi-cluster scaling for concurrency, which addresses queuing rather than query speed. Slow queries and queued queries are different problems with different remedies, and conflating them leads to buying a larger cluster when the issue was concurrency.
• Timeouts and query limits per class, so one runaway query cannot occupy a cluster indefinitely.

Cost attribution and the behaviour it produces

Per-cluster cost attribution makes spend visible, and it also creates the incentive that makes the platform efficient: a team that sees its own compute cost will suspend idle clusters, size appropriately, and fix the dashboard that refreshes every thirty seconds.

The counterpart is that shared costs need a defensible key — storage, the shared metadata layer, and the platform team's own usage — and the key matters less than it being agreed and stable, because arguments about the key consume the energy that should go into reducing the cost.

The failure that undermines the whole design

Data layout. Separation of storage and compute makes compute elastic and does nothing about scanning too much data. Partitioning and clustering on the columns that queries actually filter by is what makes pruning effective, and a platform with poor layout responds to slow queries by adding compute — which works, costs enormously, and never addresses the cause.