Theory
There is no cluster — there's a query and a pool
Snowflake and Databricks ask you to pick a compute size. BigQuery's differentiator is true serverless: you submit SQL, and Google allocates compute from a vast shared pool for the duration of that query. There is nothing to start, size or suspend.
- Dremel — BigQuery's execution engine breaks a query into a tree of stages and fans it out across thousands of workers that scan Capacitor (columnar) files in Colossus storage in parallel, then aggregate results back up the tree. This is how it scans terabytes in seconds with no cluster in sight.
- Slots — A slot is BigQuery's unit of compute (a virtual CPU share). A query is granted some number of slots; more slots = more parallelism. You either pay on-demand (billed by bytes scanned) or buy capacity / reservations (a fixed pool of slots for a flat rate, shared across your queries).
- Separation, taken further — Because compute is fully managed and ephemeral per query, scaling is automatic and invisible; the trade-off is you tune the query and the data layout, not a cluster size.
Use Case Example: An analyst runs an ad-hoc GROUP BY over a 10 TB events table at 2pm. BigQuery spins thousands of Dremel workers, scans the needed columns in parallel, returns in seconds, and releases all that compute the instant the query ends — the team never provisioned, sized, or paused a thing.