BigQuery pricing is two models for compute and one for storage: on demand per TiB of data a query scans, with the first TiB a month free, or capacity in slot-hours per edition with autoscaling and one- or three-year commitments; storage per GiB-month, active or long-term after 90 days without a change, billed logically or physically per dataset; plus streaming and Storage Write API ingestion per GiB, Storage Read API per TiB, BI Engine per GiB-hour of memory and egress per GiB when results leave the region. On the bill, on-demand scans dominate on teams that query ad hoc, slot reservations on teams that run pipelines, and storage grows quietly because nothing in BigQuery expires without a table expiration.

Pricing dimensions

Google prices BigQuery by what a query touches, not by the warehouse that runs it, unless an edition replaces that with reserved capacity; every price has its own SKU per region, and the region of the dataset sets it.

DimensionUnitWhat drives itOptional
On-demand computeTiB of bytes processed per query, by the columns read, partitions pruned and clustering; first 1 TiB a month free per billing account; minimum 10 MB per table and queryEvery query, dry run excluded; the scanned bytes, not the resultNo without an edition
Capacity computeSlot-hour per edition (Standard, Enterprise, Enterprise Plus), by the second with a one-minute minimum, autoscaled between a baseline and a maximum; one- or three-year commitments on Enterprise and Enterprise Plus at lower ratesReservations assigned to projects; the slots provisioned, not the queriesYes
Active storageGiB-month, logical (uncompressed) by default or physical (compressed, with time travel and fail-safe counted) per dataset; prorated per MiB and secondTables modified in the last 90 daysNo
Long-term storageGiB-month at about half the active rate for tables or partitions unchanged for 90 consecutive days; automatic, no performance changeTables that stop changingNo
Streaming and Storage Write APIPer 200 MiB for legacy streaming inserts, per GiB for the Storage Write API, with a monthly free allowanceReal-time ingestion; batch loads freeYes
Storage Read APITiB read through the Storage Read API, with a monthly free allowanceSpark, Dataflow and BI tools reading tables directlyYes
BI EngineGiB-hour of reserved memoryDashboards on cached dataYes
BigQuery ML and other operationsTiB processed for model creation and prediction, per million tokens for remote models; Omni per TiB; data transfer per sourceModels, external data, transfersYes
EgressGiB when query results or copies leave the dataset's region, by continent pair; within the region freeCross-region queries and copiesYes
Purchase optionSlot commitments over one or three years on Enterprise and Enterprise Plus; nothing on on-demand or storageSteady query loadYes (Google Cloud committed use discounts)

On demand charges the bytes a query reads, and the columns, partitions and clustering decide them: a query that selects three columns of a partitioned table for one day reads kilobytes, the same query with SELECT * over the whole table reads everything, at the same price per TiB. The first TiB a month is free per billing account, and the price per TiB does not fall with volume, so a team that scans 100 TiB a month pays a hundred times the team that scans one. Editions replace that with slots: a reservation of a baseline and a maximum of slots per edition, billed per slot-hour while the slots are allocated, autoscaled up when queries wait and down when they finish, with a one-minute minimum per scaling step; a commitment over one or three years lowers the slot-hour and pays it whether queries run or not. The break-even sits where the on-demand scans of a month exceed the slot-hours of the same work; for teams that query all day it falls at a few hundred slot-hours, for teams that query at month end it never comes. Storage is the quiet line: logical billing counts uncompressed bytes at the lower rate, physical billing counts compressed bytes with time travel at about double the rate per GiB, and which is cheaper depends on the compression ratio of the data; long-term storage halves the rate for tables untouched for 90 days, automatically. The mechanics across all three providers are in data warehouses and analytics.

How it appears in your billing data

In the billing export the rows carry service.description BigQuery and a sku.description that names the model and region: Analysis (europe-west3) for on-demand bytes processed in TiB, Active Logical Storage (europe-west3) and Long Term Logical Storage (europe-west3) or the physical variants per GiB-month, Streaming Insert (europe-west3) and BigQuery Storage Write API per GiB, BigQuery Storage API Read per TiB, BI Engine (europe-west3) per GiB-hour; a reservation appears under service.description BigQuery Reservation API as Enterprise Edition Slot Hours (europe-west3) or Enterprise Plus Edition Slot Hours per slot-hour, with the commitment as its own row. usage.amount is in bytes for scans and storage, in hours for slots; location.region is the dataset's region, and resource.name in the export with resource-level detail names the reservation, not the query. Which query or user caused the on-demand bytes is not in the export: the INFORMATION_SCHEMA.JOBS views name total_bytes_billed, user_email and the labels per job, and a reservation's slot usage per job sits in JOBS_TIMELINE; the export's labels carry the project's labels and the job labels an application sets.

Credits sit in credits: the free TiB of on-demand analysis appears as credits.type FREE_TIER beside the analysis row, a slot commitment as COMMITTED_USAGE_DISCOUNT beside the slot-hours; there is no sustained use discount on BigQuery. The export's structure is described in the Google Cloud billing export; in the FOCUS export, ServiceName carries BigQuery, ServiceCategory Analytics, SkuId the SKU, PricingCategory Standard or Committed and CommitmentDiscountId the commitment (FOCUS columns). How the export itself is set up, in BigQuery, is in that page; the export's own storage and queries are BigQuery rows like any other.

on demanda reservationA queryPricing model ofthe project?Analysis: the bytes processedper TiB, the free tieras a credit beside itSlot-hours of the edition, thecommitment as a credit beside themThe tablesActive and long-term storage,logical or physical, per GiB-month;streaming and the Storage APIas rows of their own
BigQuery bills the bytes a query processes on demand or the slot-hours of a reservation, storage apart by age and form, and the commitment credits only the slots

Levers

Configuration: the first lever is partitioning and clustering with a filter on the partition column, because a query pays the partitions it reads and a table without partitions pays everything on every query; the second is the column list, because SELECT * reads every column and BigQuery stores columns apart; the third is the model per project, on demand for ad hoc and rare queries, a reservation with autoscaling for pipelines and dashboards that run all day, and a maximum bytes billed per query as the guardrail against the scan that reads a petabyte. Table expirations and partition expirations end the storage growth of staging and temporary tables; the patterns of the data layer are in storage optimisation.

ad hoc, rarelypipelines and dashboardsall dayPartitioning and clustering with afilter on the partition column: aquery pays the partitions it readsThe column list: SELECT starreads every column, stored apartHow does theproject query?On demand, with a maximumbytes billed per queryA reservation with autoscaling:the commitment on the measuredminimum, not the peak
Partitions and columns decide the bytes a query pays, the model per project follows the query pattern, and a byte limit catches the query that reads everything

Purchase option: slot commitments over one or three years on Enterprise or Enterprise Plus for the baseline a team uses every hour, with autoscaling for the rest; the commitment pays its slot-hours whether queries run or not, so the baseline is the measured minimum, not the peak (commitment strategy).

Architecture: materialised views and BI Engine for dashboards that repeat the same query, because the second scan of the same bytes costs as much as the first; the Storage Read API for Spark and Dataflow instead of exporting to Cloud Storage and back; and the dataset in the region of the compute that reads it, because cross-region results pay egress. What a pipeline on Dataflow or Dataproc costs beside the warehouse is in Dataflow, Dataproc and Composer pricing.

Where it goes wrong

  • The dashboard scans the whole table. A dashboard that refreshes SELECT * every five minutes on an unpartitioned table pays the table's size 288 times a day. INFORMATION_SCHEMA.JOBS by total_bytes_billed names it; partitions, columns and BI Engine end it.
  • The reservation idles at night. A baseline of 500 slots pays 500 slot-hours every hour. Autoscaling from a baseline of zero, or a smaller commitment, matches the load.
  • The commitment covers the wrong edition. A commitment on Enterprise does not cover Enterprise Plus slots; the fee runs, the credit does not. One edition per organisation unless a feature demands the other.
  • Physical billing on uncompressed data. Physical storage at double the rate saves only when data compresses by more than half; JSON and strings often do, floats rarely. The dataset's storage metadata shows both.
  • Staging tables never expire. Every pipeline run leaves a table; the storage line grows by the run. A default table expiration on the dataset ends it.
  • The query exceeded the free TiB on day one. The free TiB is per billing account and month, not per project. A maximum bytes billed on the project catches the scan before it costs.
  • The result left the region. A query over datasets in two regions, or a copy to another region, pays egress per GiB. Datasets co-located with their consumers.

Example

List prices in USD for Frankfurt (europe-west3), read on 2026-10-21 from the BigQuery pricing page: on-demand analysis costs USD 8.125 per TiB after the first TiB a month; capacity compute USD 0.052 per slot-hour on the Standard edition, USD 0.078 on Enterprise and USD 0.13 on Enterprise Plus at pay-as-you-go, USD 0.0702 and USD 0.117 with a one-year commitment, USD 0.0624 and USD 0.104 with three years; active logical storage USD 0.000031507 per GiB-hour, USD 0.023 per GiB-month, long-term logical USD 0.016, active physical USD 0.052, long-term physical USD 0.026 per GiB-month; the Storage Write API USD 0.0325 per GiB, legacy streaming inserts USD 0.013 per 200 MiB, the Storage Read API USD 1.43 per TiB; BI Engine USD 0.0541 per GiB-hour.

A team that scans 20 TiB a month on demand pays 19 × 8.125 = USD 154.38; at 200 TiB USD 1,616.88; at 2 PiB USD 16,636.00. The same 200 TiB of work done by a reservation of 100 Enterprise slots running eight hours on working days, 220 × 100 = 22,000 slot-hours, costs USD 1,716.00 at pay-as-you-go and USD 1,372.80 with the three-year commitment, close to on demand; the same slots around the clock, 73,000 slot-hours, USD 5,694.00, which pays off only above 700 TiB of scans a month. A dataset of 50 TiB of logical data costs USD 1,177.60 a month active and USD 819.20 once 90 days have passed without a change; the same data compressed to 15 TiB under physical billing USD 798.72 active. A dashboard that scans a 2 TiB table 288 times a day costs 2 × 288 × 30 × 8.125 = USD 140,400 a month on demand, and a few dollars with a partition filter and BI Engine. The figures show that the scanned bytes, not the stored ones, carry the bill on demand, that a reservation beats on demand only when it is busy most of the day, and that storage is cheap until nothing expires.

Sources

Read on 2026-10-21. Prices: BigQuery pricing. Service: BigQuery editions, storage billing models, estimate and control costs. Billing data: structure of the standard Cloud Billing data export, INFORMATION_SCHEMA.JOBS view.