In a cloud warehouse, why is the first query after a suspended compute cluster resumes slower than later runs?

## Why a cold cluster is slow When storage and compute are separated, a compute cluster is stateless with respect to persistent data — it holds caches and nothing else. That is what makes suspend and resume cheap for the platform, and it is exactly what makes the first query after resume expensive for you. Three things are cold at the moment a cluster comes back. **The machines.** Resuming means allocating worker VMs, starting the engine process on each, and joining them into a cluster. This is real wall-clock time before a single byte is read. On most platforms it is seconds to tens of seconds depending on cluster size and whether the provider keeps a warm pool; treat the exact figure as something you measure for your own platform rather than something you quote. **The local data cache.** A running cluster stores recently read column chunks on local NVMe SSD and in page cache. On a repeat scan most reads are satisfied locally at microsecond-to-low-millisecond latency. A resumed cluster's SSDs are empty — the old ones belonged to VMs that no longer exist — so every column chunk must come from the object store over the network, where per-request latency is orders of magnitude higher than local NVMe and throughput is bought by issuing many parallel ranged reads. The scan is not slower because the CPU is slower; it is slower because it is I/O-bound on a remote store. **Everything else warm-path.** Metadata for the tables being queried has to be fetched and parsed again, and engines that cache compiled plans or query fragments lose those too. These are smaller terms than the data cache but they show up on the very first statement. ## Reading it in the profile Most engines report, per query, how much data was read from remote storage versus served from the local cache. That split is the diagnostic. If the first run shows near 100% remote and the second run shows the same scan mostly local, you are looking at cache warm-up, not a plan regression, not a statistics problem, and not a data-layout problem. If instead the second run is also mostly remote, the working set is larger than the cluster's local cache and no amount of warming will fix it — you need a bigger cluster (more aggregate local SSD), better pruning so the working set shrinks, or acceptance that this workload is remote-read-bound. ## What resizing does Resizing is a partial version of the same effect. Adding workers gives you machines with empty caches and, on engines that assign files to nodes consistently, changes which node is responsible for caching which file — so even the surviving nodes' caches become partly useless. Removing workers destroys their cached data outright. A cluster that has just been resized will behave cold for a while even though it never suspended. ## Managing the trade-off The idle timeout is the control. Suspend aggressively and you stop paying for idle compute but pay cold-start on the next query; suspend lazily and queries stay fast while you burn compute on an empty cluster. The right setting follows the arrival pattern, not a rule of thumb: - **Interactive BI during business hours** — arrivals are bursty but continuous, so a short timeout guarantees users hit cold starts all day. Keep the cluster alive through the working window; the idle cost is small relative to the number of queries protected. - **A single nightly batch job** — nothing is served interactively, one cold start amortizes over an hour of work, so suspend as fast as the platform allows. - **A scheduled morning dashboard refresh** — schedule a cheap warm-up query a few minutes ahead so the cluster is up and the hot tables are partly cached when real users arrive. Two common mistakes are worth naming. Shortening the idle timeout to save money on a bursty interactive workload usually costs more than it saves, because every resume re-reads the working set remotely and the queries themselves run longer, burning compute-seconds. And downsizing the cluster does not shorten cold start meaningfully — a smaller cluster boots marginally faster but has less aggregate local SSD, so it stays cold longer and holds less of the working set. ## The framing that lands in an interview Cold start is the bill for statelessness. The same property that lets you suspend a cluster to zero cost, resize it without moving data, and run several clusters over one copy of the data is the property that guarantees a resumed cluster knows nothing. You do not eliminate it; you decide where to spend — idle compute, or first-query latency.