TSDB performance improvements are now generally available in 9.4. Elasticsearch can store metrics at 2.6x the efficiency of Prometheus and query them 25x faster than Prometheus and Mimir.
Native Prometheus and PromQL support (technical preview) lets Prometheus-based teams consolidate onto Elastic without abandoning the tooling they already have: ship Prometheus metrics directly to Elasticsearch, execute PromQL queries natively in Kibana alongside existing dashboards and alerting rules, and combine PromQL with ES|QL for unified logs and metrics analysis in a single query.
ES|QL time-series support is now generally available, with expanded aggregation functions (rate, changes, cumulative, trange, clamp) and full time-range filtering, making it a fully supported foundation for monitoring, alerting, and reporting workflows. The managed OTLP endpoint is also now generally available on Elastic Cloud Hosted, giving you a direct path to send OpenTelemetry logs, metrics, and traces into Elastic without deploying or operating collectors for basic ingestion.
Search Analytics Logs: One Log for Every Query
Your cluster is slow. CPU is spiking. A dashboard times out. But which query caused it? This has been a persistent pain point for everyone running Elasticsearch. Unlike slow logs, which fire per shard, cover DSL only, and produce multiple lines per query, Elasticsearch query logs produce one line per request, covering ES|QL, DSL, SQL, and EQL, with the actual end-to-end duration from the coordinator's perspective, which is the same took value returned by the API. Each entry also carries the full query text, outcome (success or failure), X-Opaque-Id, and optional user context. The schema is ECS-aligned, so you can ship straight to Kibana with no custom pipeline.
Query logging is off by default. To enable it and only capture queries above a duration threshold:
PUT _cluster/settings
{
"persistent": {
"elasticsearch.querylog.enabled": "true",
"elasticsearch.querylog.threshold": "1s"
}
}
Logs land in your Elasticsearch log directory as *_querylog.json. Each line is one JSON object. Here is what a successful DSL search looks like:
{
"@timestamp": "2026-03-04T19:40:34.736Z",
"log": {
"level": "INFO",
"logger": "elasticsearch.querylog"
},
"event": {
"duration": 1000000,
"outcome": "success"
},
"elasticsearch": {
"querylog": {
"type": "dsl",
"query": "{\"size\":10,\"query\":{\"match_all\":{\"boost\":1.0}}}",
"indices": ["query_log_test_index"],
"result_count": 3,
"search": { "total_count": 3 },
"shards": { "successful": 1 },
"took": 1000000,
"took_millis": 1
},
"node": { "name": "node-1" },
"cluster": { "name": "my-es-cluster" }
},
"http": {
"request": {
"headers": { "x_opaque_id": "opaque-1772653234" }
}
},
"user": {
"name": "elastic",
"realm": "reserved"
}
}
Ship the logs using the querylog fileset in the Filebeat Elasticsearch module, and you get an out-of-the-box Kibana dashboard with P95/P99 latencies, query type breakdown, success/failure ratios, top indices, and top error types. This builds on the ES|QL-only query log introduced in 9.2 and extends it to all query languages.
Vector Search: simdvec, DiskBBQ Improvements and GPU Indexing
ARM - Bulk scoring, int8 dot product (ns/op, lower is better)
