What is BigQuery?

BigQuery is Google Cloud's serverless data warehouse¹ — there are no clusters to provision, size, or keep running. You submit SQL, and the query just runs across a massive shared pool of compute that Google operates and you never see. It descends from Dremel, Google's internal interactive query system, and exposes that engine to anyone with a Google Cloud project. The pitch is genuine zero-ops: no nodes, no patching, no capacity planning to get started. The catch, as always, is in how it bills you for that convenience.

🔗 Learn more — ¹ What is a data warehouse?

Serverless, and the storage/compute split

The defining design choice is the separation of storage and compute. Your data lives in BigQuery's managed storage, billed roughly like object storage by the gigabyte. Query execution is a completely separate, stateless service that spins up to read that data, runs your SQL, and disappears. Nothing stays warm waiting for you, and you never own a server.

This is what "serverless" actually buys you here. There is no cluster to leave running, no idle nodes burning money overnight, and no resize ticket when one report suddenly needs ten times the horsepower. The execution layer scales to the query in front of it. Conceptually it sits in the same family as a data warehouse like Snowflake, which also splits storage from compute — but BigQuery hides the compute unit entirely rather than asking you to pick a warehouse size.

Under the hood, data is held in a columnar format called Capacitor: BigQuery stores each column separately and compresses it, so an analytical (OLAP²) query that touches three columns out of two hundred only reads those three. The query engine³ itself is Dremel-style — a multi-level serving tree that fans a query out across thousands of workers, each scanning a shard, then aggregates the partial results back up the tree. That tree is why a scan over terabytes can finish in seconds.

🔗 Learn more — ² OLTP vs OLAP: two opposite jobs

🔗 Learn more — ³ What is a query engine (Trino, Presto, and friends)?

%% color = green: the only layer you pay per-byte to scan
flowchart TD
    SQL["your SQL query"] --> ROOT["Dremel root: plans + splits the query"]
    ROOT --> W1["worker: scans shard"]
    ROOT --> W2["worker: scans shard"]
    ROOT --> W3["worker: scans shard"]
    W1 --> STORE["Capacitor columnar storage"]
    W2 --> STORE
    W3 --> STORE

    classDef grey stroke:#7b88a1,stroke-width:2.5px
    classDef green stroke:#a3be8c,stroke-width:2.5px
    class STORE green
    class SQL,ROOT,W1,W2,W3 grey

How it bills, and why that bites

BigQuery offers two pricing models. On-demand bills by bytes scanned — every query costs in proportion to how much data the engine had to read. Capacity pricing instead reserves a pool of compute (measured in slots) for a flat rate, decoupling cost from scan volume. Most teams start on-demand because it needs zero setup.

On-demand is where the cost surprises live. Since you pay per byte read, a careless SELECT * over a wide table scans every column whether you needed them or not, and an unfiltered query against a huge table scans the whole thing. The same query engine that feels free at small scale can quietly run up a real bill at large scale, and the cost is invisible until the invoice arrives. The fix is structural: data partitioning⁴ splits a table by date or an integer range so a query with a matching WHERE clause only scans the relevant partitions, and clustering physically sorts data within partitions so filters can prune further. Partitioning and clustering are not micro-optimizations here — on a scan-priced engine they are the primary lever you have over what each query costs. You design the table to limit bytes scanned, not just to run fast.

🔗 Learn more — ⁴ What is data partitioning?

Streaming and built-in ML

Two features round out why people reach for it. The Storage Write API (and the older streaming inserts path) lets you push rows in continuously and query them within seconds, so BigQuery serves near-real-time dashboards, not just nightly batch loads. And BigQuery ML lets you train and run models — regression, classification, clustering, even calls out to large models — using ordinary CREATE MODEL SQL, so analysts who know SQL can do predictive work without exporting data to a separate ML stack or learning Python.

The honest summary: BigQuery delivers on true zero-ops and is genuinely fast, with a strong story for streaming and in-warehouse ML. But the scan-based pricing that makes on-demand so frictionless is also its sharpest edge — costs scale with bytes read, so undisciplined queries get expensive, and partitioning and clustering exist precisely to keep that in check. And it is firmly Google Cloud lock-in: the engine, the storage format, and the ML all live inside one cloud. Whether that trade is worth it depends entirely on whether you are already committed to that cloud, and how disciplined your queries are.