This post breaks down BigQuery pricing into plain language: what compute, storage, streaming, editions, and commitments each actually charge you for, so you know what you’re looking at on an invoice before you try to change any of it.

As a finance or engineering leader, when opening the Cloud Billing console, you’ll find BigQuery split across half a dozen SKUs: on-demand or capacity compute, active storage, long-term storage, maybe a streaming line if any pipeline writes in real time. The total is clear enough. Which line item is driving it (and what it would cost to change) usually isn’t. BigQuery doesn’t bill like one product: it bills like several, and each one has its own rate, unit, and rules for how the price shifts over time.

Learn all about BigQuery Editions and Reservations. Download our white paper:

How does BigQuery pricing work at a high level?

BigQuery doesn’t have a single price. It bills a small set of categories independently, and your invoice reflects whichever ones your workloads actually touch:

• Compute: running queries, priced under whichever pricing model your project uses
• Storage: data at rest, split into active and long-term tiers
• Streaming: data written in real time, billed separately from query compute

Editions and commitments aren’t separate line items so much as terms attached to the compute line: editions set the rate and feature set, commitments set a discount in exchange for a fixed slot count. (The figures below reflect Google BigQuery pricing in 2026 — rates vary by region, so always check the official BigQuery pricing page for yours.)

This section is just the map for navigating BigQuery pricing. It doesn’t tell you which pricing model fits your workload; that decision, including when a mixed setup makes sense, is covered in the posts linked further down.

What are the two ways BigQuery charges for running queries?

BigQuery gives you two fundamentally different units to be billed on, and understanding both is the first thing to sort out before editions or commitments matter at all.

On-demand pricing charges per byte scanned: $6.25 per tebibyte (TiB) in US regions (check pricing for your region on cloud.google.com). Capacity-based pricing (reservations) charges per slot-hour consumed at $0.06 per slot-hour on Enterprise edition in US regions (check pricing for your region on cloud.google.com), regardless of how many bytes a query reads. These two BigQuery pricing models measure genuinely different things: one is metered by data volume, the other by compute time.

That’s the full billing mechanic. Which model actually costs less for a given workload is a separate question, one that depends on how much data your queries touch and how computationally heavy they are, not something this post tries to answer. What it means for your bill is simpler: if your project is on-demand, look for a per-byte charge tied to query volume. If it’s on a reservation, look for a steady per-slot-hour charge that doesn’t move with bytes scanned at all.

Learn more:
Comparing BigQuery Pricing Models: On-demand vs Capacity-based Reservations

Why isn’t there one capacity-based rate for BigQuery?

Once you’re on capacity-based pricing, the slot-hour rate itself isn’t fixed: it depends on which BigQuery Edition your reservation runs on. Standard, Enterprise, and Enterprise Plus carry different list prices in US regions ($0.04, $0.06, and $0.10 per slot-hour respectively; check pricing for your region on cloud.google.com), and the price difference tracks a real difference in what you get: Standard has no baseline slots and no commitment discounts, Enterprise adds both plus most production features, and Enterprise Plus layers on managed disaster recovery and compliance controls most teams never need.

The edition line on your bill isn’t a discount tier you can just downgrade into: it changes what your reservation is technically capable of, not just what it costs per hour.

Learn more:
BigQuery Editions Comparison: Standard vs Enterprise vs Enterprise Plus

What do “active” and “long-term” storage actually mean on your bill?

Storage is billed completely separately from compute, and it has its own aging mechanic that most people never notice happening. Any table or partition that hasn’t been modified for 90 consecutive days automatically drops to the long-term storage rate, roughly half the active rate (check current storage pricing for your region on cloud.google.com), with no change in performance or availability. That’s the first lever on BigQuery storage costs, and it’s automatic: any edit at all, including a full table rewrite on a scheduled job, resets the 90-day clock back to zero.

A second, entirely separate choice sits underneath that: whether a dataset is billed on logical (uncompressed) or physical (compressed) storage. Which one is cheaper for a given table depends on how well its data compresses and how often it changes, and the answer isn’t the same across every dataset in a project.

Learn more:
How to Choose the Right BigQuery Storage Pricing Model (Logical vs Physical) to Save up to 60%

What do you pay for when data streams into BigQuery in real time?

If any pipeline writes data into BigQuery as it arrives rather than in scheduled batches, that’s billed on its own, separately from both query compute and storage. Legacy streaming inserts are priced at $0.01 per 200 mebibytes successfully inserted; the newer Storage Write API charges $0.025 per gibibyte per month, with the first 2 tebibytes of monthly throughput per account free (check current ingestion pricing for your region on cloud.google.com).

This line is genuinely easy to miss when estimating total spend, because it doesn’t exist at all for teams running only batch loads and scheduled queries. It only shows up once a pipeline commits to near real-time ingestion, and at that point it becomes a fixed cost of the ingestion pattern itself, independent of how the resulting data gets queried afterward.

What’s different about a BigQuery slot commitment on your bill?

Every line item covered so far is pay-as-you-go: you’re charged for what you actually use, whether that’s bytes scanned, slot-hours consumed, storage held, or rows streamed. Slot commitments are the one exception. Committing to a fixed slot count for a 1-year term gets a 20% discount off the pay-as-you-go capacity rate; a 3-year term gets 40% (check current commitment terms on cloud.google.com).

Committed slots are billed whether or not a query ever touches them, for the entire term. That’s the trade: a lower effective rate in exchange for giving up the flexibility to simply stop paying if usage drops. On the bill itself, a commitment shows up as a steady charge that doesn’t respond to demand the way autoscaled or on-demand capacity does.

Learn more:
How to Configure BigQuery Baseline Slots and Slot Commitments

Putting the BigQuery bill back together

These line items don’t move in isolation, and they don’t all matter equally for every team. The mix that shows up on your bill tends to follow the shape of your workload.

Heavy ad hoc analysis, with analysts running unpredictable one-off queries, usually shows on-demand compute as the dominant line, since there’s rarely enough recurring volume to justify a reservation. Steady, scheduled pipelines running daily on a predictable cadence tend to shift the dominant cost to capacity-based compute, and often to commitments once that usage has been stable long enough to lock in. Any workload with a real-time ingestion component adds a streaming line that’s small individually but easy to underweight when it’s not on anyone’s radar. Storage, across all three shapes, is usually the smallest line unless the underlying data volume is genuinely large.

None of this tells you what to change. It’s a description of what typically drives the total, not a recommendation for your specific setup.

How does Rabbit break the bill down without the manual reconstruction?

Everything above answers “what is this line item.” The harder question, once you know that, is which line item can be optimized for your specific workload. That requires reconstructing usage patterns behind the invoice rather than just reading the SKUs.

Rabbit breaks a BigQuery bill down to this level automatically: per-job cost pulled from billing data, on-demand vs. capacity-based fit analyzed per project, and cost broken out by label and by account, so the “which line item, which team, which job” question doesn’t require pulling billing exports and reservation configs into a spreadsheet every time someone asks. That approach helped Nordstrom cut their BigQuery costs by 47%. See potential savings against your own usage: try the BigQuery Savings Calculator to get a rough savings estimate in a few minutes. Ready to dig deeper? Book a demo.