2026-07-21

OpenSearch 3.6: What's in the First LTS Release and Why It Matters

Explore the key features introduced in OpenSearch 3.6 LTS, from Observability and APM improvements to vector search and AI agent enhancements.

Reading time: 7 minutes

By Alannah Melly

OpenSearch 3.6 carries two distinct kinds of significance. It is the first release to carry a Long-Term Support designation in the 3.x line, which means the Foundation has committed to a minimum of 18 months of support, security patch SLAs, and SBOM coverage for it. And it is a substantial feature release in its own right, with meaningful advances across observability, vector search, AI agent infrastructure, and developer tooling.

The two are connected. LTS designation requires a release that has cleared a higher bar for stability and compatibility testing than a standard minor release. The fact that 3.6 is the designated LTS version in the 3.x line reflects the Foundation’s judgement that the feature set and stability of this release represent the right foundation for organisations building production deployments on 3.x. This post covers what is actually in 3.6 and what it means for teams planning or running production OpenSearch.

Observability: A Unified Stack Out of the Box

The most operationally significant addition in 3.6 for many teams will be the OpenSearch Observability Stack. This is not a new plugin or an optional add-on — it is a fully pre-configured observability environment that assembles OpenTelemetry Collector, Data Prepper, OpenSearch, Prometheus, and OpenSearch Dashboards into a single deployable unit, launchable via Docker Compose or a standalone installer.

The stack is intended to be the complete observability layer for microservices, web applications, and increasingly, AI agents. What it provides out of the box:

Distributed tracing with full service maps showing call paths and latency at each hop.
Log analytics ingested through Data Prepper with OpenTelemetry-native pipelines.
Prometheus-compatible metrics with pre-built dashboards in OpenSearch Dashboards.
LLM observability tooling — tracking of large language model calls, execution graphs, and token usage, directly relevant for teams running AI-augmented search workloads.

The significance of this is not just feature breadth — it is the elimination of the integration work that previously sat between an operator and a functional observability setup. Teams who have been assembling observability stacks from individual components, managing version compatibility between them, and configuring the connections manually now have a supported, tested configuration as a starting point. On an LTS release, that configuration has an 18-month support window.

Application Performance Monitoring

3.6 introduces a dedicated Application Performance Monitoring (APM) capability built on the same OpenTelemetry foundation as the Observability Stack. APM in 3.6 provides:

Service topology maps showing which services are calling which, with dependency visualisation across distributed systems.
RED metrics — Rate, Errors, and Duration — the standard signals for service health assessment, available per service and per endpoint.
Direct linking from service metrics to related traces and logs within the Observability workspace in Dashboards, so investigation does not require context switching between tools.
Service grouping by attributes such as SDK language, team, or deployment environment, enabling filtered views for large service meshes.
Threshold-based filtering on error rate and fault rate, so teams can surface degraded services without manual scanning.

For teams running microservices architectures on OpenSearch for search and analytics, this closes a gap that previously required either a separate APM solution or custom instrumentation. The OpenTelemetry foundation means existing instrumentation in services using OTEL SDKs flows into the APM layer without reconfiguration.

Vector Search: 32x Compression via Lucene BBQ

3.6 introduces 1-bit Scalar Quantization (1-bit SQ) via Lucene Better Binary Quantization (BBQ) as the default vector compression method. The performance characteristics are significant: 32x storage compression compared to full float32 vectors, with benchmark results showing 24% better recall and 15% lower latency versus previous quantization approaches.

The practical implication for teams running large vector indices is a substantial reduction in memory footprint without a corresponding hit to search quality. At the scale at which vector search becomes expensive — tens or hundreds of millions of vectors — a 32x compression factor is the difference between a deployment that requires specialised high-memory hardware and one that runs on standard infrastructure.

3.6 also extends support for approximate and exact k-NN search directly on quantized vectors for metadata-heavy use cases — scenarios where vectors are filtered by structured attributes before or after the nearest-neighbour search. This has historically been an area where quantization and metadata filtering interact badly; 3.6 improves the handling of these patterns across both Faiss and Lucene engines.

AI Agent Infrastructure: ML Commons Upgrades

ML Commons — OpenSearch’s framework for integrating large language models and machine learning directly within clusters — receives four major upgrades in 3.6.

Token Usage Tracking

3.6 adds transparent token usage tracking to the ML Commons agent framework. Each agent execution now exposes a TokenUsage model that normalises per-provider token reporting into a unified format, covering prompt tokens, completion tokens, and total tokens consumed. This was one of the most requested community features and directly addresses the cost monitoring and performance debugging gap that existed when there was no visibility into per-execution token consumption. Planned future enhancements include persistent token data storage and configurable per-agent token budgets.

V2 Chat Agent

The V2 Chat Agent is a next-generation agent type that simplifies conversational AI workflows within ML Commons. It builds on the existing ReAct and PER agent types with a more streamlined interface for chat-based interactions while retaining the flexibility to integrate tools and memory. For teams building conversational search or support applications on top of OpenSearch, this reduces the boilerplate required to wire up a functional chat agent.

Semantic and Hybrid Memory APIs

A new set of APIs brings semantic and hybrid search capabilities to long-term memory retrieval for agents. Agents can now search stored memory using both semantic similarity and structured filters, enabling more accurate and context-aware memory recall during multi-turn conversations. This is a foundational capability for agents that reason over extended conversation histories — the pattern underpins most production conversational AI applications.

OpenSearch Launchpad

Launchpad is an AI-powered agent that automates the initial setup of a search application. Given a set of sample documents and conversational input describing what the search application should do, Launchpad can provision a local setup, select retrieval approaches (dense, sparse, or hybrid), configure embedding models, and generate a working user interface. It integrates with IDEs and handles the configuration decisions — from semantic encoding to cluster layout — that would otherwise require manual expertise. It is primarily a developer tooling addition but has direct implications for time-to-first-working-search-application.

The OpenSearch Relevance Agent

The Relevance Agent is an experimental feature in 3.6 that automates search relevance tuning. The agent operates through a natural-language interface in OpenSearch Dashboards and uses three specialised subagents: one that analyses user behaviour and query logs to identify relevance problems, one that generates hypotheses about configuration changes that would improve relevance, and one that evaluates those changes through controlled experiments. The cycle that previously involved manual query analysis, configuration adjustment, A/B testing, and iteration — a process that typically ran over weeks — is compressed into an automated loop.

The Relevance Agent is flagged as experimental, which means it is not covered by the LTS support guarantees for 3.6. The stable, LTS-covered capabilities in 3.6 are the Observability Stack, APM, the vector search improvements, and the ML Commons upgrades. Experimental features in an LTS release can be used, but they may change in subsequent releases and do not carry the same support commitments.

Why 3.6 Is the Right LTS Target for 3.x Deployments

The combination of the Observability Stack, APM, the vector search compression improvements, and the ML Commons upgrades makes 3.6 a release that meaningfully advances OpenSearch’s capability across the workloads it is most commonly deployed for: search, observability, and AI-augmented data applications. The LTS designation adds the governance layer that makes it a stable foundation for production deployments rather than a feature release to evaluate and move on from.

If you are on 2.x and planning a major version upgrade, 3.6 is the version to target.
If you are starting a new 3.x deployment, it is the obvious starting point.
If you are already running a 3.x minor version, upgrading to 3.6 is the path to LTS coverage.

Eliatra provides Foundation-accredited LTS support for OpenSearch 3.6 and 2.19. If you’d like to discuss upgrading to 3.6 or planning LTS coverage for your deployment, get in touch today.