BigQuery — separated compute and storage, slots, the two compute pricing models, and the four storage billing models
The warehouse's cost and capacity model, which is the part an estimate turns on. Compute and storage are independent, compute is slots bought either on demand or as capacity in one of three editions, storage is billed under four named models, and there are four documented ways to get data in.
markdownreferencev1S56N-6X68stage: designtrust: officialfamily: dataservice: bigqueryinterface: anybigquerysloton-demand pricingcapacity pricingeditionsStandard editionEnterprise editionEnterprise Plus editionactive storagelong-term storagephysical storagelogical storageStorage Write APIBigQuery Data Transfer Service
BigQuery
1. Compute and storage are independent
"These compute and storage layers efficiently operate independently of each other thanks to Google's petabit-scale network."
That is the architectural fact behind every cost decision below, and it is the main structural difference from a cluster-based warehouse: you do not size a cluster to hold the data. Storage grows on its own; compute is bought separately and can be zero between queries.
2. Compute: two models, and three editions inside one of them
| Model | What you buy |
|---|---|
| on-demand | compute per query, with no reservation |
| capacity-based | slots, reserved — in Standard, Enterprise or Enterprise Plus editions |
The compute unit is the slot.
The choice is the single biggest lever in a BigQuery estimate, and it is not a discount question: the two models have different units. On-demand is metered by the query; capacity is metered by reserved slot capacity over time. A workload with spiky, infrequent, large queries and one with constant moderate querying can have inverted costs under the two models.
No figures are typed here. Read the live rates, and read your own slot usage, before choosing
(reference/overview/quotas-and-limits-model.md).
3. Storage: four named billing models
active · long-term · physical · logical
Two orthogonal pairs, and both choices matter:
- active against long-term is about age: data not modified for long enough is billed differently;
- physical against logical is about what is measured: bytes as stored (compressed) or bytes as logically
held.
The physical/logical choice is a real decision with real money attached, and it depends on how compressible the data is. A highly compressible dataset favours physical. This is a per-dataset setting in practice, and it is routinely left at the default in a migrated estate.
4. Four documented ways in
| Method | For |
|---|---|
| batch loading | files: Avro, Parquet, ORC, CSV, JSON, Datastore and Firestore exports |
| Storage Write API (gRPC) | the current high-throughput write path |
| BigQuery Data Transfer Service | scheduled transfers from other sources |
| streaming ingestion | row-by-row arrival |
And a fifth that does not appear on this page because it belongs to another service: a Pub/Sub BigQuery
subscription writes messages straight in with no code at all
(reference/messaging/pubsub.md §2). Check for that before building an ingestion pipeline.
5. For a migration estimate
BigQuery is paired with Amazon Redshift by Google's own table and with Fabric Data Warehouse / Azure Databricks by Microsoft's. Both are warehouse-to-warehouse matches at the name level, and the model underneath is different enough to change the arithmetic:
- a Redshift or Synapse-dedicated-pool estimate is cluster-shaped — nodes, sized to hold the data and
serve the queries;
- a BigQuery estimate is two independent numbers — bytes stored under one of four models, and compute under
one of two models.
So a node count does not convert. The inputs you actually need are bytes stored, bytes scanned per query
per day (for on-demand) or concurrent slot demand (for capacity). guides/parity/data.md §2 and
guides/parity-and-migration-method.md both treat these as required measurements.
Next: reference/data/errors.md for the reason strings, guides/data/query-bigquery-from-typescript.md.