For AI agents: The documentation index is at https://docs.digitalocean.com/llms.txt. Markdown versions of pages use the same URL with index.html.md in place of the HTML page (for example, append index.html.md to the directory path instead of opening the HTML document).

OpenSearch supports vector search through k-NN indexes, knn_vector fields, filters, aggregations, and optional ML Commons integrations.

OpenSearch Vector Search

OpenSearch stores vectors in knn_vector fields and uses k-NN indexes to search for nearby vectors. A vector search query compares a query vector against stored vectors and returns the closest matches.

OpenSearch is useful for vector workloads when search quality depends on more than vector similarity alone. It can combine vector search with filters, full-text search, aggregations, and hybrid search in the same engine. For help deciding whether OpenSearch is the right engine for your application, see Choosing an Engine.

Choose a k-NN Engine

OpenSearch supports multiple k-NN engines. Each engine affects indexing behavior, filtering, performance, and available tuning options.

The best k-NN engine depends on your workload, index size, filtering needs, and tuning requirements:

• Faiss: Use when you need high-throughput vector search, large-scale ANN performance, or quantization options.
• Lucene: Use when you want tight integration with OpenSearch indexing and filtering behavior.
• NMSLIB: Use only when you need compatibility with an older index or deployment.

For current OpenSearch features, see OpenSearch methods and engines.

Faiss

Facebook AI Similarity Search (Faiss) is a vector search library designed for high-throughput similarity search at scale. In OpenSearch, Faiss supports HNSW indexes and can support product quantization and scalar quantization, depending on configuration and version.

Faiss is a strong fit for large vector workloads where throughput, recall tuning, and memory efficiency matter. Use Faiss when you need high-performance approximate nearest-neighbor search and are comfortable tuning vector index settings.

Lucene

Lucene provides native HNSW support inside OpenSearch. Because Lucene owns the underlying segment structure, Lucene-based vector search integrates closely with OpenSearch indexing and filtering behavior.

Lucene is a strong fit when you want vector search that behaves naturally with OpenSearch indexes, filters, and segment-level operations.

NMSLIB

Non-Metric Space Library (NMSLIB) is an older k-NN engine in OpenSearch. It exists mostly for backwards compatibility. For new vector workloads, use Faiss or Lucene unless you have a specific compatibility requirement.

Choose a Space Type

The space type controls how OpenSearch compares vectors. Choose the space type that matches the embeddings you store and the similarity function your model expects.

Common options include:

• Cosine similarity: Use for normalized text embeddings and semantic search workloads.
• L2 distance: Use when your model expects Euclidean distance.
• Inner product: Use when your model or ranking strategy depends on vector magnitude as well as direction.

Use the same space type consistently across indexing, querying, and evaluation. Changing the space type can change result ordering even when the stored vectors stay the same.

Use Filters with Vector Search

Use filters when vector search results need to respect metadata, such as account ID, project ID, permissions, timestamps, language, source, or object type.

Filtering behavior depends on the k-NN engine and index configuration. Lucene and Faiss HNSW engines support filtering inside the knn query, which lets OpenSearch apply filters while searching the vector graph.

For filtered workloads, choose an engine and index configuration that match your filtering needs. Test representative filtered queries because highly selective filters can affect recall, latency, and candidate selection.

Tune k-NN Query Size

The k value controls how many nearest neighbors the vector query retrieves. The size value controls how many hits OpenSearch returns.

For simple vector searches, keep k and size equal. For filtered or hybrid-style workloads, you may need a larger k so OpenSearch has enough vector candidates before filtering, scoring, or combining results.

Test with representative queries and known relevant results. Increasing k can improve recall, but it can also increase query latency.

Optimize Large Ingestion Jobs

Vector indexes can be expensive to build and refresh during large ingestion jobs.

For large initial loads, temporarily reduce indexing overhead before ingestion, then restore normal settings after ingestion finishes. For example, you can temporarily set refresh_interval to -1 and number_of_replicas to 0, then restore both settings after the load completes.

Avoid setting refresh=True during production ingestion. Forced refreshes make newly indexed documents searchable immediately, but they can add significant overhead for vector indexes.

Monitor Index Size and Query Behavior

Use index statistics to confirm that documents were indexed and to debug ingestion or query issues.

Check document counts, index size, and k-NN plugin statistics when troubleshooting.

Use _count to confirm how many documents are indexed:

curl "$OS/documents/_count"

Use _cat/indices to check document count and storage size:

curl "$OS/_cat/indices/documents?v&h=index,docs.count,store.size,pri.store.size"

Use the k-NN stats API to inspect k-NN plugin activity:

curl "$OS/_plugins/_knn/stats?pretty"

Monitor query latency, recall, and memory usage with representative workloads. Vector search performance depends on index size, vector dimensions, engine choice, filtering patterns, and query settings.