Last checked and updated on 10 Jun 2026
What Is New in Elasticsearch 7.16
Elasticsearch 7.16 delivers key enhancements in search performance, security, and data management. This release focuses on making complex queries faster and simplifying how you handle cross-cluster operations.
| Category | Key Updates |
|---|---|
| New Features | Faster terms queries, Cross-cluster replication improvements, EQL sequence queries |
| Enhancements | Frozen index storage savings, Better CCS latency handling, Painless script updates |
| Security | New FIPS 140-2 mode, Service account tokens for internal services |
| Deprecations | Deprecated the `_field_stats` API |
How did search performance get a boost?
The terms query now executes significantly faster for certain common search patterns. This happens because it can skip unnecessary document iterations when the field being queried has a single value per document.
In practice, this optimization is a big win for logging and metrics use cases where you're often filtering on fields like `host.name` or `tags`. You'll see the most dramatic speed improvements on time-series indices and any data that uses the `keyword` type with single values.
What's improved for cross-cluster operations?
Cross-cluster search (CCS) now handles high-latency connections between clusters more effectively. The system is smarter about managing timeouts and retries, which prevents searches from failing prematurely when network conditions aren't perfect.
We also made cross-cluster replication (CCR) more resilient. If a follower cluster loses its connection to the leader, it will now automatically retry restoring the connection, reducing the need for manual intervention to get replication back on track.
Are there new security capabilities?
Yes, Elasticsearch 7.16 introduces a FIPS 140-2 compliant mode for environments that require this certification. When enabled, it restricts the cryptographic algorithms to only those approved under the FIPS standard.
We've also added support for internal service account tokens. These tokens are automatically managed by Elasticsearch for internal processes, making it easier to secure communications between system components without manual token rotation.
What storage optimizations were added?
Frozen indices now take up even less disk space. The previous implementation already saved memory by not loading the index fully into memory, but now we've optimized how these indices are stored on disk too.
This matters because it makes archival data much cheaper to maintain. You can keep more historical data searchable without the storage costs of fully hot indices, which is perfect for compliance or historical analysis scenarios.
Did the query language get any new features?
Event Query Language (EQL) now supports sequence queries with the `until` keyword. This lets you define more precise sequences of events by specifying an ending condition for the sequence pattern.
For security analytics, this is particularly powerful. You can now search for sequences like "a process starts, then makes a network connection, until a file is written" - giving you much finer control over threat hunting patterns.
FAQ
Does the terms query optimization work with multi-valued fields?
No, the optimization specifically targets fields that typically have a single value per document. You'll see the biggest performance gains on fields like `host.name` or `event.action` rather than multi-valued fields like `tags`.
Is the FIPS 140-2 mode enabled by default?
No, you must explicitly enable FIPS mode by setting `xpack.security.fips_mode.enabled` to `true` in your elasticsearch.yml configuration file.
Can I use the new EQL `until` keyword with existing sequences?
Yes, the `until` condition integrates with existing EQL sequence syntax. You can add it to both new and existing queries to make your event sequences more precise.
Do I need to reindex frozen indices to get the storage savings?
No, the storage optimization for frozen indices works automatically. Existing frozen indices will benefit from the improved storage efficiency without any action on your part.
What happens if cross-cluster replication auto-retry fails repeatedly?
The system will continue retrying but will back off between attempts. If failures persist, you'll still need to investigate the underlying cause, such as network connectivity or configuration issues between clusters.