PointFive helped a global consumer goods company cut BigQuery storage costs by 82% in just five days. By optimizing billing models across 435 datasets, the organization realized over $330K in annual savings, more than covering the cost of our platform.
Here is the whole workflow in the product, from the BigQuery footprint down to a single dataset and the fix. The sections below walk through the same path, with stills, if you would rather read it.
The opportunity was hiding in the billing model
BigQuery bills dataset storage one of two ways, logical or physical, and which costs less depends on the dataset and how it behaves over time. The cheaper option can be either one; PointFive flags datasets that should move in both directions.
In this environment, many datasets were still on a billing model that no longer made sense for how they were being used. PointFive analyzed storage behavior over time to identify which datasets could move to a more cost-efficient model, rather than recommending a switch based on a single snapshot.
435 datasets, and the pattern kept repeating
This wasn't one misconfigured dataset. Of the 435 datasets reviewed, 397 could reduce storage costs by at least 50% by switching billing models. For 220, the reduction was 80% or more. The largest dataset dropped nearly 90%.
The result was more than $330K in annualized savings from one type of optimization alone.
How the two billing models actually differ
BigQuery always stores data compressed on disk, no matter which model a dataset uses. The billing model only changes which bytes Google counts, and at what rate, when it prices the bill.
- Logical billing (the default) charges for the uncompressed size of the data, as if no compression applied, and includes time travel and fail-safe backup storage at no extra cost.
- Physical billing charges for the compressed bytes actually stored, at roughly double the per-GiB rate, and bills time travel and fail-safe storage separately.
Data that compresses well and mostly grows by appending new records is usually cheaper on physical billing: the compression discount outweighs the higher rate. Data that gets rewritten or deleted constantly is often cheaper on logical billing, because every rewrite accumulates time travel and fail-safe bytes that physical billing charges for. Neither model is "the right one" — it depends on how each dataset behaves, and that behavior changes over time.
Knowing when to switch matters too
Comparing logical and physical storage costs is relatively straightforward. Knowing whether today's cheaper option will remain the right one is harder.
Storage behavior changes. Pipelines grow or disappear. Data gets updated at different rates. Compression and the amount of historical data being retained change over time.
PointFive bases the recommendation on how a dataset behaves over time, not a single point-in-time calculation, so teams can act on the change with more confidence.
This matters because changing a BigQuery dataset's billing model isn't something you want to do based on a temporary pattern. Google locks a dataset into its new billing model for 14 days after a switch, so a recommendation built on one day's snapshot can leave you stuck on the wrong side of it. PointFive only recommends a switch when the same model has been cheaper on every day it measured.
From detection to savings in five days
Changing the billing model is a configuration change, not a data migration. Once PointFive identified the datasets that could benefit from a switch, the changes could be made without moving the underlying data.
Within five days, storage costs were down 82%, generating more annualized savings than the company pays for PointFive.
Why this can be easy to miss
Google gives teams the data and guidance to compare logical and physical storage billing, and recommends choosing a model based on usage patterns. But doing that across hundreds of datasets, continuously, is a different problem.
A billing decision that made sense when a dataset was created may not make sense six months later. Without continuously revisiting those decisions, the extra cost can simply remain part of the BigQuery bill.
PointFive continuously looks for those changes and identifies when there is enough evidence to recommend a different model.
One optimization is only part of the BigQuery bill
Storage billing is one place BigQuery waste can hide.
PointFive also identifies unused tables, pipelines writing to tables nobody reads, unnecessary storage in dev and staging, and anomalies down to the dataset and table.
The $330K opportunity came from one optimization in one environment. The bigger value is continuously looking across BigQuery to find what else is hiding in the bill and turn those opportunities into realized savings.
Frequently asked questions
How much can a BigQuery storage billing-model change save?
Results vary by environment. In one recent case, correcting the storage billing model across 435 BigQuery datasets in 26 GCP projects cut storage costs 82% within five days, generating more than $330K in annualized savings, enough to cover the cost of PointFive.
What's the difference between logical and physical storage billing in BigQuery?
Logical billing charges based on uncompressed data size. Physical billing charges based on compressed size, at a higher per-GiB rate, and bills time travel and fail-safe storage separately (logical includes those at no extra cost). Which costs less depends on the dataset, and the answer can change as its storage behavior changes over time.
How does PointFive decide when to recommend a billing-model switch?
PointFive analyzes storage behavior over time rather than relying on a single point-in-time comparison. This helps identify where a different billing model offers a durable cost advantage before recommending a change.
Is this safe to run without giving PointFive access to our data?
Yes. PointFive reads only BigQuery's built-in storage and usage metadata, never the contents of your tables.
What else does PointFive find in a BigQuery environment beyond storage billing?
PointFive identifies unused tables, pipelines writing to tables nobody reads, unnecessary storage in dev and staging, and storage anomalies down to a specific dataset or table.