What Is New in Elasticsearch 9.5
| Category | Highlights |
|---|---|
| New Features |
|
| Improvements |
|
| Bug Fixes |
|
What does batched execution in the query phase mean for search performance?
Batched execution in the query phase groups shard-level query work together instead of processing requests one at a time, reducing coordination overhead on large clusters. In practice, this shows up as lower latency and more predictable throughput for queries that fan out across many shards, particularly in time-series and log-heavy deployments where shard counts per index pattern can be high.
This ties into a broader set of search-path changes in 9.5, including a new reader-heap circuit breaker for the stateless search engine and improvements to how search hits are pooled and ref-counted (ExpandSearchPhase, CompletionSuggestion, and SearchHitRowSet all moved to pooled hits). Most teams won't need to change any configuration to benefit from this, but if you run custom monitoring around query phase timings, expect the shape of those metrics to shift slightly.
Watch out for the new cache-miss wait time field added to search responses. It's a useful diagnostic if you're chasing latency spikes tied to blob store prefetching, especially on searchable snapshots.
How does data stream lifecycle support for the frozen tier change storage strategy?
Data stream lifecycle (DLM) can now move data directly into the frozen tier, closing a gap that previously required ILM for full tiered-storage automation. This matters if you've been running DLM for its simplicity but had to fall back to ILM just to get frozen-tier cost savings on old data.
Alongside this, a new dynamic cluster setting, data_streams.lifecycle.downsampling.max_indices_in_progress (default 10), throttles how many backing indices per data stream can be submitted to downsampling in a single run. Indices that get deferred are recorded in the error store with a warning and retried on the next run, so nothing silently gets skipped.
Also note that both ILM and DLM snapshots now use partial: true by default, which prevents a stuck snapshot from blocking cluster recovery actions. This is a meaningful operational safety net if you've ever had a snapshot hang during a node recovery.
What's new for ES|QL users in this release?
ES|QL gets one of its largest feature pushes yet in 9.5, with flattened field support, the DEDUP command, and match with non-mapped expressions all reaching general availability. The new IP_LOCATION command adds geolocation lookups directly in ES|QL pipelines, and range_intersects/range_contains functions extend range-based filtering.
The FUSE command is now GA, useful for combining results from multiple retrievers, and JSON_EXTRACT is also GA for pulling structured values out of JSON strings without a separate ingest step. A simple example:
FROM logs-*
| EVAL parsed = JSON_EXTRACT(message, "$.status_code")
| WHERE parsed >= 500
In practice, teams running dashboards or alerting logic in ES|QL should review queries that touch unmapped fields. Several fixes in this release change how unmapped fields behave under LOAD, FORK, and subqueries, which could subtly alter result sets if you were relying on prior (undocumented) behavior.
What should I know about vector search and TSDB changes before upgrading?
Vector search gets a round of low-level performance work, including AVX-512 kernels for f32 dot product and squared L2 distance, and a symmetric 1-bit OSQ vector scorer for DiskBBQ. If you're running dense vector search at scale on modern hardware, these changes should translate into measurably lower query latency without any configuration changes.
On the TSDB side, ES95 becomes the default doc values codec, and you can now create backing indices for backfilling past timestamps as an opt-in feature. Native support for metric temporality has also landed, which is relevant if you're ingesting OpenTelemetry metrics with cumulative or delta temporality semantics.
This matters if you maintain custom TSDB mappings: the release also adds a raw histogram mapping hint and improves handling of OTLP explicit-bounds histograms in tdigest and exponential histogram conversion paths. Review your ingest pipelines if you're piping OTLP metrics directly into TSDB-backed indices.
Are there security or operational changes that affect production clusters?
Yes -- 9.5 introduces a dedicated encryption service (EncryptionService) with automatic key rotation and encryption-at-rest for the primary encryption key, moved into its own x-pack-encryption module. This is largely transparent, but teams managing their own key rotation tooling should check the new graceful degradation behavior when no password is configured.
Audit logging can now be toggled on or off without a server restart, which removes a common source of planned downtime for security-conscious clusters. Log4j was also bumped to 2.26.1 as part of ongoing dependency hygiene.
On the allocation side, DesiredBalanceStats is now exposed as metrics, and desired balance is published earlier when newly created replicas are assigned. If you monitor shard allocation behavior closely, expect slightly earlier visibility into rebalancing decisions after upgrading.
FAQ - Common Questions about Elasticsearch 9.5
Does Elasticsearch 9.5 require reindexing existing data?
No, standard upgrades do not require reindexing, though features like columnar index mode and date_range are opt-in and only apply to newly created indices or fields.
Is the flattened field type safe to use in production now?
Yes, support for flattened fields in ES|QL along with field_extract on flattened fields has been released and is no longer marked as preview.
Can I use JSON_EXTRACT in ES|QL to parse nested JSON in a text field?
Yes, for example you can write FROM logs-* then EVAL code = JSON_EXTRACT(message, dollar sign status_code) followed by a WHERE clause to filter on the parsed value.
Will enabling frozen tier support in data stream lifecycle affect my existing ILM policies?
No, DLM and ILM operate independently, so enabling frozen tier movement in DLM does not modify or override existing ILM policies on other indices.
Do I need to change my OpenTelemetry ingestion pipeline for this release?
Only if you rely on cumulative or delta metric temporality or send explicit-bounds histograms, since both now have dedicated native handling that changes how the data is stored internally.
Is the new encryption key rotation feature enabled by default?
Encryption at rest and automatic key rotation for the primary encryption key are part of the new x-pack-encryption module, but clusters without a configured password will degrade gracefully rather than fail.