BigQuery pricing: what queries and storage cost, with examples

What a query costs on demand

On-demand pricing charges for the bytes a query reads, not for how long it runs or how many rows it returns.

cost = TiB scanned × $6.25

A query that scans 100 GiB costs about $0.61. One that scans 2 TiB costs $12.50. And the first TiB of the month is free, so a small project often pays nothing for queries.

The rules that decide how many bytes are read, from the pricing page:

• You are charged for the columns you select, in full. BigQuery is a columnar store: SELECT * reads every column, SELECT order_id reads one.
• LIMIT does not reduce the cost. The page says so directly: you are charged for the data processed in the selected columns “even if you set an explicit LIMIT”.
• A query that returns an error is not charged, and neither is one answered from the cache.
• There is a minimum of 10 MB per table referenced and per query.
• Cancelling a running query can still cost up to the full price.

A measured example

A Search Console export table with 58.8 million rows, 10.35 GiB in total, partitioned by date. The same sum, three ways:

Two things to read from it. The whole table is 10 GiB and a single-column query reads 448 MiB of it, because only that column is scanned. And one query costs a fraction of a cent. A BigQuery bill is rarely about one expensive query. It is about a cheap one that runs every fifteen minutes from a dashboard.

See the cost before you run

The console shows an estimate in the top right of the editor before you run: “This query will process 448.35 MB when run”. That is a dry run, and it is free. Multiply by $6.25 per TiB.

To see what queries already cost, by user, for the last 30 days:

SELECT
  user_email,
  COUNT(*) AS queries,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4), 3)
    AS tib_billed,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4)
    * 6.25, 2) AS usd_on_demand
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE creation_time >= TIMESTAMP_SUB(
    CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND statement_type != 'SCRIPT'
GROUP BY user_email
ORDER BY tib_billed DESC;

In the project used for this article, that query showed 0.475 TiB billed to one person over 30 days and 0.133 TiB to a service account: all within the free tier. The service account is usually the line worth reading, because nobody is watching it. More ways to read this view are in BigQuery query history.

Capacity pricing: paying for slots

The alternative to paying per TiB is paying for compute capacity, measured in slots (virtual CPUs) per hour, through BigQuery editions.

One- and three-year commitments lower the Enterprise and Enterprise Plus rates. Capacity is billed per second with a one-minute minimum, and the autoscaler adds and removes slots as queries arrive.

Under capacity pricing the number of bytes scanned no longer sets the bill. Slot-hours do. That changes what is worth optimizing: a query that scans little and computes a lot, with heavy joins or window functions, is cheap on demand and costly on slots.

Which to choose. On demand suits irregular workloads and anything under or near the free TiB. Capacity suits steady, heavy use where the monthly per-TiB total would exceed the cost of the slots you need. To compare, take your monthly total_slot_ms from the query above, convert to slot-hours, and price it against your per-TiB total.

What storage costs

Storage is billed per GiB, prorated per second, in one of two billing models that you choose per dataset:

Google’s own worked example: 1 TiB of active logical storage for a full month costs $23.552. The first 10 GiB each month is free.

• Active is any table or partition modified in the last 90 days.
• Long-term is one that has not been modified for 90 consecutive days. The lower rate applies automatically, with no change in performance.
• Logical bytes are the uncompressed size; physical bytes are the compressed size on disk. Physical costs more per byte, and you pay for time travel and fail-safe storage on top. It pays off when your data compresses well.

What resets the 90-day clock: loading, appending, DML, streaming, or CREATE OR REPLACE TABLE. What does not: querying, exporting, copying the table, creating a view over it.

Each partition of a partitioned table ages separately. A table partitioned by day that only receives today’s data moves its history to the long-term rate one day at a time.

For the 10.35 GiB table above, active logical storage comes to about $0.24 a month before the free 10 GiB. For most analytics projects storage is the small part of the bill.

What is free

• The first 1 TiB of query data per month, on demand.
• The first 10 GiB of storage per month.
• Batch loading data, from Cloud Storage or local files.
• Batch exports, up to 50 TiB a day.
• Queries that fail, and results served from cache.
• Dry runs.
• The BigQuery sandbox, which works without a billing account inside those limits.

What costs extra

• Streaming: $0.01 per 200 MiB for streaming inserts; $0.025 per GiB for the Storage Write API over gRPC, after 2 TiB free each month.
• Storage Read API: $1.10 per TiB read, after 300 TiB free each month.
• Data Transfer Service: free for Google sources such as Google Ads and Google Analytics 4; paid connectors are billed in slot-hours.
• BigQuery ML, BI Engine and BigQuery Omni have their own price lists on the same page.

How to lower the bill

In order of effect for a typical on-demand project:

1. Select only the columns you need. This is the single largest lever.
2. Partition large tables by date and filter on the partition column. In the example above that took a query from 448 MiB to 0.4 MiB. Wrapping the column in a function undoes it.
3. Cluster by the columns you filter on most.
4. Stop the repeated query. Find scheduled jobs and dashboards that scan the same data many times a day, and point them at a small pre-aggregated table or a materialized view.
5. Set a ceiling. maximum bytes billed on a query makes it fail instead of running over; custom quotas cap a user or a project per day.
6. Let old data expire, with table or partition expiration.

LIMIT is not on the list. It reduces the rows returned, not the bytes read.

Who is running the queries

Every item above is about a query someone wrote. The costs that surprise people come from queries nobody remembers writing: a dashboard that refreshes for forty viewers, a spreadsheet that reloads a full table every hour, five reports that each compute the same join from raw data.

That is partly a cost problem and mostly an ownership one. In OWOX Data Marts, each Data Mart is one query you wrote, with an owner and a description, and the reports in spreadsheets and dashboards are built on it and scheduled from it. It runs in your warehouse, on your BigQuery bill, so the cost does not go away. What changes is that the recurring load on a table comes from a short list of named queries you can open, measure and tune, instead of from every tool separately. OWOX does not optimize the SQL or reduce what Google charges for it.

Google BigQueryHow to connect GA4 to BigQuery: setup, limits and first queriesOctober 6, 2026→Google BigQueryHow to connect BigQuery to Google Sheets: three waysOctober 6, 2026→Google BigQueryBigQuery Sandbox 2025: Beginner's Setup and TipsOctober 3, 2024→

See all articles →