Commit the BigQuery Baseline, Meter the Variable Top
BigQuery sells three editions at $0.04, $0.06, and $0.10 per slot hour, and only the Enterprise tiers buy down to a 1 or 3 year commitment. Size the commitment to your verified baseline and the discount band runs 20 to 40 percent. Oversize it and you fund idle slots for three years.
Prepared by Redress Compliance · June 2026 · Representative BigQuery estate scenario (benchmark scenario, not a quote)
Executive Summary
BigQuery cost is governed by two decisions made before any contract: which edition runs each workload, and how much capacity you commit versus meter. Get those two right and the negotiation is almost done. Get them wrong and no discount recovers the loss.
The pricing is public and unforgiving. On demand scanning bills $6.25 per TiB with no ceiling. Capacity bills by the slot hour: Standard $0.04, Enterprise $0.06, Enterprise Plus $0.10. The committed use discount applies only to the Enterprise tiers, a 20 to 40 percent buy down from list.
Storage is a second, quieter lever. Logical billing charges uncompressed bytes at $0.02 active and $0.01 long term. Physical billing charges compressed bytes at $0.04 active and $0.02 long term, and on a well compressed estate it cuts the storage bill in half.
The trap is the commitment floor. A committed slot is billed whether or not it runs a query. Buyers who commit to peak, or lock three years for the deepest sticker discount, convert a discount into a stranded cost. The buyer side move is to commit only the verified baseline and meter the rest.
This paper gives you the governance cycle, the verified baseline method, the edition and slot model, the storage tier map, the commitment band math, the five contract clauses, the discount benchmarks, the counter moves Google will run, and the BATNA with side letter language.
What does the BigQuery cost governance cycle look like?
The governance cycle is a twelve week sequence that ends with a signed commitment sized from your own data, not the Google account team forecast. It runs in three phases: measure, model, then negotiate.
Most buyers skip straight to negotiate because the renewal date is close. That is the error. Whoever holds the verified baseline anchors the commitment, and the baseline takes weeks of telemetry to build. Start the clock at least one full quarter before any commitment date.
Build the verified baseline
Pull slot consumption, bytes scanned, and storage by dataset from the INFORMATION_SCHEMA views. Separate steady base load from burst. Reconcile to the billing export.
Map editions and the slot band
Assign each workload to an edition. Model baseline commit versus autoscaling versus on demand. Set the storage billing model per dataset. Price every option.
Commit at the bottom of the band
Take the modeled commit to the table with an active alternative. Lock the five clauses. Sign only the verified baseline at one year, never the forecast at three.
Who owns each phase
- Data platform team: owns the telemetry, the workload to edition mapping, and the storage billing decision per dataset.
- FinOps or cost engineering: owns the baseline reconciliation and the commit band model.
- Procurement: owns the clause language, the benchmark position, and the alternative that sets the discount.
How do you build a verified BigQuery entitlement baseline?
The verified baseline is the slot, scan, and storage profile that survives Google scrutiny because it comes from BigQuery's own metadata, not an estimate. It is the single most important artifact in the negotiation.
Build it from the system views, not the console dashboards. The dashboards round and smooth. The INFORMATION_SCHEMA.JOBS view gives you per query slot milliseconds and bytes billed. The TABLE_STORAGE view gives you active and long term bytes, logical and physical, per table.
The four data sets the baseline needs
- Slot consumption profile: average and peak slots by hour and day, split into a steady base and a burst layer. This sizes the commitment.
- Bytes scanned profile: on demand TiB per month by project, to price the on demand alternative against capacity.
- Storage footprint: active versus long term, logical versus physical, by dataset, to set the storage billing model.
- Workload classification: production, ad hoc, dev and test, and pipeline, so each lands in the right edition.
How do the three BigQuery editions and the slot model work?
BigQuery sells compute three ways, and the cheapest sticker rate is not the cheapest outcome. Standard is $0.04 per slot hour but cannot buy a commitment, so a steady workload pays full rate forever. Enterprise at $0.06 buys down to $0.048 at one year and $0.036 at three years.
That is the first counterintuitive point. For a steady production workload, Enterprise at a three year commit ($0.036) beats Standard at list ($0.04) and carries more features. Standard is a burst and ad hoc edition, not a production one.
Enterprise at a three year commitment ($0.036) undercuts the Standard list rate ($0.04, red line) and adds features. Green bars are committed rates. Numbers match Section 3 and the commitment model in Section 5.
What each edition is actually for
| Edition | List slot rate | Commitment | Right fit |
|---|---|---|---|
| Standard | $0.04 / slot hour | None available | Burst, ad hoc, dev and test on autoscaling |
| Enterprise | $0.06 / slot hour | 1 yr $0.048, 3 yr $0.036 | Steady production with a verified baseline |
| Enterprise Plus | $0.10 / slot hour | 1 yr and 3 yr available | Regulated estates needing CMEK, residency, advanced controls |
The slot reservation model has two layers. Baseline slots are always on and billed continuously. Autoscaling slots scale up in increments of 100 when the baseline is exhausted and bill at the pay as you go rate. Commit the baseline. Never commit the autoscaling layer.
How do you map the BigQuery storage tiers to cut the bill?
Storage is billed on two axes that buyers conflate: active versus long term, and logical versus physical. Each axis is a separate lever, and the physical lever is the one most estates leave on the table.
- Active versus long term: any table partition not modified for 90 days drops automatically to the long term rate, a 50 percent cut. This is per partition, not per table.
- Logical versus physical: logical bills uncompressed bytes at $0.02 active and $0.01 long term. Physical bills compressed bytes at $0.04 active and $0.02 long term.
Physical billing doubles the per gigabyte rate but charges the compressed footprint. On an estate that compresses better than two to one, physical wins. Most analytical data compresses three to five to one, so the saving is real.
Worked storage model on the representative estate
Take a 1,000 TB logical estate, 70 percent active and 30 percent long term, compressing four to one. The table below prices the current logical billing against a physical switch. This is a benchmark scenario, not a quote.
| Tier | Logical billing (current) | Physical billing (optimized) | Annual cost |
|---|---|---|---|
| Active | 700 TB @ $0.02/GB = $14,000/mo | 175 TB @ $0.04/GB = $7,000/mo | $84,000 vs $168,000 |
| Long term | 300 TB @ $0.01/GB = $3,000/mo | 75 TB @ $0.02/GB = $1,500/mo | $18,000 vs $36,000 |
| Storage total | $17,000 / month | $8,500 / month | $102,000 vs $204,000 |
The physical switch halves the storage bill, from $204,000 to $102,000 a year, with no change to data or queries. The compression ratio is the whole story, so measure it per dataset before switching.
How do you size the BigQuery commitment band?
Size the commitment to the verified always on baseline, not the peak and not the forecast. The baseline is the slot floor your steady production load never drops below. Everything above it is variable and belongs on autoscaling or on demand.
On the representative estate the verified baseline is 2,000 Enterprise slots running continuously, with a variable layer that averages a further 1,000 slots during business hours. The model below prices the current on demand spend against the committed baseline plus metered top.
| Compute layer | Current (on demand) | Optimized (editions) | Annual saving |
|---|---|---|---|
| Predictable base load | $1,344,000 | $841,000 (2,000 slots, Enterprise 1 yr CUD) | $503,000 |
| Variable / burst load | $576,000 | $360,000 (autoscaling, pay as you go) | $216,000 |
| Compute total | $1,920,000 | $1,201,000 | $719,000 |
The committed baseline math checks out: 2,000 slots at $0.048 per slot hour across 730 hours a month is $70,080 a month, or $841,000 a year rounded. The variable layer stays metered so you never pay for idle capacity.
Committing the verified 2,000 slot baseline at the one year rate and metering the rest cuts annual compute 37 percent, from $1,920k to $1,201k. Bars match the Section 5 table exactly.
Where the common advice on BigQuery commitments is wrong
The standard Google and partner pitch is to move the estate onto Enterprise Plus slots and lock a three year commitment for the deepest sticker discount. We disagree. In the BigQuery estates we have modeled, a three year peak sized commit strands 15 to 30 percent of committed slots as idle capacity, billed whether or not they run a query.
The buyer side move is to commit only the verified baseline, take one year not three, and let autoscaling absorb the variable top. You give up a few points of headline discount and keep the right to reprice every twelve months as your workload and Google's rate card both move.
Which five contract clauses protect a BigQuery commitment?
The list price is public, so the negotiation is won in the terms, not the rate. Five clauses decide whether the commitment is a budget floor you control or a trap that bills idle slots.
| Clause | What it does | Why it matters |
|---|---|---|
| Baseline flex down | Right to reduce committed baseline slots at each anniversary without penalty | Stops a one time peak from locking three years of idle capacity |
| Edition portability | Move committed slots between Enterprise and Enterprise Plus reservations | Lets dev and prod rebalance without forfeiting the commitment |
| Rate hold on overage | Autoscaling and on demand billed at the committed effective rate, not list | Caps the variable layer so a burst month does not reprice at full list |
| Storage model election | Right to switch logical to physical billing per dataset during the term | Preserves the 50 percent storage lever as compression profiles change |
| Marketplace and migration credit | Documented Google migration funding and committed use of partner credits | Offsets first year cost and funds the cutover from on demand |
Each clause is a known Google concession, not a stretch. Bring them as a drafted markup, not a request, and the account team negotiates the edges rather than the principle.
What discount benchmarks should you expect across scenarios?
The benchmark band depends on the scenario, not the logo. A fresh migration with an active alternative pulls a different number than a passive renewal. The cards below set the range we see, with the source noted.
Enterprise one year to three year commitment off the $0.06 list slot rate, the most reliable structural saving.
Moving a steady workload off $6.25 per TiB on demand onto a right sized committed baseline.
Switching well compressed datasets to physical billing, on a three to five to one ratio.
Incremental migration funding or commit credit on a larger Google Cloud agreement, scenario dependent.
Benchmark ranges: Redress Compliance advisory engagement file, 2024 to 2025. Ranges are scenario dependent and not a quote.
Bar start to end marks the low and high of each benchmark band. Numbers match the percent cards above. Source: Redress Compliance advisory engagement file, 2024 to 2025.
How do you counter the standard Google negotiation tactics?
The Google account team runs a predictable playbook on a BigQuery commitment. Each move has a buyer side counter that costs nothing but preparation.
| Google tactic | What they say | Buyer side counter |
|---|---|---|
| Forecast inflation | Commit to projected growth for the deepest discount | Commit the verified baseline only; growth rides autoscaling at the same rate |
| Three year anchor | The real saving is only at three years | Price one year against three; keep the repricing right and the lower idle risk |
| Enterprise Plus default | Standardize the estate on Enterprise Plus | Map features per workload; most production needs Enterprise, not Plus |
| Quarter end urgency | This pricing expires at the fiscal quarter | Set your own date; the baseline does not change because Google's quarter ends |
| Storage left alone | Focus the deal on compute slots | Put physical billing and partition aging in scope; it is half the bill |
What is the BATNA and the side letter language?
The discount sits at the top of its band only when Google believes you have a live alternative. The BATNA does not need to be a full migration plan, but it must be specific and current.
- On demand fallback: price the estate at $6.25 per TiB and show you can stay on demand for the variable layer indefinitely. It caps how hard Google can push a commit.
- Cross cloud alternative: a costed comparison against Snowflake, Databricks, or AWS Redshift for the analytical workload, even at a high level, changes the tone.
- Multi year ramp option: a smaller first year commit with a documented option to grow, so Google earns the larger commitment rather than locking it up front.
Capture the protections in side letter language that survives the order form. Sample wording we use, to be tailored by counsel:
Commit the verified baseline at one year, meter everything above it, and put storage billing in scope. BigQuery cost is set by the edition and commitment decisions, not the headline discount. Size from your own telemetry and the rest follows.
- Before the commitment date: build the verified slot, scan, and storage baseline from INFORMATION_SCHEMA, map each workload to an edition, and model baseline commit versus metered top.
- At signature: commit only the always on baseline at the one year rate, lock the five clauses, switch well compressed datasets to physical billing, and stand up a live alternative so the discount sits at the top of its band.
We bring the baseline model, the clause language, and the benchmark data to every Google Cloud renewal we advise. We are glad to tie a meaningful part of the fee to delivered value.
