Serverless Architecture

## What "serverless" actually means here Most data warehouses ask you to buy a machine shape before you can run a query: a cluster of nodes, a virtual warehouse of some size, an instance class. Those systems couple three things together — how much data you can hold, how much compute you get, and how much you pay while idle. BigQuery decouples all three. You create a dataset and a table, load data, and run SQL. There is no cluster object in the API, no node count, no "resume the cluster and wait" step before the first query. Underneath, the pieces are real servers, they are just not yours: - **Storage** — table data is written to Colossus, Google's distributed file system, in BigQuery's columnar format. It is durable and replicated, and it exists whether or not anything is querying it. - **Compute** — query execution runs on Dremel, a multi-tenant execution service. The machines it runs on are scheduled by Google's cluster manager and shared across many customers. - **Network** — because the data is not on the worker's local disk, every scan is a network read. Google's datacenter network is fast enough that reading remote storage is not the bottleneck it would be in a typical on-premise design. ## Slots: the unit you get instead of nodes BigQuery expresses compute as **slots**. A slot is a unit of compute — Google describes it as a virtual CPU — that BigQuery uses to execute one unit of query work. A query is planned as a graph of stages; each stage is split into many small work units; the scheduler assigns available slots to those units and reassigns them as stages complete. Two consequences follow: 1. **Parallelism is dynamic.** A stage that reads 10,000 file splits can be spread far wider than a stage that reads 3. You never declare the width; the planner and scheduler decide, based on the shape of the data and how many slots are available at that moment. 2. **Slots are shared and reclaimed.** Between stages, and between concurrent queries, slots move. Nothing sits warm and billable on your behalf in the on-demand model. ## What you give up, and what you get The trade is control for elasticity. You get: - No capacity planning before the first query, and no cold-start-a-cluster step. - No storage-versus-compute sizing compromise — a tiny amount of compute can query a very large table, and a large query does not require you to grow storage. - No index rebuilds, vacuums, or node maintenance as an operational chore. You give up: - The ability to tune workers directly. There is no "give this query more memory per node" knob; you influence execution by changing the query and the physical layout of the table. - Predictable per-query performance in the on-demand model, because slot availability is shared. Buying capacity is what makes performance more predictable — that is the reservation model, and it is a separate topic from architecture. ## The levers that replace cluster sizing Because you cannot size machines, the performance and cost levers are all about the *work*, not the *hardware*: - **Bytes read.** Select only the columns you need — a columnar store reads only referenced columns — and filter on the table's partition column so whole date ranges are skipped. - **Bytes moved between stages.** Aggregate before joining, avoid exploding row counts, and avoid operations that funnel all rows through one worker. - **Result reuse.** Repeating an identical query against unchanged tables can be served from the cached result rather than executed again. ## How to say this in an interview The crisp version: *BigQuery separates storage from compute completely. Data lives in Colossus; execution borrows slots from a shared Dremel pool per query and gives them back. There is no cluster to size because there is no cluster that belongs to you.* Then name the consequence that matters to an operator: you tune the query and the table layout, never the machines. A common junior mistake is to describe BigQuery as "a database that autoscales its cluster." It does not scale a cluster of yours up and down — there is no such cluster to begin with. That distinction is exactly what the question is probing.