Updated 27 Oct 2026 • 6 mins read
What Is BigQuery? How It Works and How BigQuery Pricing Works
BigQuery is Google Cloud's serverless data warehouse: columnar storage on Google's distributed file system, SQL queries executed across pooled compute in slots, nothing to provision. This answer-first explainer covers how it works, the two compute pricing models and when each wins, storage pricing, worked examples, and the habits that keep BigQuery bills small.
BigQuery is Google Cloud's serverless data warehouse: a fully managed analytics database that stores data in a compressed columnar format on Google's distributed storage and runs SQL queries over it on pooled compute, scaling to petabytes without clusters to size, nodes to patch, or capacity to pay for while nothing runs. You load data, you write SQL, and Google supplies whatever compute the query needs for as long as it needs it. That model is why BigQuery is the simplest data warehouse to operate, and why its pricing, which charges by bytes scanned or by compute reserved, surprises teams who read the rate card as if it were a server.
This explainer answers what BigQuery is and does, how its architecture works, how its two compute pricing models and its storage pricing work and when each model wins, with rates from the official pricing page as of October 2026, and the habits that keep BigQuery bills small. For the rest of Google Cloud's rate card, see our Google Cloud pricing guide.
The short answer: BigQuery is Google Cloud's serverless, fully managed data warehouse. It stores data in Capacitor, a compressed columnar format, on Colossus, Google's distributed file system, independent of any compute, and runs standard SQL through the Dremel engine, which splits a query across thousands of workers measured in slots and reads only the columns the query touches. There is nothing to provision: storage scales with data and compute scales with queries. Pricing has two meters. Storage is about $0.02 per GB-month active and $0.01 long-term (unmodified for 90 days), or physical billing at roughly double per compressed byte. Compute is either on-demand, $6.25 per TiB of data scanned with the first TiB a month free, or capacity (editions), $0.04 to $0.10 per slot-hour for Standard, Enterprise, and Enterprise Plus with autoscaling and commitments at a discount. On-demand wins for light or well-optimized query volume; capacity wins for heavy, steady workloads, with a crossover near 100 TB scanned a month. Partitioning, clustering, and selecting only needed columns cut on-demand cost directly.
How BigQuery Works
BigQuery works by separating where data lives from what runs queries, and by never reserving either for you between queries.
| Component | What it is | What it means for cost |
|---|---|---|
| Storage: Capacitor on Colossus | Data stored in a compressed columnar format on Google's distributed file system, replicated and managed by Google | Billed per GB-month; a query reads only the columns it needs, so wide tables cost nothing to scan beyond the columns touched |
| Compute: Dremel and slots | A query is compiled into a tree of stages and executed in parallel across workers; a slot is one unit of CPU and memory | On-demand bills bytes scanned; capacity bills slot-hours reserved |
| Separation of storage and compute | Neither is tied to the other; data can be queried by any amount of compute, and compute is released when the query ends | Nothing bills while idle; storage and compute are optimized independently |
| Partitioning and clustering | Tables divided by a date or integer column and sorted within partitions by chosen columns | Queries that filter on those columns scan only matching partitions and blocks, cutting bytes scanned by 90 percent or more |
| Ingestion | Batch loads from Cloud Storage (free), the Storage Write API for streaming, Datastream and Dataflow for pipelines | Batch loads cost nothing; streaming bills per GB |
| Beyond SQL | BigQuery ML, geospatial and time-series functions, BI Engine for in-memory acceleration, federated queries, Iceberg and external tables | Each bills on its own meter or in slots |
How BigQuery Pricing Works
Two meters, storage and compute, and the compute meter comes in two models.
| Meter | Model | Rate (US, October 2026) | Notes |
|---|---|---|---|
| Storage | Logical, active | About $0.02 per GB-month | Uncompressed size; first 10 GB free |
| Storage | Logical, long-term | About $0.01 per GB-month | Automatic for tables unmodified 90 days |
| Storage | Physical (compressed) | About $0.04 active, $0.02 long-term per GB-month | Optional per dataset; cheaper for highly compressible data |
| Compute | On-demand | $6.25 per TiB scanned; first 1 TiB a month free | Bytes read by the query, not rows returned; up to 2,000 shared slots |
| Compute | Editions: Standard | $0.04 per slot-hour, autoscaled | No commitment; basic features |
| Compute | Editions: Enterprise | $0.06 per slot-hour; about $0.048 on 1-year and $0.036 on 3-year commitment | Most production workloads; advanced security and ML |
| Compute | Editions: Enterprise Plus | $0.10 per slot-hour; about $0.08 and $0.06 committed | Highest availability, regulatory features |
| Streaming | Storage Write API | About $0.025 per GB after 2 TiB free a month | Legacy streaming inserts higher |
| Other | BI Engine, BigQuery ML, data transfer, Omni | Per GiB-hour, per slot or per model, per GB | Separate meters |
On-Demand vs Capacity: Which Wins
On-demand charges for bytes scanned, so its cost depends entirely on how queries are written and how often they run; a well-partitioned table queried sparingly costs almost nothing, and an unpartitioned 10 TB table queried hourly costs about $1,500 a day. Capacity pricing charges for slots regardless of bytes, so its cost depends on how much compute you reserve and how fully you use it. The crossover for a typical mix is around 100 TB scanned a month, where $625 of on-demand compute meets roughly 100 slots of Enterprise capacity at $0.06 an hour on autoscale, but it moves with the workload.
| Workload | On-demand monthly | Enterprise capacity monthly | Winner |
|---|---|---|---|
| Ad hoc analysis, 5 TB scanned | $25 (after 1 TiB free) | Minimum autoscale slots: hundreds of dollars | On-demand |
| Dashboards scanning 40 TB | $244 | About $250 for 60 slots average | Even |
| Steady ELT and BI, 300 TB scanned | $1,869 | About $1,300 for 300 slots average; about $1,050 on a 3-year commitment | Capacity |
| Same ELT after partitioning cuts scans to 60 TB | $369 | About $1,300 (slots unchanged) | On-demand |
The last row is the point most comparisons miss: optimizing queries changes the answer. A workload that needs capacity pricing because it scans too much often needs partitioning and clustering more, and once it has them it may not need capacity at all.
A Worked Example
A product analytics team stores 20 TB in BigQuery and runs three dashboards refreshing hourly against an unpartitioned events table, plus about 50 ad hoc queries a day. Storage is about $400 a month. The dashboards scan the full table on each refresh, 24 times a day, 3 dashboards, 30 days: about 43,000 TB-scans, which would be absurd; in practice the table is 2 TB of events and each refresh scans it, so 2 TB times 72 refreshes a day times 30 is about 4,300 TB, about $27,000 a month at on-demand rates. That is the number that makes BigQuery look expensive.
Partitioning the events table by day and clustering by the columns the dashboards filter on cuts each refresh to about 20 GB; the same refreshes scan about 43 TB a month, about $270. Materializing the three dashboard aggregations and refreshing them from the day's partition cuts it further. The ad hoc queries, scanning about 10 TB a month, cost about $62. The team's compute bill falls from about $27,000 to under $400, and it never needed capacity pricing, only the two features BigQuery provides for exactly this.
How to Keep BigQuery Cheap
- Partition every large table by date or ingestion time and cluster by the columns queries filter on; this is the whole game under on-demand.
- Select the columns you need; BigQuery reads only those, and a query over a wide table that selects everything scans everything.
- Preview and dry-run queries to see bytes scanned before running them; set per-user and per-project byte limits.
- Use materialized views and the query cache for repeated aggregations.
- Let staging tables expire and let stable tables age into long-term storage pricing; consider physical billing for compressible data.
- Move heavy, steady workloads to capacity pricing with autoscaling and a commitment, after optimizing them.
- Keep BigQuery and the compute that queries it in the same region; cross-region reads bill egress.
How BigQuery Compares
| BigQuery | Snowflake | Amazon Redshift | |
|---|---|---|---|
| Model | Serverless; slots or bytes scanned | Virtual warehouses you size; credits per second | Provisioned clusters or serverless RPU-hours |
| Operations | None; fully managed | Size, suspend, and separate warehouses | Cluster sizing or serverless |
| Clouds | Google Cloud (Omni reads AWS and Azure data) | AWS, Azure, Google Cloud | AWS |
| Pricing shape | On-demand by data scanned or capacity by slot | By warehouse running time | By node-hour or RPU-hour |
| Best for | Google Cloud estates; teams wanting zero operations | Multi-cloud; strong SQL ecosystem | AWS-native estates |
Snowflake's pricing is covered in our Snowflake cost optimization guide and the three-way comparison in our Databricks versus Snowflake and Snowflake versus AWS versus Azure guides.
How Opslyft Helps
BigQuery's bill is driven by how queries are written, and the dashboard that rescans a table hourly shows on the invoice as one BigQuery line with no project, team, or dashboard named on it. Opslyft shows BigQuery compute and storage by project and team beside the rest of the GCP bill and flags a project whose scan volume jumped with the cause, the way it surfaced the idle resources behind Purplle's $200,000 first month on GCP; the levers for the whole GCP estate are in our GCP cost optimization guide.
Conclusion
BigQuery is a data warehouse with nothing to run: columnar storage on Google's file system, queries executed across pooled slots, and a bill that reflects either the bytes your queries scan or the slots you reserve. On-demand is cheap for well-written queries and ruinous for a dashboard that rescans a large unpartitioned table every hour; capacity is predictable for heavy steady workloads and wasteful for light ones. Partition, cluster, select columns, cache, let storage age, and choose the compute model after optimizing rather than before. For how BigQuery fits the rest of the Google Cloud bill, see our Google Cloud pricing guide; for estimating a GCP estate, our Google Cloud cost calculator guide.
FAQs
BigQuery is Google Cloud's serverless data warehouse: a fully managed analytics database that stores data in a columnar format on Google's distributed storage and runs SQL queries across it on pooled compute, scaling automatically to petabytes with no clusters to size, patch, or pay for while idle. It supports standard SQL, streaming and batch ingestion, built-in machine learning (BigQuery ML), geospatial and time-series functions, and federated queries over Cloud Storage, Bigtable, Spanner, and external lakehouse tables.
It separates storage from compute. Data is stored in Capacitor, a compressed columnar format, on Colossus, Google's distributed file system, independently of any compute. When a query runs, the Dremel execution engine breaks it into stages, distributes them across thousands of workers measured in slots (units of CPU and memory), reads only the columns the query touches, and assembles the result. Because storage and compute are separate, you pay for data stored and for compute consumed, and neither is reserved for you while nothing runs.
Two meters. Storage: about $0.02 per GB-month for active logical storage and $0.01 for long-term (tables unmodified for 90 days), or physical (compressed) billing at about $0.04 and $0.02. Compute, in one of two models: on-demand at $6.25 per TiB of data scanned by queries, first TiB a month free; or capacity pricing (editions) at $0.04, $0.06, or $0.10 per slot-hour for Standard, Enterprise, and Enterprise Plus, with autoscaling and one- or three-year commitments at a discount. Streaming inserts, BigQuery ML, BI Engine, and data transfer bill separately.
On-demand is cheaper for light, unpredictable, or well-optimized query volume, because you pay only for bytes scanned and the first TiB is free. Capacity pricing is cheaper for heavy, steady workloads, since a slot runs any number of queries for a fixed hourly rate; the crossover is typically around 100 TB scanned a month, and lower for workloads that scan large tables repeatedly. Many organizations run both: capacity for the core workload, on-demand for ad hoc.
On-demand cost is bytes scanned, so partition tables by date and cluster by the columns queries filter on, select only needed columns, use materialized views for repeated aggregations, set per-user and per-project byte limits, and cache results. For storage, let tables age into long-term pricing, choose physical billing for highly compressible data, and set table expiration on staging data. Move heavy, steady workloads to capacity pricing with autoscaling and a commitment.
A slot is BigQuery's unit of compute, a virtual CPU with memory, used to execute queries. On-demand queries draw from a shared pool of up to 2,000 slots per project at no per-slot charge; capacity pricing reserves slots for your workloads at a per-slot-hour rate, with autoscaling adding slots under load. Slot usage is the number to watch under capacity pricing, as bytes scanned is under on-demand.
All three are cloud data warehouses that separate storage and compute. BigQuery is fully serverless with no warehouses to size and bills on-demand by bytes scanned or by slot capacity; Snowflake runs virtual warehouses you size and start, billed in credits per second; Redshift runs provisioned clusters or a serverless option billed in RPU-hours. BigQuery is simplest to operate and most tightly integrated with Google Cloud; Snowflake is multi-cloud; Redshift is deepest in AWS.