Why Your Cluster Composition Matters, and Why You'll Never Have to Think About It

What is a cluster’s “composition”?

When you run search on Elasticsearch or OpenSearch, your data doesn’t just live in one place on one server. It lives in a cluster, or a group of servers working together to store your documents, handle queries, and keep everything humming even if something goes wrong.

The composition of that cluster is the sum of all of the infrastructure decisions underneath it: how many servers (nodes) you have and what type, how those nodes are grouped, and what role each one plays. Some nodes hold your actual data and handle search queries. Others act as orchestrators at scale, making sure all the pieces talk to each other correctly. Some hardware optimizes for CPU, some for RAM, some for disk.

Zoom out one more level and you get the full picture: nodes group into cells , cells live inside pods, and pods may contain multiple cells as your data grows.

So, if you’re not a search engineer, or a search expert, how do you know what the right composition is? Think of it like staffing a team: three generalists might be perfect for one job, ten specialists for another. The right answer depends on what you're trying to do. And getting it wrong has consequences.

Why does your cluster's composition matter?

Search quality has three dimensions: relevance (are the results right?), performance (is it fast and scalable?), and experience (is the interface working for your users?).

Cluster composition lives squarely in the performance column, but that doesn't mean it's disconnected from the rest.

Performance is the floor everything else is built on. You can have perfect relevance tuning and a beautiful interface, but if your cluster is undersized, then queries slow down, data goes missing, or — worst case — search goes down entirely.

Modern AI-powered search, including vector search and hybrid search, raises the bar further. These workloads require specific hardware profiles and configurations that a standard general-purpose cluster won't support well. Getting the composition right isn't just a cost optimization exercise, though it does help with that, too. It's what makes advanced search work so your users can actually find what they’re looking for.

When your cluster needs to change: recomposition

Your data doesn't stay the same size forever. Your query patterns shift. AWS releases a new instance family with better price-performance. You're onboarding a large new dataset and need more headroom. Any of these can mean your current cluster composition is no longer the right one.

A recomposition is the process of migrating your data from the cells it currently lives in to new cells with a different configuration. It sounds straightforward, but the complexity scales fast.

The signals that a recomposition is needed come from three places: CPU, disk, and memory. The tricky part is that these signals are subtle and gradual. Most teams running search don't log into a monitoring dashboard every day looking for trends. They're building their product. By the time they notice something is wrong, it usually means search is already slow, or returning partial results, or down. The recomposition needed to fix it was visible weeks earlier in the metrics, if someone was looking.

That's the problem Bonsai solves on the recomposition side: we're looking, every day, so you don't have to.

How Bonsai makes this invisible (by design)

Go price a managed cluster somewhere else. Unless you are a search expert, you'll spend twenty minutes answering questions you don't fully understand yet. You’ll need to know the hardware profiles, tier architecture, node types, and licensing levels you want before you've decided on a single server size. The final quote arrives as an hourly figure with four decimal places. That's not a budget line. That's a math problem.

And that's just to get started. If you later need a recomposition, you have to know that you need one, and you have to know what to change it to.

At Bonsai, you pick a plan. We handle the rest.

When you sign up, we don't hand you a configuration wizard. For Standard tier customers, we configure your cluster based on what we know works. For Business and Enterprise customers, you tell us what you're building and we match the hardware profile and cell configuration to your workload. Either way, you're not guessing.

More importantly, we are monitoring your clusters every day. We look at disk usage trends, memory pressure, and CPU load. When we see a cluster heading toward trouble, we reach out before anything breaks. In some cases, a proactive recomposition actually saves money. We're not optimizing for extracting more from you. We're optimizing for your search working well, because that's the job and because we are, genuinely, search nerds.

Most teams running search on Bonsai are not running search as their job. They're building a product, and search is a piece of it. They shouldn't need to become infrastructure experts to keep it healthy. That's what we're here for.

Ready for what’s next?

The conversation around search has shifted. Keyword matching was the baseline. Now teams are building hybrid search pipelines and integrating vector embeddings. These workloads aren't plug-and-play. They require clusters with specific hardware profiles configured to support them from the start.

Getting your composition right now means you're not rearchitecting later when you're ready to move up the capability stack. The infrastructure is already there when you need it.

If you're ready to see what that looks like for your use case, start here. We can’t wait to hear more about what you’re building.