BigQuery Pricing Explained: Storage, Query Costs, and On-Demand vs Capacity Pricing
BigQuery charges for two things: storing data and querying it. Storage costs a few cents per GB per month. Query costs depend on which pricing model you choose. On-demand pricing charges $6.25 per TB of data scanned, with no upfront commitment and the first 1 TB per month free. Capacity-based pricing gives you dedicated compute resources called slots through BigQuery editions, with optional commitments for lower rates. Most beginners and small teams should start with on-demand. Capacity-based pricing becomes worth evaluating when your monthly on-demand spend is consistently high and predictable.
Simple explanation
BigQuery’s architecture separates storage from compute. You pay for each independently, and they scale independently. Storage is straightforward: you pay for the data sitting in your tables. Compute is where the pricing model choice matters.
Think of it like electricity. On-demand pricing is pay-as-you-go: you are billed for exactly how much data your queries read, and nothing when no queries run. Capacity-based pricing is more like a fixed-rate plan: you reserve a set amount of compute power and pay for it whether you use it or not, but heavy usage becomes cheaper per unit.
The rest of this page breaks down how each cost surface works, when each pricing model makes sense, and how to estimate costs before you spend anything. If you are new to BigQuery, start with the BigQuery overview first.
What BigQuery can charge you for
Most BigQuery spend falls into two categories:
Storage: the cost of keeping data in BigQuery tables. Charged per GB per month. Older, untouched data gets an automatic discount.
Query compute: the cost of running SQL queries against your data. This is where your pricing model choice (on-demand vs capacity-based) applies. It is usually the larger portion of the bill for active teams.
There are also smaller, less common cost surfaces:
- Streaming inserts: the legacy streaming API charges $0.01 per 200 MB of data ingested. The newer BigQuery Storage Write API has a free monthly allowance. See loading data into BigQuery for the different ingestion options and their costs.
- Data extraction: exporting data to Cloud Storage is free within the same region. Cross-region exports incur network egress charges.
- BigQuery ML: model training and some prediction operations have per-TB charges on top of normal compute.
- BI Engine: an in-memory acceleration layer with its own reservation cost, separate from standard query pricing.
This page focuses on storage and query compute because they account for the vast majority of BigQuery bills. For a broader view of how GCP services are priced, see GCP pricing models.
Storage pricing
BigQuery charges two rates for storage depending on how recently a table or partition was modified.
Active storage: $0.02 per GB per month. This rate applies to any table or partition that has been modified in the last 90 days.
Long-term storage: $0.01 per GB per month. After 90 consecutive days with no modifications, BigQuery automatically cuts the storage rate in half. You do not need to configure anything. The discount applies the moment the 90-day threshold is reached.
For partitioned tables, each partition is evaluated independently. A table with daily partitions might have recent partitions at the active rate and older partitions at the long-term rate simultaneously. This is one reason partitioning matters beyond query performance.
The rates above apply to logical storage billing, which measures uncompressed data size. BigQuery also offers physical storage billing, which measures compressed size at a higher per-GB rate ($0.04 active, $0.02 long-term). Because BigQuery compression is typically 3–5x, physical billing often costs less overall. New datasets may default to physical billing. Check your dataset’s storage billing model in the console or with bq show.
Example: your dataset has 500 GB of tables modified this week (active) and 2 TB of historical tables untouched for over a year (long-term). Monthly storage cost: (500 × $0.02) + (2,000 × $0.01) = $10 + $20 = $30 per month. Storage is rarely the expensive part of a BigQuery bill.
Compute pricing: on-demand vs capacity-based
This is the pricing decision that matters most. BigQuery offers two compute pricing models. You can use different models for different projects or reservations within the same organisation.
On-demand pricing
On-demand pricing charges $6.25 per TB of data scanned by your queries. The first 1 TB per month is free. You pay nothing when no queries run, nothing for failed queries, nothing for dry runs, and nothing for queries that hit the 24-hour result cache.
”Data scanned” means the total bytes BigQuery reads from the columns and partitions your query touches. It is not the number of rows returned. A query that reads 500 GB of data and returns 10 rows costs the same as one that reads 500 GB and returns 10 million rows. What drives cost is how much data BigQuery has to read from storage to answer the query.
On-demand is like a taxi: you pay for each journey based on distance. Great for occasional trips. If you commute the same route daily, a monthly transit pass (capacity-based pricing) is worth calculating.
On-demand scales to zero. If your team runs no queries for a week, you pay nothing for compute that week. This makes it the natural starting point for most teams and the better choice for variable, exploratory, or low-volume workloads.
Capacity-based pricing
Capacity-based pricing gives you dedicated compute resources called slots. A slot is roughly equivalent to a virtual CPU in BigQuery’s query engine. Instead of paying per TB scanned, you pay for the slots you reserve, and all your queries share that slot pool with no per-TB charge.
Capacity-based pricing is structured through BigQuery editions:
- Standard: basic analytics features at the lowest per-slot cost.
- Enterprise: adds features like row-level security, multi-statement transactions, and higher concurrency limits.
- Enterprise Plus: adds advanced security, performance, and disaster recovery features.
Within each edition, you create a reservation and configure two settings:
- Baseline slots: the minimum number of slots always available to your workloads. You pay for these continuously.
- Autoscaling maximum: the upper limit of slots BigQuery can add automatically when demand exceeds your baseline. Autoscaled slots are billed per slot-second only while in use.
Autoscaling means you do not need to guess your peak demand exactly. Set a baseline for your steady-state workload and let autoscaling handle bursts.
Commitments are optional. You can purchase 1-year or 3-year commitments to reduce the per-slot cost for your baseline slots. Commitments lower your rate but lock you in. You do not need a commitment to use capacity-based pricing. Starting with autoscaling only (no commitment) is a common way to test whether capacity pricing fits your workload before making a longer-term decision.
If your queries need more slots than your reservation provides, they queue rather than fail. Queries will run more slowly when the slot pool is fully consumed. Monitor slot utilisation through INFORMATION_SCHEMA.JOBS to right-size your reservation. For more on how slots and BigQuery’s compute engine work, see the architecture page.
On-demand vs capacity-based pricing: when to use each
| On-demand | Capacity-based | |
|---|---|---|
| Best for | Variable, exploratory, or low-volume workloads | Steady, high-volume production workloads |
| Cost shape | Pay per TB scanned | Pay per slot-hour (baseline + autoscaling) |
| Predictability | Costs vary with query volume and data size | Baseline cost is fixed; autoscaling adds variable cost |
| Risk | Runaway query can produce a large bill | Slots cap compute, but queries may queue |
| Free tier | 1 TB/month free | No free tier |
| Typical workload | Ad-hoc analyst queries, dashboards with caching | Scheduled ETL pipelines, large BI platforms |
Which model to start with
Beginners: start with on-demand. The free tier covers a surprising amount of exploratory work, and you pay nothing when idle. Do not switch until you have enough usage data to model the comparison.
Small analyst teams (a handful of people running occasional reports): on-demand is almost certainly cheaper. A team scanning 5 TB per month pays about $31 on on-demand, which is less than even a small slot reservation.
Steady enterprise workloads (scheduled pipelines, consistent daily query volume): capacity-based pricing can save money if your monthly on-demand bill would regularly exceed the cost of a right-sized reservation. Calculate your average monthly TB scanned, compare the on-demand cost to the equivalent slot cost in your chosen edition, and factor in whether autoscaling covers your peak demand. See estimating cloud costs for a general approach to this kind of comparison.
Bursty, high-concurrency workloads (many users hitting dashboards at the same time): capacity-based with autoscaling handles concurrency spikes well. On-demand can become expensive quickly when many large queries run simultaneously, because each query is billed independently for the data it scans.
How BigQuery pricing works in practice
Understanding the pricing model is one thing. Knowing what actually drives your bill is another. These are the factors that determine your real-world BigQuery costs:
Bytes scanned per query: this is the single biggest cost driver on on-demand pricing. A query that scans 1 TB costs $6.25. The same query rewritten to scan 50 GB costs $0.31. The difference usually comes from column selection and partition filters, not from the question being asked. See BigQuery performance optimisation for specific techniques.
Table design: wide tables with many columns cost more to query because accidental SELECT * reads everything. Partitioned tables with date filters let BigQuery skip entire date ranges from scans. A well-designed table can make the same query 100x cheaper than a poorly designed one.
Query frequency is a silent cost multiplier. A query that costs $0.50 is cheap. That same query running every 5 minutes costs $144 per day. Scheduled queries and dashboard refreshes deserve special attention because they accumulate cost in the background without anyone noticing.
Cache hits: BigQuery caches results for 24 hours. If the same query runs against unchanged data within that window, the cached result is returned at no compute charge. Dashboard queries that many users run against the same underlying data benefit significantly from caching.
Storage age: data that sits untouched for 90 days automatically drops to half-price storage. If you have large historical tables that are rarely queried, the long-term rate keeps storage costs low without any action on your part.
Workload consistency: if your query volume is steady and predictable, capacity-based pricing lets you pay a flat rate. If your query volume spikes unpredictably, on-demand avoids paying for idle slots during quiet periods.
Set up billing budgets and alerts on your BigQuery project. A budget alert at 50% and 80% of your expected monthly spend gives you time to investigate before costs run away.
How to estimate cost before running a query
Never run a large query on an unfamiliar table without checking the cost first. BigQuery provides two free ways to estimate bytes scanned before you spend anything.
In the console: the query validator in the bottom-right corner of the SQL editor shows estimated bytes to be scanned as you type. It updates in real time. If you see “This query will process 2.5 TB”, you know the on-demand cost would be about $15.63 before you click Run.
From the CLI: use the —dry_run flag to get the byte estimate without executing the query. Dry runs are free and consume no quota. If you are new to the bq CLI, running your first query walks through the setup.
# Estimate bytes scanned without running the query
bq query \
--use_legacy_sql=false \
--dry_run \
'SELECT user_id, event_type, revenue
FROM `my-project.analytics.orders`
WHERE DATE(created_at) = "2026-03-01"'The output shows the estimated bytes. To convert to on-demand cost: divide the byte count by 1,099,511,627,776 (1 TB in bytes) and multiply by $6.25.
Example 1: small ad-hoc analyst query
An analyst wants to check yesterday’s revenue by product category. The orders table is partitioned by created_at and has 40 columns.
Dry run result: 850 MB (the query selects 3 columns from one day’s partition).
Cost estimate: 850 MB = 0.00083 TB × $6.25 = $0.005. Essentially free. This query is cheap because it uses a partition filter and selects only the columns it needs.
Example 2: repeated dashboard query
A dashboard refreshes every 15 minutes, running a query that scans the last 30 days of a 200-column event table without selecting specific columns.
Dry run result: 4.2 TB per execution. Cost per run: 4.2 × $6.25 = $26.25. At 96 runs per day, that is $2,520 per day or roughly $75,600 per month.
Add a partition filter for the last 30 days, select only the 8 columns the dashboard uses, and reduce the refresh interval to 1 hour. The same query drops to 200 GB per run, costing $1.25 per execution and about $30 per day. If the data does not change between refreshes, the 24-hour cache eliminates the cost of repeated runs entirely. Monthly cost: roughly $900.
Same dashboard, same questions, same data. The difference between $75,600 and $900 comes from partition filters, column selection, and refresh frequency. If you encounter query sizes that seem unmanageable, the query too large troubleshooting guide covers how to reduce oversized queries systematically.
LIMIT 100 does not reduce bytes scanned. BigQuery scans the full qualifying data before applying the limit. A query with LIMIT 10 costs exactly the same as the same query without it. To actually reduce scan volume, use partition filters and select only the columns you need.
Common beginner mistakes
- Using
SELECT *in production queries. BigQuery’s columnar storage reads only the columns your query requests.SELECT *reads every column. On a 100-column table where you need 5 columns, you pay for 20x more data than necessary. Always list the columns you need explicitly. - Assuming LIMIT reduces cost. This is the most common BigQuery misconception (see warning above). For sampling, use
TABLESAMPLE SYSTEM (1 PERCENT)or add a partition filter to reduce actual scan volume. - Missing partition filters on large tables. On a two-year table partitioned by day, a query without a date filter scans all 730 partitions. Adding
WHERE DATE(event_timestamp) = ‘2026-03-01’scans one partition. That is a 730x cost difference. Enablerequire_partition_filter=trueon critical tables to reject queries that forget the filter. - Testing against full production tables. While iterating on query logic, test against a single recent partition or a small sample table. Running exploratory SQL against a multi-terabyte table while you refine the logic is expensive and unnecessary. Use dry runs to check the cost before executing.
- Switching to capacity-based pricing too early. Capacity pricing only saves money at sustained, high query volume. If your team runs a handful of queries per day, on-demand is almost certainly cheaper. Calculate your actual monthly on-demand spend and compare it against the edition reservation cost before switching. Starting with autoscaling and no commitment is safer than locking into a multi-year deal.
- Ignoring how often a query runs. A $0.50 query is cheap. That same query scheduled every 5 minutes costs $144 per day. Review your scheduled queries and dashboard refresh intervals. Frequency is a silent cost multiplier.
BigQuery pricing vs cost optimisation
This page explains how BigQuery pricing works: what you are charged for, how the two pricing models differ, and how to estimate costs. That is different from actively optimising your spend.
Cost optimisation involves techniques like restructuring tables, rewriting queries to scan fewer bytes, materialising intermediate results, and choosing the right partitioning and clustering strategy. Those techniques build on the pricing knowledge from this page but go deeper into implementation.
Once you understand pricing, the BigQuery cost optimisation guide covers the practical techniques for reducing your bill. The performance optimisation page covers the SQL-level techniques (column selection, approximate aggregation, denormalisation) that reduce bytes scanned and improve query speed at the same time.
Summary
- BigQuery charges for storage and query compute independently. Storage costs $0.02/GB/month (active) and $0.01/GB/month (long-term, after 90 days untouched). The long-term discount applies automatically, per partition.
- On-demand pricing charges $6.25 per TB scanned, with 1 TB/month free. No charge for idle time, failed queries, dry runs, or cache hits. Best for variable, exploratory, or low-volume workloads.
- Capacity-based pricing provides dedicated slots through BigQuery editions (Standard, Enterprise, Enterprise Plus). You set a baseline and autoscaling maximum. Optional 1-year or 3-year commitments reduce per-slot cost but are not required.
- Start with on-demand. Switch to capacity-based pricing only when your monthly on-demand spend consistently exceeds the cost of an equivalent slot reservation.
- The biggest cost drivers are bytes scanned per query, table design (partitioning and column count), query frequency, and cache utilisation.
- Always run a dry run before executing a large query on an unfamiliar table. Use the console query validator or
bq query —dry_run. - LIMIT does not reduce bytes scanned. Use partition filters and column selection to reduce actual cost.
Frequently asked questions
How much does BigQuery cost per query?
BigQuery does not charge per query. On-demand pricing bills $6.25 per TB of data scanned, with the first 1 TB per month free. A query scanning 10 GB costs about $0.06. A query scanning 10 TB costs about $62.50. Your cost depends entirely on how much data the query reads, not how many queries you run.
Does LIMIT reduce bytes billed in BigQuery?
No. LIMIT only restricts the rows returned after BigQuery has already scanned the data. A query with LIMIT 10 scans and costs exactly the same as the same query without LIMIT. To reduce bytes billed, use partition filters and select only the columns you need.
When should I switch from on-demand to capacity-based pricing?
Capacity-based pricing makes sense when your monthly on-demand spend consistently exceeds the cost of an equivalent edition reservation. Calculate your average monthly TB scanned, multiply by $6.25, and compare that to the cost of a baseline reservation in your chosen edition. For variable, exploratory, or occasional workloads, on-demand is almost always cheaper.
What else besides queries can cost money in BigQuery?
Storage is the other main cost: $0.02/GB/month for active tables and $0.01/GB/month for long-term tables. Streaming inserts cost $0.01 per 200 MB. Other possible charges include BigQuery BI Engine, BigQuery ML model training, and cross-region data transfers. For most teams, storage and query compute account for the vast majority of BigQuery spend.
Is BigQuery expensive for small teams?
No. The free tier includes 1 TB of query scanning and 10 GB of storage per month. A small team running occasional analytical queries against well-partitioned tables can operate well within the free tier or spend only a few dollars per month. BigQuery becomes expensive when queries scan large amounts of data repeatedly without optimisation.