+++
title = "What's New in Elasticsearch 7.10"
weight = 21
updated = 2026-09-02

[extra]
nav_title = "What's New in ES 7.10"
weight = 5
+++

If your cluster is running an older Elasticsearch 7.x release, such as 7.2, we
may upgrade it to **Elasticsearch 7.10.2**. This page explains what that means
for you and what you gain in the process.

The short version: this is a minor version upgrade within the 7.x series. Your
data, indices, credentials, and cluster URL stay exactly the same, and your
application does not need to change. You get several years of stability,
performance, and security improvements for free.

{% admonition(type="info", title="Nothing to do on your end") %}
Minor version upgrades within Elasticsearch 7.x are backward compatible. There
are no breaking API changes between 7.2 and 7.10, so your existing queries,
mappings, and client libraries continue to work as-is. If you'd like to validate
against the new version yourself before the change, see
[Upgrading Major Versions](@/docs/cluster-management/version-upgrades/upgrading-major-versions/index.md),
whose blue-green approach works just as well for minor upgrades.
{% end %}

## Why We're Upgrading

Bonsai supports a limited set of Elasticsearch versions on
[multitenant clusters](@/docs/platform/bonsai-architecture/index.md) so that we
can provide reliable operational support and timely security response across the
fleet. 7.10.2 is the current standard for the 7.x series. Consolidating older
7.x clusters onto 7.10.2 lets us keep every 7.x cluster on a version that
receives our full operational attention. See
[How Bonsai Handles Elasticsearch Releases](@/docs/cluster-management/version-upgrades/how-bonsai-handle-version-releases/index.md)
for the full policy.

## What You Gain

Every release between 7.2 and 7.10 layered on improvements. Here are the changes
most likely to matter for a typical Bonsai workload.

### Stability and Security

You move from a 2019-era release onto one that received nearly two more years of
bug fixes and security patches. This is the single biggest reason to be on
7.10.2: fewer known issues, and a version we can support and patch effectively.

### Performance and Efficiency

- **Lower memory footprint.** A series of heap-usage reductions across 7.3–7.10
  means the same cluster handles more mappings and more concurrent work before
  hitting memory pressure. This is especially noticeable on clusters with large
  or numerous indices.
- **Faster indexing.** Indexing throughput improved measurably over the 7.x
  series for many workloads.
- **Smaller indices.** 7.10 improved compression of stored fields, reducing
  on-disk index size for many workloads with no configuration changes. Smaller
  indices mean more headroom under your plan's storage limit.
- **Faster aggregations.** Date histogram aggregations — a common building block
  for dashboards and analytics — were significantly optimized.

### Search Capabilities

These are opt-in features. You don't have to use them, but they're available on
7.10.2 if you want them:

- **`search_as_you_type` field type** (added in 7.4) — a purpose-built field for
  autocomplete and instant-search experiences, without hand-rolling edge-ngram
  mappings.
- **Pinned queries** (7.4) — promote specific documents to the top of results,
  useful for merchandising, curated results, and sponsored placements.
- **Vector search foundations** — `dense_vector` fields with `script_score`
  let you build semantic and similarity search using embeddings, the basis for
  modern AI-powered search.
- **Async search** (GA in 7.7) — run long or heavy queries in the background and
  collect results as they complete, instead of holding a request open.
- **Point-in-time reads** (7.10) — a lightweight way to run consistent,
  paginated queries against a fixed view of your data.

### New Field Types and Data Handling

- **`version` field type** (7.10) — sorts and compares software version strings
  using semantic-versioning rules rather than plain string ordering.
- **`unsigned_long`** (7.10) — support for unsigned 64-bit integers, up to
  2⁶⁴-1, for large counters and system-generated identifiers.
- **Composable index templates** (GA in 7.8) — build index templates from
  reusable component templates, which makes managing mappings and settings
  across many indices far less repetitive.

## Will Anything Break?

No breaking changes were introduced within the 7.x line, so an upgrade from 7.2
to 7.10.2 should be transparent to your application. Features that were
*deprecated* during 7.x still function in 7.10.2 — they don't get removed until
Elasticsearch 8. If your use case depends on something niche, the safest check
is to
[test your queries against the new version](@/docs/cluster-management/version-upgrades/upgrading-major-versions/index.md)
before the change. When in doubt, [reach out to support](mailto:support@bonsai.io).

## I Need to Stay on My Exact Version

Some use cases are pinned to an exact engine version — for example,
compatibility testing, regulatory requirements, or a client library locked to a
specific release. On multitenant plans, Bonsai can't pin a cluster to a version,
because changing versions means migrating between shared server groups.

If you need control over when your engine version changes, upgrade to a
[Business cluster](@/docs/cluster-management/sizing-your-business-cluster/index.md).
Business and Enterprise clusters run on
[dedicated, single-tenant infrastructure](@/docs/platform/bonsai-architecture/index.md),
so version changes happen only when you request them. See
[How Bonsai Handles Elasticsearch Releases](@/docs/cluster-management/version-upgrades/how-bonsai-handle-version-releases/index.md)
for details.

## Questions?

We're happy to help. Email us at [support@bonsai.io](mailto:support@bonsai.io)
and we'll walk through what the upgrade means for your specific cluster.