By ByteBot
OpenSearch 3.6 has shipped, and its most significant label is one the project has never had before: Long-Term Support. Enterprise teams have been waiting for this since the Elasticsearch fork in 2021. But the LTS badge is almost a footnote compared to what’s packed inside — 32x vector compression, an experimental Relevance Agent that tunes search relevance via natural language, and a preconfigured observability stack that knows what your AI agents are doing with every token.
The LTS Story, Finally
OpenSearch 3.6 and version 2.19 are the first two releases to carry official LTS status, backed by the OpenSearch Software Foundation and the Linux Foundation. What that means in concrete terms: at least 18 months of guaranteed support, medium and high severity CVEs patched within 60 days of public disclosure, and software bills of materials generated across all ~150 OpenSearch repositories.
That last point matters for enterprise compliance teams almost as much as the patch SLA. The project also promises that all LTS work goes upstream, so you’re not on an isolated fork-of-a-fork. For teams that stayed on Elasticsearch because of support guarantees, this closes the last credible argument for not evaluating OpenSearch.
32x Vector Compression, No Config Changes Required
The headline performance number is 32x. OpenSearch 3.6 makes 1-bit scalar quantization the default for both Lucene and Faiss — no index settings to flip, no migration required. On Faiss, that delivers 24% better recall and 15% lower latency compared to the old binary quantization methods. Lucene gets something it never had before: both approximate and exact k-NN search running directly on quantized vectors.
The practical implication is a meaningful infrastructure cost reduction for anyone running RAG pipelines or semantic search at scale. With oversampling and rescoring enabled, recall exceeds 0.95 on large datasets like Cohere-10M. The compression is essentially free quality if you configure it properly — and the default is a reasonable starting point without any tuning at all. The memory-optimized vector field documentation covers the configuration options in detail.
Agentic Features: The Interesting and the Practical
The experimental Relevance Agent is the novel piece. Built on the new OpenSearch Agent Server — an experimental multi-agent orchestration platform — the Relevance Agent analyzes user behavior, proposes search tuning changes, and validates them through a natural language interface. It does not touch production configurations without review. It is positioned for teams who know their search is underperforming but lack the relevance engineering expertise to fix it.
More immediately useful is the unified ML Commons agent registration API. Previously, wiring up a model in ML Commons required four manual steps: creating a connector, registering the model, configuring the agent, and mapping parameters. One API call now handles all of it. Community demand also landed transparent token usage tracking in ML Commons responses — a standardized output format that will extend to all agent types in future releases.
Observability Stack: One Command, Full Picture
OpenSearch 3.6 ships a preconfigured observability stack: OpenTelemetry Collector, Data Prepper, OpenSearch, Prometheus, and OpenSearch Dashboards, launched via Docker Compose or a single installer. The new APM layer adds RED metrics, service maps, SLO tracking, and distributed trace exploration. It also tracks LLM calls, execution graphs, and token usage — which tells you exactly where this stack is aimed. Teams running AI agents alongside traditional services can now monitor both in the same pane.
What to Do With This
If you are running OpenSearch in production, 3.6 is the version to stabilize on. The official announcement covers the full upgrade notes, and the LTS guarantee makes this version defensible to enterprise stakeholders in a way no previous release could. The vector compression improvement is automatic — plan a rolling upgrade and your RAG index costs drop without touching your application code.
The Relevance Agent and unified ML Commons API are worth evaluating in staging. Both are experimental, meaning APIs will change before GA. Do not build production workflows on them yet, but run evaluations now so you understand what they deliver before they stabilize. Review the full release notes on GitHub for breaking changes before upgrading. The gap between OpenSearch and Elasticsearch continues to close; 3.6 makes a serious case that it has closed enough.
