A growing cloud bill is not proof that a system needs an expensive rewrite. Sometimes the infrastructure is paying for capacity that the workload no longer needs. Sometimes the database needs tuning before smaller resources become viable.
An anonymous metaverse project running on Google Cloud illustrates the second possibility.
Big Bad Byte worked on resource rightsizing and database tuning for this project. The owner-reported monthly Google Cloud spend went from approximately €36,000 to €6,000, while the user experience was not negatively affected. That is a reported €30,000 monthly difference, or roughly 83.3% less spending at the observed monthly run rate.
If maintained for a full year, the difference would correspond to €360,000. That is a run-rate calculation, not a claim that €360,000 was already realized over twelve months.
We can substantiate the general workstreams and the reported before-and-after cost. We are not publishing the client's identity, individual instance sizes, database engine, billing exports or latency traces because those details are not part of the approved public evidence.
Why a cheaper VM is not a complete FinOps strategy
Right-sizing asks a more useful question than "Which instance costs less?"
It asks what capacity a service needs under the traffic and data conditions that actually matter. For some workloads the answer is straightforward: resources were provisioned with too much headroom and average utilization stayed low. For others, shrinking the VM before fixing a query or data-access pattern turns an acceptable system into an overloaded one.
Resource cost, application performance and database behavior must be considered together.
In the metaverse engagement, the reported work combined resource rightsizing and database tuning. These are the only technical interventions confirmed for this case. We should not retrospectively claim a particular GKE topology, storage tier, SQL engine, autoscaler policy, cache design or network optimization without project evidence.
A useful way to investigate cloud spend
The most valuable first deliverable is not a savings promise. It is a traceable baseline.
For a Google Cloud workload, teams can investigate costs using Cloud Billing reports and detailed billing exports. Google's Cloud Billing export documentation explains how usage, costs and resource-level details can be analyzed in BigQuery. If the workload uses GKE and an allocation by cluster or workload is required, the appropriate GKE cost-allocation configuration must also be considered.
The baseline should answer three practical questions:
- Which services, projects and usage categories account for most of the spend?
- Which changes in usage or pricing explain the variation between comparable periods?
- Which resources are tied to customer-facing work, and which costs persist regardless of useful demand?
A project-wide before-and-after total is useful, but not enough to explain causality. Credits, reservations, one-off migration charges, taxes, billing-period length and changes in activity can all affect the apparent difference.
In a new engagement, we would explicitly document those conditions before using a percentage in a business case. That is a recommended methodology, not a claim about the historical client's billing methodology.
Test the database before removing capacity
Database optimization is not equivalent to reducing instance size.
A system can consume substantial CPU because queries scan more data than necessary, indexes are ineffective, or concurrency creates repeated work. A smaller machine under the same query pattern may be cheaper on the invoice but much slower for the people using it.
The sensible sequence is to understand the relevant query workload, identify expensive operations, test changes and then revisit resource sizing. In the anonymized Google Cloud story, database tuning was part of the work that accompanied rightsizing, but the available proof does not identify specific queries or tuning parameters.
A useful acceptance test would compare representative request paths before and after a change. It should cover peak behavior, error rates and latency distributions rather than treating the mean CPU graph as proof that user experience is unchanged.
That distinction matters when a project reports lower spend without negatively affecting user experience. The phrase communicates the reported outcome; it does not authorize us to invent a measured p99 number.
Calculate savings without inflating the result
Here is the scope of the approved customer-reported figures:
| Metric | Reported figure |
|---|---|
| Monthly Google Cloud spend before | €36,000 |
| Monthly Google Cloud spend after | €6,000 |
| Difference at observed monthly run rate | €30,000 |
| Reduction versus the reported starting month | ~83.3% |
| Annualized equivalent if sustained | €360,000/year |
The monthly difference should not be added to the annualized number as though they were separate benefits. And the annualized number should not be described as realized annual savings without evidence of the duration.
These are client-reported figures authorized for an anonymous account, not independently audited invoices.
What should happen after the first reduction?
FinOps is not a one-off cleanup. Without ownership and feedback, resources drift back toward their old size, databases accumulate new work, and teams lose sight of whether savings survived product growth.
A practical follow-up would track:
- Monthly spend and actual workload activity together, not just total invoice.
- Resource changes, their owners and rollback plans.
- Database performance signals around major releases.
- Headroom and recovery requirements after rightsizing.
- Whether the new cost baseline holds over multiple billing periods.
This is not an assertion that all five controls existed in the original project. It is the operational discipline we recommend when evaluating a similar change.
What this case means for engineering leaders
A cloud bill should be tied to the work a system delivers, not to an assumption that higher spending buys better performance.
For this metaverse workload, the owner-reported result was a Google Cloud bill reduced from €36,000 to €6,000 per month through rightsizing and database tuning, without a negative user-experience impact. We are not claiming those savings are typical for other companies.
If you want to understand where your own cloud spend is coming from, the first step is a workload and cost baseline with performance requirements attached. That is how Big Bad Byte approaches cloud cost optimization: identify a real cost driver, implement a defensible change and measure what happened.