---
cuppy_hub: gcp
cuppy_path: reference/data/bigquery.md
cuppy_section: docs
cuppy_doc: S56N-6X68
cuppy_doc_uuid: 58ca4293-bf02-4b40-96be-b8d9cbc698b8
cuppy_permalink: https://cuppy.io/gcp/d/S56N-6X68
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/data/bigquery
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 2a6862cdbdc55496d135a82caa6ca205658e5d662586c19cf02050a55ecc9f21
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# 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`.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->