How Elasticsearch 8.6 Handles Vector Search at Scale: A Benchmark from the Bayview Cluster

Vector search has become a cornerstone of modern search applications, from semantic product discovery to real-time recommendation engines. Elasticsearch 8.6 introduced significant improvements to its vector search capabilities, but running approximate nearest neighbor (ANN) search at scale requires careful planning. This article shares qualitative observations from the Bayview cluster, a production deployment handling millions of vectors across multiple indices. We focus on what works, what breaks, and how to tune for your specific use case.

Why Vector Search at Scale Demands Attention

Traditional full-text search relies on inverted indices and term matching. Vector search flips that model: documents are represented as high-dimensional vectors, and queries find the nearest neighbors by distance. At small scale, brute-force k-nearest neighbors (kNN) works fine—just compute all distances. But when you have hundreds of millions of vectors, each with 128 or 768 dimensions, exhaustive search becomes impractical. Elasticsearch 8.6 uses the Hierarchical Navigable Small World (HNSW) algorithm for approximate search, which trades a small amount of recall for dramatic speed gains.

Teams often assume that enabling vector search is as simple as adding a dense_vector field and indexing data. The reality is more nuanced. Indexing speed, memory pressure, query latency, and recall all depend on HNSW parameters like m (maximum edges per layer) and ef_construction (dynamic candidate list size during indexing). On the Bayview cluster, we observed that default settings work for small datasets but cause performance degradation beyond a few million vectors.

For example, a customer running product similarity search with 768-dimensional vectors saw indexing throughput drop by 40% when m was set to 64 instead of 16. Query latency, however, improved by 60% at the same recall level. These trade-offs are not one-size-fits-all. Understanding them is essential before scaling.

Who Should Care About These Benchmarks

This guide is for engineers and architects who are evaluating Elasticsearch 8.6 for vector search in production. If you're already using vector search and hitting performance walls, the following sections will help you diagnose and adjust. If you're new to vector search, we'll cover the basics without assuming prior experience.

Core Idea: How HNSW Works in Elasticsearch 8.6

HNSW builds a multi-layer graph where each layer is a subset of the vectors. The top layer contains a few hundred vectors, and each lower layer adds more detail. During search, the algorithm starts at the top layer, greedily moves toward the query, then descends to finer layers. This hierarchical approach reduces the number of distance calculations from millions to a few thousand.

Elasticsearch 8.6 implements HNSW as the default algorithm for dense_vector fields with index: true. The key parameters are:

• m: The number of edges each node maintains in the graph. Higher values increase memory and indexing time but improve recall.
• ef_construction: The dynamic candidate list size during index building. Larger values improve graph quality at the cost of slower indexing.
• ef_search: The candidate list size during query. Higher values increase recall but also latency.

On the Bayview cluster, we benchmarked these parameters across three datasets: 1 million 128-dimensional vectors (medium), 10 million 256-dimensional vectors (large), and 50 million 768-dimensional vectors (XL). The hardware was consistent: 16 nodes, each with 64 GB RAM and NVMe SSDs.

Indexing Throughput vs. Recall

For the medium dataset, increasing ef_construction from 100 to 400 improved recall at k=10 from 0.92 to 0.98, but indexing throughput dropped by 35%. For the XL dataset, the drop was 50%. If your indexing pipeline is time-sensitive, you may prefer lower ef_construction and accept slightly lower recall. We found that ef_construction=200 offered a good balance for most use cases.

Query Latency vs. Recall

Query latency is directly tied to ef_search. With ef_search=100, median latency for the large dataset was 12 ms at 0.93 recall. Doubling ef_search to 200 pushed recall to 0.97 but latency to 22 ms. For real-time applications like autocomplete, the extra 10 ms may be unacceptable. For batch similarity jobs, the higher recall is worth the wait.

How It Works Under the Hood

When you index a document with a dense_vector field, Elasticsearch serializes the vector and adds it to an HNSW graph segment. The graph is stored per Lucene segment, and segments are merged over time. This design has implications for memory and performance.

Each HNSW graph is loaded into memory when the segment is opened. With many small segments, memory overhead increases because each graph has its own index structures. On the Bayview cluster, we observed that after a force merge to a single segment per shard, memory usage dropped by 30% and query latency improved by 15%. However, force merging is expensive and blocks indexing. We recommend scheduling it during low-traffic periods.

Segment Merging and Graph Quality

During segment merges, the HNSW graphs are combined. The merge process rebuilds the graph from scratch, which can degrade quality if the merge is not tuned. Elasticsearch 8.6 introduced a new merge policy for vector fields that prioritizes preserving graph connectivity. In our tests, this policy maintained recall within 1% of the original after a full merge, compared to a 5% drop with the default merge policy.

Memory Footprint

Each vector consumes memory for its raw values plus graph edges. For a 768-dimensional vector with float32 elements, that's 3 KB per vector. With m=32, each edge adds roughly 8 bytes (pointer). For 50 million vectors, the graph alone can exceed 12 GB per shard. On our cluster, we allocated 32 GB heap per node for vector indices, but garbage collection pauses increased when the graph exceeded 20 GB. We recommend keeping the total vector index heap under 25% of node memory.

A Walkthrough: Setting Up and Tuning Vector Search

Let's walk through a typical scenario: you have 5 million product descriptions, each encoded into a 384-dimensional vector using a sentence transformer. You want to return the top 20 similar products for a query vector.

First, create the index with appropriate mappings:

PUT /products
{
  "mappings": {
    "properties": {
      "product_vector": {
        "type": "dense_vector",
        "dims": 384,
        "index": true,
        "similarity": "cosine"
      }
    }
  }
}

Next, index your documents. For bulk indexing, we recommend using the _bulk API with batches of 500–1000 documents. On the Bayview cluster, indexing throughput plateaued at around 2000 documents per second per shard for 384-dimensional vectors. If you need higher throughput, increase the number of shards or reduce ef_construction.

Tuning HNSW Parameters

After indexing a subset of data, run a few queries to measure recall and latency. Start with default parameters (m=16, ef_construction=100, ef_search=100). If recall is below 0.95, increase ef_search first—it's cheaper than rebuilding the index. If recall is still low, rebuild the index with higher ef_construction or m.

Scaling to Multiple Shards

When distributing vectors across shards, each shard runs its own HNSW search. The coordinator node merges results from all shards. This means latency scales with the number of shards, but total recall can be better because each shard returns its top candidates independently. We observed that with 10 shards and k=20, the final recall was 0.98 compared to 0.95 with a single shard, because the shard-level results were more diverse.

Edge Cases and Exceptions

Not all workloads benefit from HNSW. If your dataset is small (under 100,000 vectors), brute-force search with index: false may be faster and simpler. Similarly, if you need exact results for compliance or auditing, you must disable approximate search.

Another edge case is high-dimensional vectors (over 1024 dimensions). HNSW degrades in high dimensions due to the curse of dimensionality. On the Bayview cluster, we tested 1536-dimensional vectors and found that recall at k=10 dropped to 0.85 even with high ef_search. For such dimensions, consider dimensionality reduction (e.g., PCA) or switching to a specialized vector database.

Filters and Pre-Filtering

Combining vector search with filters (e.g., "only products in stock") can be tricky. Elasticsearch 8.6 supports pre-filtering: the filter is applied first, then vector search runs on the filtered set. If the filter is highly selective (e.g., 1% of documents), the search is fast. But if the filter returns 90% of documents, the pre-filtering overhead can negate the benefits of HNSW. In our tests, pre-filtering with a broad filter added 30% latency compared to unfiltered search.

Cold Start and Indexing During Search

When you start indexing, segments are small and numerous. Searching during indexing can be slow because each segment's graph is tiny and the coordinator must merge many results. We recommend allowing indexing to complete before enabling search, or using a separate index for near-real-time queries.

Limits of the Approach

HNSW is not a silver bullet. Its memory requirements grow linearly with the number of vectors, and scaling beyond 100 million vectors on a single cluster becomes challenging. On the Bayview cluster, we hit a wall at 200 million vectors: indexing slowed to a crawl, and garbage collection pauses exceeded 10 seconds. At that point, we had to split the data into multiple clusters or use a tiered storage approach.

Another limitation is the lack of native support for hybrid search (combining vector and text scores). While you can script a weighted sum, it's not efficient. Elasticsearch 8.6 introduced the knn query that can be combined with bool queries, but the scoring is not mixed—the vector score and text score are separate. For true hybrid ranking, you may need to re-rank externally.

When to Look Beyond Elasticsearch

If your use case requires real-time updates (inserts and deletes at high velocity), HNSW's graph structure is expensive to maintain. Each deletion requires marking the vector as deleted, but the graph edges remain, causing memory waste. Over time, the graph becomes fragmented. Specialized vector databases like Milvus or Qdrant handle updates more gracefully. For read-heavy workloads with static data, Elasticsearch is a solid choice.

Reader FAQ

Q: Can I use Elasticsearch 8.6 for real-time recommendation?
A: Yes, but expect sub-100 ms latency for datasets under 10 million vectors. For higher throughput, use caching or reduce ef_search.

Q: How do I choose between cosine and Euclidean similarity?
A: Cosine is preferred for normalized vectors (e.g., from text embeddings). Euclidean works well for unnormalized data like image features. Both are supported.

Q: What happens if I run out of memory?
A: The JVM will throw OutOfMemoryError, and the node will crash. Monitor heap usage and set indices.breaker.total.limit to prevent runaway queries.

Q: Can I mix vector and text search in one query?
A: Yes, using a bool query with a knn clause and a match clause. The results are combined, but scoring is independent. You may need to re-rank.

Q: Is there a limit on vector dimensions?
A: Elasticsearch 8.6 supports up to 2048 dimensions. Beyond that, performance degrades. Consider dimensionality reduction.

Q: How do I back up vector indices?
A> Use snapshots like any other index. Restoring is straightforward, but the graph is rebuilt on restore, which can take time.

Q: Should I force merge after indexing?
A: Yes, if you have a static dataset or a maintenance window. It reduces memory and improves query speed.