The Biggest Lie About BigQuery: “It Is Expensive.”
One sentence appears in almost every discussion about BigQuery.
“BigQuery is expensive.”
Sometimes it comes from developers.
Sometimes from managers.
Sometimes even from cloud architects.
The sentence sounds convincing because everyone has seen screenshots of unexpectedly high cloud invoices. One poorly written query scans dozens of terabytes. Someone forgets a filter on a production table. A dashboard refreshes every minute instead of every hour. At the end of the month, finance asks uncomfortable questions.
The conclusion seems obvious.
BigQuery must be expensive.
The interesting part is that the same conclusion could be made about almost any technology if it is used without understanding how it works.
A sports car is expensive if you drive it with the handbrake engaged.
A cargo aircraft is expensive if you use it to deliver one envelope.
BigQuery is no different.
The platform is not expensive by design.
It is brutally honest about the work your architecture asks it to perform.
Understanding this changes the conversation completely.
The question is no longer, “Why is BigQuery expensive?”
It becomes, “Why is our architecture making BigQuery work so hard?”
BigQuery Does Not Charge for Existing
One of the biggest differences between BigQuery and traditional databases is psychological.
Most relational databases charge you for having infrastructure.
Whether users submit one query or one million, the virtual machine is running.
CPU is reserved.
Memory is allocated.
Storage is attached.
You pay because the infrastructure exists.
BigQuery follows a different philosophy.
By default, it does not charge because a server is waiting for you.
It charges because a distributed computing system actually performs work.
That distinction is subtle but extremely important.
Imagine two warehouses.
The first rents you an entire building.
You pay every month whether the warehouse is full or empty.
The second warehouse lets you store your goods almost indefinitely, but every time someone asks workers to search through the inventory, you pay for the effort required.
Neither model is better.
They simply optimize different business cases.
BigQuery belongs to the second category.
The invoice reflects activity, not ownership.
Every Query Is a Construction Project
One reason BigQuery feels unusual is that people imagine SQL as something lightweight.
They write a query.
Press Run.
Receive a result.
The process appears almost instantaneous.
Behind the scenes, something much larger is happening.
When BigQuery receives a query, it does not simply execute SQL.
It builds an execution plan.
It identifies which tables are involved.
It determines which columns are actually required.
It decides how the work can be divided into parallel stages.
It allocates distributed workers.
It schedules data movement between execution nodes.
It performs joins, aggregations, filtering and sorting.
Finally, it merges partial results into a single response.
In other words, every analytical query temporarily creates a distributed computation pipeline.
The complexity of that pipeline depends almost entirely on the shape of the data.
This is why two SQL statements of similar length can have dramatically different costs.
The number of characters in a query is irrelevant.
The amount of work hidden behind those characters is what matters.
Scanning Data Is Not the Same as Using Data
Here is one of the most misunderstood concepts in BigQuery.
People often believe they pay for the amount of data returned.
They do not.
They pay for the amount of data that must be examined.
Suppose you have a table containing one hundred billion user events collected over five years.
Your query returns only twenty rows.
That sounds inexpensive.
Unfortunately, if BigQuery had to examine the entire table before finding those twenty rows, the work has already been done.
Returning twenty rows is cheap.
Reading one hundred billion rows is not.
This explains why experienced data engineers spend so much time discussing table design.
Good architecture reduces the amount of information BigQuery must inspect before it discovers the answer.
That is a completely different optimization strategy from traditional database tuning.
Partitioning Does Not Make BigQuery Faster
This statement surprises many engineers because almost every introductory guide says the opposite.
Partitioning is often described as a performance feature.
That is only partially true.
Imagine a library containing ten million books.
Now imagine that all books are randomly scattered across the floor.
Finding books published in 2024 would require searching the entire building.
Now organize the same library by publication year.
The books themselves are not easier to read.
The librarian simply knows which shelves can be ignored.
Partitioning works exactly like this.
When a table is partitioned by date, BigQuery can immediately eliminate large portions of the dataset before scanning begins.
The execution engine performs less work because less data enters the computation pipeline.
Queries often become faster, but speed is a consequence.
The real benefit is that unnecessary work never happens.
Less work means fewer bytes scanned.
Fewer bytes scanned mean lower cost.
Partitioning is therefore best understood as a mechanism for reducing the search space rather than accelerating processors.
Clustering Solves a Different Problem
Many engineers confuse partitioning and clustering because both reduce scanned data.
They achieve this in completely different ways.
Partitioning divides a table into large logical sections.
Clustering organizes data inside those sections.
Imagine a warehouse.
Partitioning decides which room contains today’s deliveries.
Clustering decides how boxes are arranged inside that room.
If every shipment for the same customer is stored close together, workers spend less time searching.
BigQuery behaves similarly.
When filtering by clustered columns, the execution engine often skips large storage blocks because it knows they cannot contain matching values.
Again, the processors are not working faster.
They are simply working less.
Architects should always remember this distinction.
Optimization in BigQuery is rarely about increasing computing power.
It is about preventing unnecessary computation.
The Most Expensive Query Is the One Nobody Notices
Large exploratory queries attract attention because they appear immediately in billing reports.
Silent waste is far more dangerous.
Consider a dashboard refreshing every minute.
Each refresh scans only a few gigabytes.
Individually, the cost seems trivial.
Now multiply that query by sixty minutes, twenty-four hours, thirty days, several dashboards and dozens of users.
A tiny inefficiency becomes one of the largest items on the monthly invoice.
This is why FinOps is fundamentally an architectural discipline rather than an accounting exercise.
Cloud costs rarely explode because of one catastrophic decision.
They grow through thousands of perfectly reasonable decisions repeated automatically.
Cost Optimization Starts Long Before SQL
Many organizations create optimization teams after receiving an unexpectedly large invoice.
They begin rewriting queries.
Adding filters.
Removing joins.
Reducing result sets.
These improvements help.
But they often address symptoms instead of causes.
Real cost optimization begins much earlier.
It begins when architects decide how raw data will be partitioned, how events will be modeled, how frequently dashboards refresh, how historical information is retained, and how analytical workloads are separated from operational systems.
By the time analysts start writing SQL, most of the important financial decisions have already been made.
That is why experienced architects say that the cheapest query is not the most efficient one.
It is the query that was made inexpensive by a well-designed architecture.
Architect’s Notebook
BigQuery bills computation, not curiosity.
Every unnecessary byte scanned is unnecessary work performed by thousands of distributed workers.
Partitioning reduces the search space.
Clustering reduces the amount of data examined within that space.
The biggest cloud invoices rarely come from complicated SQL.
They come from architectures that ask simple SQL to perform enormous amounts of unnecessary work.
Closing Thought
When finance says, “BigQuery is too expensive,” the natural reaction is to optimize queries.
An experienced architect asks a different question.
“Why is our architecture forcing BigQuery to read so much information in the first place?”
Because in analytical systems, the cheapest optimization is almost always the one made before the first query is ever written.