BigQuery separates storage cost from query cost, and the storage side has two decisions worth real money. First, the long term tier: any table or partition that has not been modified for 90 consecutive days automatically drops to a long term storage rate that is roughly half the active rate, with no change to performance or availability and no action required. Second, the billing model: a dataset can be billed on logical bytes, the uncompressed size of your data, or on physical bytes, the compressed size BigQuery actually stores including time travel and fail safe. Physical billing has a higher per gigabyte rate but charges the far smaller compressed footprint, so for compressible data it usually wins. Getting both right, and pruning what you do not need, is most of storage optimization.
This sits in the GCP data cluster with on demand versus capacity pricing in BigQuery and scheduled queries and cost discipline. Read those for the query side of the bill, where the other half of BigQuery spend lives.
How does the long term storage rate work?
It is automatic and it is about modification, not access. If a table or an individual partition goes 90 consecutive days without being modified, its storage price drops to the long term rate, roughly half the active rate. Querying the data does not reset the clock; only changing it does. The practical consequence is subtle. A table you append to daily keeps its whole storage in the active tier, while the same data split into date partitioned tables lets old partitions age into long term independently as they stop being written. Partitioning by time is therefore not only a query cost technique but a storage cost technique, because it lets cold partitions fall to the cheaper rate while the recent partition stays active.
Logical or physical billing, which should you pick?
Logical billing charges the uncompressed size of your data at a lower per gigabyte rate. Physical billing charges the compressed size BigQuery actually stores at a higher per gigabyte rate, and the compressed footprint also includes time travel and fail safe storage. The decision turns on compressibility. Highly compressible data, typical of structured analytics tables, can compress several times over, so paying the higher physical rate on a much smaller number usually costs less than the logical rate on the full uncompressed size. Poorly compressing data, or datasets with very long time travel windows, can tip the other way. Estimate both for your largest datasets before switching, because the choice is made per dataset and is worth getting right where the data is big.
What storage are you paying for without realizing?
Three quiet lines. Time travel keeps a window of historical data so you can query or restore the recent past, and under physical billing that history is part of what you pay for, so a long time travel window on a large, frequently changed table adds real cost. Fail safe retains data for recovery beyond time travel and also counts under physical billing. And plain forgotten tables: intermediate results, abandoned experiments, and duplicated exports that no lifecycle process ever removes. Trim the time travel window to what your recovery requirement actually needs, and run a periodic sweep for tables nobody queries.
How do you cut storage without losing data?
Sequence it. Partition large tables by time so cold partitions age into long term automatically and queries scan less. Estimate logical versus physical billing on your biggest datasets and switch the ones where compression clearly favours physical. Set time travel windows deliberately rather than leaving the maximum everywhere. And expire or archive intermediate and abandoned tables on a schedule. Every one of these keeps the data you need and removes the cost you do not, which is the whole game in storage optimization: you are not deleting value, you are stopping paying full active rates for cold, compressible, or forgotten bytes.
A worked example
An indicative Fortune 500 retailer carried a large BigQuery footprint billed logically, with several huge append only event tables and maximum time travel windows everywhere. The event tables held all their data in the active tier because daily appends kept the whole table modified. The team repartitioned the event tables by date so old partitions aged into long term, estimated physical billing on the largest highly compressible datasets and switched them, and trimmed time travel to the recovery window the business actually required. Storage spend dropped substantially with no data lost and no change to query behaviour. Figures are verified against billing data and anonymised.
Frequently asked questions
When does BigQuery long term storage apply?
Is physical or logical BigQuery storage billing cheaper?
What hidden storage am I paying for in BigQuery?
Where this fits the cost review
Storage is the steady, unglamorous half of the BigQuery bill, and the long term tier plus the physical billing choice are levers most teams never deliberately pull. We run that review as an independent buyer side advisory across AWS, Azure, GCP, and OCI, with zero provider commissions and a guarantee: we reduce your cloud spend or we reimburse our service fee.
For monthly buyer side analysis delivered to your inbox, subscribe to The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.