Cloud Parts

Google BigQuery

Google Cloud’s serverless data warehouse: no clusters, and you pay per TiB scanned or per slot-hour.

What it is
Data warehouses,Query engines
Type
Managed service on Google Cloud
Made by
Google Cloud
License
Proprietary
Facts checked
5 October 2026
Website

What it is

BigQuery stores each column separately, in its Capacitor format, and keeps storage and compute apart so each scales on its own. A query is split across many workers that scan only the columns it names. Compute is measured in slots, units of processing that Google assigns to each query from a large shared pool. There are no clusters to create: you load or stream data in and query it with GoogleSQL.

On demand, queries cost $6.25 per TiB scanned, the first TiB each month is free, and every query is billed for at least 10 MB. Steady workloads can buy capacity instead, as slot-hours in BigQuery editions. Through BigLake, BigQuery also queries Iceberg, Delta Lake and Hudi tables in Cloud Storage and other clouds, and BigQuery tables for Apache Iceberg keep data as Parquet in your own bucket while supporting full DML and streaming writes.

Why teams pick it

  • Truly serverless: nothing to size, and an on-demand project can use up to 2,000 slots at once
  • A free tier of 1 TiB of queries per month
  • Streaming ingest, partitioning and clustering, with SQL-based machine learning built in
  • Open formats through BigLake and managed Iceberg tables

Watch out for

  • On-demand cost tracks bytes scanned: SELECT * on a wide, unpartitioned table can cost far more than expected
  • On tables that aren’t clustered, LIMIT doesn’t reduce the bytes a query scans; filters on partition and cluster columns do
  • GoogleSQL and native storage tie you to Google Cloud, so leaving means rewriting jobs
  • Delta Lake tables are read through BigLake; BigQuery can’t change their schema

Alternatives

What all data warehouses have in common →
ClickHouseOpen sourceAn open-source column-oriented database for real-time analytics, fast enough to serve dashboards over billions of rows.DatabendOpen sourceA cloud data warehouse written in Rust that keeps every table as Parquet blocks and Git-like snapshots in object storage, so stateless compute clusters can start, scale and stop without moving data. Open core: Apache 2.0, with paid features under the Elastic License 2.0.MotherDuckCommercialA serverless cloud data warehouse built on DuckDB, where one query can run partly on your laptop and partly in the cloud.SnowflakeCommercialA fully managed cloud data warehouse that separates storage from compute, with virtual warehouses billed per second.

How it fits with other technologies

What uses Google BigQuery

Load Parquet, check what a query would scan, then cap its cost · bash

bq load --source_format=PARQUET \
  analytics.orders "gs://acme-raw/orders/2026/10/*.parquet"

# dry run: reports bytes that would be processed, costs nothing
bq query --use_legacy_sql=false --dry_run \
  'SELECT region, SUM(amount) FROM analytics.orders WHERE order_date >= "2026-09-01" GROUP BY region'

# fail instead of billing more than 10 GB
bq query --use_legacy_sql=false --maximum_bytes_billed=10000000000 \
  'SELECT region, SUM(amount) FROM analytics.orders WHERE order_date >= "2026-09-01" GROUP BY region'

See it in a real stack

No architecture uses Google BigQuery yet. Drop it into the playground and wire it up yourself.Open playground →

Benchmarks

Benchmark · ClickHouse Inc.ClickBenchHow fast analytical databases run 43 SQL queries over one 100-million-row table of web analytics events, on the same cloud machines.Includes Google BigQuery · 7 caveats to read first
How to read a benchmark →
Where it came from2006–2026

In the mid-2000s, Google processed huge datasets with MapReduce, writing jobs in C++ or the Sawzall language. The conventional wisdom inside the company was “SQL doesn’t scale”, and Google had moved away from SQL almost completely. Commercial warehouses such as Teradata and Netezza ran on dedicated servers. Google wanted thousands of employees to ask ad-hoc questions of trillion-row datasets and get answers in seconds.

Dremel began in 2006 as a “20 percent” project by Andrey Gubarev. It stored data in columns, used a new encoding for the deeply nested Protocol Buffer records Google used for nearly all its data, and fanned each query out across a tree of servers. The 2010 VLDB paper by Sergey Melnik and colleagues described aggregation queries over trillion-row tables finishing in seconds. That same year, on the first day of Google I/O in May, Google introduced BigQuery: Dremel, offered to the public as a cloud service.

Dremel’s ideas spread well beyond Google. Apache Parquet, announced by Twitter and Cloudera in 2013, adopted its nested-column encoding, and separating storage from compute became the standard design for cloud warehouses.

Why it’s built this way

Separate storage from compute
Early Dremel kept data on its own servers’ disks, so scaling storage meant adding CPUs too, and the data could only be read through Dremel. From 2009 Google moved it onto its shared file system, GFS, so compute and storage could scale separately.
Multi-tenant and serverless from the start
Serving thousands of users interactively at low cost was only possible with one shared, multi-tenant pool and on-demand resources, rather than a cluster per user. Work was scheduled in abstract units called slots, still how BigQuery measures compute today.
Columnar storage for nested records
Google’s logs had thousands of nested and repeated fields. Encoding them in columns let a query read only the fields it touched, and denormalised nested records avoided costly joins (Dremel had no joins at first).
Managed storage alongside querying files in place
Querying raw files gave no chance to optimise layout, collect statistics or run updates and deletes, so BigQuery added its own managed storage while keeping external tables over open files.

Timeline

  1. 2006

    Dremel starts as a 20 percent project inside Google

  2. 2010

    Dremel paper at VLDB; BigQuery introduced at Google I/O in May

  3. 2020

    BigQuery Omni runs BigQuery’s engine on data in AWS and Azure

  4. 2022

    BigLake brings BigQuery governance to open files on GCS, S3 and Azure

  5. 2023

    BigQuery editions bring autoscaling slots; flat-rate commitments stop being sold in July

  6. 2026

    BigQuery Graph becomes generally available in August

Sources17 · facts checked 5 October 2026

Improve this page on GitHub