How Bonsai Saved A Customer $48,000 in Cloud Spend

Throwing more resources at a slow system is the obvious move. Unfortunately, it's also often the wrong one. The harder truth is that some problems stay hidden until they're expensive, and running Elasticsearch yourself means you're also responsible for knowing what you don't know. That’s where Bonsai comes in. We’ve seen these patterns across enough clusters to recognize them fast, and we have the expertise to fix them. The Bonsai team identified two structural issues this customer had been scaling around for months. Fixing them, rather than adding to them, cut costs 35% and read latency 75%.

The situation

The customer runs an API service. Search latency isn't just their problem — it cascades directly to their customers, and their customers' customers. They came to us with a cluster that was slow on reads and writes, and getting expensive to run.

The initial instinct was the right one: add resources. CPU was chronically high. We scaled up the cluster. Things improved marginally, but not enough. The symptoms kept coming back.

That's usually a signal: when a system doesn't respond to more resources, it's time to dive deeper into the issue.

What we found

After a few conversations and a close look at the cluster, two problems emerged. They were independent, but they compounded each other in a way that made the cluster behave far worse than either one alone would explain.

The first was about how work was being distributed. The cluster had more capacity than it was using. Half the infrastructure was sitting mostly idle during the heaviest workloads while the other half ran hot. Redistributing that work evenly across the full cluster changed the performance picture significantly.

The second was about data the cluster was doing unnecessary work to maintain. The index had accumulated tens of thousands of fields over time. Many of the fields were duplicates, and most of them were never actually used in searches. By default, the system was treating all of them as if they might be searched at any moment, building and maintaining overhead for data that would never need it. When this happens, fields accumulate one at a time and the cluster absorbs the cost gradually so that by the time it's significant, it just looks like regular overhead. Telling the cluster which fields actually needed to be search-ready, and which were just along for the ride, eliminated much of the wasted work.

Neither problem was obvious from the inside, and both had been there long enough to feel normal.

What fixing it looked like

The recommendations were straightforward. The implementation took longer, because changes like these require careful planning, testing, and a data migration to apply the new structure to existing records.

But once the work was complete, the migration itself, which historically took multiple hours on this cluster, completed in 33 minutes.

The results

After the phase one recomposition, GCP spend was reduced by $4k per month, saving the customer $48,000 per year in infra costs. We anticipate the next recomposition will save up to $4k per month, or $48,000 per year.

The pattern

These problems develop gradually and invisibly. By the time most teams realize scaling isn't working, they've already spent months overpaying. If your cluster is expensive or slow in ways that haven't responded to scaling, that's worth a conversation. Reach out to your Enterprise Account Manager, or contact our sales team if you're not yet an Enterprise customer.