This post summarizes how Lufthansa Group cut its BigQuery costs by 52%: the pricing question the team started with, the two moves that produced the savings (reservation planning first, then automation of the max slot setting), and what other teams can borrow from the approach. This post is a BigQuery cost reduction case study told as a story; the full case study has the complete record.

Read the Lufthansa Group case study:
Lufthansa Group’s Journey to Cut BigQuery Cost By 52% with Rabbit

Lufthansa Group is one of the world’s largest airlines, and when its platform team moved workloads to Google Cloud, reliability came first. For BigQuery, that meant every query ran on on-demand pricing. On-demand is a sensible default for unpredictable workloads, but Lufthansa’s queries were daily and repeating, which is the pattern where paying per byte scanned gets expensive. BigQuery had become one of the biggest cost drivers in the project.

The obvious exit, a Committed Use Discount (CUD) for one to three years, carried its own risk. Without clear visibility into usage patterns, committing meant guessing, and a wrong guess is a cost you live with for years.

Why is choosing between on-demand and BigQuery reservations so hard across many projects?

Lufthansa had multiple workloads spread across many GCP projects, each with its own usage pattern. That makes the on-demand versus reservations decision hard to answer once for the whole estate, because it is really a stack of smaller questions:

• Which projects run steady, predictable workloads, and which are spiky?
• How much capacity do the always-on jobs need, and how much is burst?
• Which pipelines cannot be starved, and which can wait a few minutes?
• What would a reservation look like per project, compared with staying on-demand?

There is no single threshold that answers these. The answers come from usage data per project, which is what the team was missing. For a framework on working through these questions yourself, see our pricing model comparison.

Learn more:
BigQuery Pricing Models Explained: On-Demand vs Capacity-Based

Optimizing reservations

Rabbit’s Reservation Planner generated multiple pricing scenarios across Lufthansa’s GCP projects to show which setup was most cost-effective, instead of forcing one estate-wide answer. It also recommended baseline and maximum slot settings for the reservations, backed by slot utilization metrics over recent periods: AVG, P90, P95, P99, and MAX.

Those percentiles are what turn a guess into a sizing decision. The average shows the steady level your always-on workloads need. P90 through P99 show how often and how high bursts reach. MAX is the single worst moment, which is rarely the number you want to pay for all month.

Implementing Rabbit’s recommendations brought a substantial reduction in Lufthansa’s BigQuery costs, and the next step took them further.

Moving past rightsized reservations

Even on capacity-based pricing, the bill does not track query work one-to-one. Per Google’s documentation on slot autoscaling:

• You are billed for the slots BigQuery scales, not the slots your jobs end up using, and that includes jobs that fail.
• Scale-up happens in 50-slot increments.
• Baseline slots are billed whether queries use them or not.

We break down what that does to your effective price per slot-hour in a separate post:

What Does a BigQuery Slot Hour Actually Cost?

The practical consequence is that the max slot setting is a single static number that has to cover your busiest hour and every quiet hour around it. Set it high enough to protect the heaviest pipeline and it stays that high when demand is low. Set it low to save money and you risk starving the pipelines that matter. A planner recommendation gets that number right for a recent window. But without automation, it cannot keep it right as workloads change.

Automating BigQuery optimization with Rabbit

That is the gap Rabbit Automation closes. Through the Max Slot Optimizer, Rabbit adjusts the reservation’s maximum slot setting continuously, updating every few seconds, so capacity follows real demand. Critical pipelines keep the headroom they need, and quiet periods run on less. Rabbit includes a safety buffer, recovers automatically if the service is interrupted, and lets you override the setting manually at any time.

Optimization at this level is opt-in; Rabbit’s default is recommendations that your team reviews and applies. Once Lufthansa activated Rabbit’s automation features, BigQuery costs dropped by a further 30% on top of the savings from reservation planning.

“They reached a 50% cost reduction, which we were not able to do on our own.”

Kunal Walia, Principal Solution Architect, Lufthansa Group

Optimizing Cloud Run for Lufthansa Group

The same pattern showed up outside BigQuery. When engineers deploy a new Cloud Run service, they usually cannot estimate CPU and memory precisely, so they pick generous values to stay safe. Cloud Run bills by vCPU-second and GiB-second, so every over-request becomes cost, used or not.

Rabbit lets teams set utilization recommendations by how critical an application is. Lufthansa tuned its critical applications to maximum usage plus a 100% buffer, a deliberately conservative setting, and Rabbit recalculated the CPU and memory requests for each Cloud Run service from there. Applying the recommendations reduced Lufthansa’s Cloud Run costs by 33%.

Cost savings with Rabbit

The savings stacked because the levers are connected. Pricing model, baseline, and max slots all pull on each other: sizing set the right shape for the reservation, and automation then kept the max setting matched to demand. BigQuery cost behaves like one interconnected system, which is why tuning one lever in isolation tends to leave savings on the table.

If you want the technical walkthrough, our talk recorded at the Google Summit 2025 in Zurich walks you through it:

What can other teams borrow from Lufthansa’s approach?

You do not need Lufthansa’s scale to apply the pattern. The same sequence works on a smaller estate:

1. Get usage data per project before choosing a pricing model or commitment. Visibility into usage patterns is what separates a confident commitment from a guess.
2. Treat baseline and max slots as two separate decisions. Baseline follows your steady load; the max setting follows how much burst you are willing to pay for.
3. Size from percentiles, not averages. AVG, P90, P95, P99, and MAX tell you different things about the same workload.
4. Plan for the max setting to change. A number that is right today drifts as pipelines and data volumes grow, so it needs a recurring review or automation.
5. Measure each lever separately. Lufthansa could point to 30% from automation within the 52% total, helping the team know where savings came from and whether they hold.

Doing steps 1 to 4 by hand is possible, but it means repeating the analysis and the configuration changes every time workloads shift. Rabbit handles that loop: Reservation Planner produces the sizing recommendations, and Rabbit Automation keeps the max slot setting matched to demand once you enable it.

For a second enterprise example with a different mix of levers,
see how Nordstrom cut its BigQuery spend by 47%:
Post-migration BigQuery at Nordstrom: From rising slot waste to 47% lower spend

Want to see what Rabbit’s BigQuery optimization features would do on your estate? Book a demo and we will walk through your own usage data. If you would like a first estimate before talking to anyone, try the BigQuery Savings Calculator, or read the full Lufthansa Group case study.