During my time at Looker, both before and after the Google Cloud acquisition, rising BigQuery costs and how to use it most effectively were constant topics among companies. Years later, long after my time at Google Cloud, BigQuery has evolved dramatically and stands today as one of the most powerful and scalable cloud data warehouses out there.

But with great power often comes a complex pricing model (or pricing model changes — if you are not new to BQ, you might still remember the change to Editions). From pay-as-you-go on-demand to multi-year capacity commitments, the way a company pays for BigQuery tells a fascinating story about its data maturity, operational philosophy, and technical prowess.

At Alvin we spoke with 100+ BQ clients in the last couple of months and after analyzing their feedback and countless usage patterns, we’ve identified six distinct “personas” that describe how organizations approach BigQuery pricing.

These six personas don’t represent a linear path. They’re archetypes of how different teams balance flexibility, predictability, and control. Even within one company, you’ll often find several coexisting.

Let’s see if you can recognize yourself in one of them?

‍

1. The On-Demand Native 🏞️

Who they are: This company lives entirely in the on-demand world, paying for every query based on the bytes scanned.

• Their Pattern: Their billing statement is dominated by the “BigQuery Analysis SKU.” They have no active slot reservations or commitments.

Why they do it:

• Simplicity: Reservations take some managing, sucking up internal resources. Without careful attention queries can end up being more expensive and less performant than running on-demand.
• Spiky Workloads: Reservations play particularly well with consistent workloads, but when query volume is volatile, the optimal approach can often be on-demand.
• The Challenge: Cost Volatility. The biggest issue is the lack of budget predictability. A single, poorly written query that scans terabytes of data can lead to a massive, unexpected bill. Also, given costs are directly proportional to bytes scanned, as data volumes increase, costs go up.

‍

2. The Capacity Curious 🤔

Who they are: This is an On-Demand Native who has made cost cutting a priority. They are now actively exploring a move to capacity-based pricing to see if this could be the answer to their problems.

• Their Pattern: While still 90%+ on-demand, you’ll see them using the BigQuery slot estimator, running pricing comparisons, and perhaps spinning up a small reservation with low autoscaler max slots on a development project to test the waters.

Why they do it:

• Cost Shock: A few expensive queries have made them realize the financial unpredictability of a pure on-demand model.
• Growing Pains: Their data platform is maturing, and want to put an end to the steady creep of their BigQuery bill.
• The Challenge: Analysis Paralysis. They know they need to make a change, but the complexity is daunting. Accurately forecasting slot usage, modeling the financial impact, and choosing the right amount of capacity requires significant analysis/time. Often, the analysis/experiments do not yield any savings, and would in fact indicate a cost increase, so they instead turn to traditional optimization techniques, such as partitioning tables and improving queries.

‍

3. The Hybrid Optimizer ⚖️

Who they are: The data team is large enough to commit dedicated resources to finding the optimal blend of BigQuery pricing models, and leverage a blend of on-demand and capacity for different projects based on what is the most efficient for those workloads.

Their Pattern: They have found a sweet spot with the autoscaler and assigned it to predictable projects, while other unpredictable workloads for ad-hoc analysis leverage on-demand

Why they do it:

• Best of Both Worlds: They run stable workloads on cost-effective capacity and leave unpredictable workloads on the flexible on-demand model.
• The Challenge: Constant Manual Overhead. This strategy is effective but manually intensive. It relies on a team member periodically reviewing usage data and deciding which projects should run on what. This process is often infrequent, reactive, and prone to human error. Workloads change, and a project that was once “spiky” might become predictable, leaving savings untapped for months. For certain projects, there may be clear cost or performance tradeoffs from choosing one of the pricing models.

‍

4. The Auto-Scaler Devotee ⚙️

Who they are: This company has gone all-in on capacity pricing and leverages the slot auto-scaler as their safety net.

Their Pattern: All projects are assigned to a reservation. They set a baseline number of slots from commitments and configure the auto-scaler to add more as demand spikes, or rely entirely on the auto-scaler to provision slots with no baseline.

Why they do it:

• On-Demand Aversion: They may have had a negative experience with a “runaway query” in the past and have sworn off on-demand pricing entirely.
• Convenience: The “set it and forget it” nature of the auto-scaler provides performance when needed without manual intervention.
• The Challenge: Paying a Premium for Peace of Mind. The auto-scaler is a powerful tool, but it’s often used as a costly crutch to handle peaks in demand. This convenience masks inefficiencies and leads to wasted spend, as the autoscaler will often overprovision slots when scaling up and down.

‍

5. The Enterprise Planner 🏢

Who they are: A large enterprise, fully committed to capacity pricing with significant 1-year or 3-year Commitments.

Their Pattern: They have a massive, pre-purchased pool of slots. Their internal focus is on governance and allocating these resources across different business units.

Why they do it:

• Budgetary Certainty: Large organizations need predictable, fixed costs for financial planning, and commitments provide the best possible price.
• Performance Guarantees: A large, dedicated pool of slots guarantees a high level of performance for critical applications.
• Status-Quo: For dedicated FinOps professionals, buying commitments is a well trodden path and gives them a quick win when it comes to meeting their cost reduction targets.
• The Challenge: Underutilization and Contention. The primary risks are waste and internal friction. Outside of peak hours, the always-on slots can end up being heavily underutilized, offsetting the discount. At the same time, when usage is high, teams can fight over the shared capacity, leading to query queuing and the “noisy neighbor” problem. Given the nature of commitments, a change in business strategy can leave multi-year commitments that outlive the workloads they were bought for.

‍

6. The Adaptive Automator 🥋

Who they are: The culmination of BigQuery FinOps best practices is continuous analysis, forecasting, and action — a perfect task for automation. Whilst we have seen a few companies building automation in-house, the time investment required to see meaningful results puts this out of reach for most data teams; and that’s where Alvin comes in.

Their Pattern: They let Alvin 1) allocate a mix of BigQuery pay-as-you-go pricing models to minimize cost at the query level 2) Tune reservations to minimize slot waste, ensuring the lowest possible cost per slot hour without compromising on performance 3) Rewrite queries in real time to achieve 5x-10x cache hits compared to the average in BigQuery.

Why they do it:

• Total Optimization: They squeeze every drop of value from BigQuery by applying the perfect pricing model to every workload, minimizing slot waste, and maximizing cache hits.
• Better things to do: Alvin fast-tracks optimization, with 30%-60% savings for the hour or so it takes to get going with Alvin, allowing teams to focus on value-adding work.
• Zero risk: The percentage of savings fee means Alvin only ever gives back to data budgets.
• The Challenge: Skeptical? If it all sounds too good to be true, then you can run a savings report in 5 minutes to see for yourself how much you would save with Alvin. So why not give it a slot.. sorry shot!

So… what is your persona? Did I miss one? Let me know!

Alvin isn’t meant to replace the great work data teams do everyday to run their BigQuery environments efficiently. Whichever persona you currently fit into, there are just some optimizations which aren’t possible without automation, and that’s where Alvin comes in.

If you are interested in learning more about how your company could benefit from automated BigQuery FinOps, feel free to connect with me on Linkedin and I’d be happy to share more!