# Edit Distance \> 2 - Is It Really Unconfigurable?

**URL:** <https://discuss.elastic.co/t/edit-distance-2-is-it-really-unconfigurable/383458>\
**Category:** Elasticsearch\
**Created:** [November 15, 2025, 12:27pm UTC](https://discuss.elastic.co/t/edit-distance-2-is-it-really-unconfigurable/383458 "2025-11-15T12:27:28Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ilia](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ilia/32/60042_2.png) [@Ilia](https://discuss.elastic.co/u/Ilia)\
**Post date:** [November 15, 2025, 12:27pm UTC](https://discuss.elastic.co/t/edit-distance-2-is-it-really-unconfigurable/383458/1 "2025-11-15T12:27:28Z")

</div>

I'm facing the same problem mentioned in [this thread](https://discuss.elastic.co/t/fuzziness-above-2-distance-or-60-levenshtein-match/159898) - I need to use an edit distance greater than 2 for fuzzy searches, but Elasticsearch doesn't seem to support this.

I understand the performance concerns with higher Levenshtein distance values, but for my specific use case with small datasets, this isn't a concern. What surprised me is that this appears to be completely unconfigurable - I can't find any setting to adjust this limit.

Is this limitation truly hard-coded? If so, where I can find this value in the source code to change and build a custom version?

---

<div class="post-metadata">

**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\
**Post date:** [November 15, 2025, 2:04pm UTC](https://discuss.elastic.co/t/edit-distance-2-is-it-really-unconfigurable/383458/2 "2025-11-15T14:04:44Z")

</div>

Have a look at:

> <https://github.com/apache/lucene/blob/main/lucene/core/src/java/org/apache/lucene/util/automaton/LevenshteinAutomata.java#L37>

---

<div class="post-metadata">

**Author:** ![Ilia](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ilia/32/60042_2.png) [@Ilia](https://discuss.elastic.co/u/Ilia)\
**Post date:** [November 16, 2025, 9:07am UTC](https://discuss.elastic.co/t/edit-distance-2-is-it-really-unconfigurable/383458/3 "2025-11-16T09:07:58Z")

</div>

Thank you David,

I'v tried to increase the fuzzy edit distance limit beyond 2 by modifying the Lucene source code. Here's what I've done so far:

1. Changed `MAXIMUM_SUPPORTED_DISTANCE` from 2 to 5 in the Lucene core

2. Recompiled the `lucene-core` library

3. Replaced the JAR file in Elasticsearch's lib directory

4. Verified via decompilation that the change is present in the JAR

However, I'm still getting the same error when trying to use edit distances greater than 2. This suggests there might be additional validation happening elsewhere in the codebase that's enforcing this limit.

```auto
{
  "error": {
"root_cause": [
      {
"type": "illegal_argument_exception",
"reason": "Valid edit distances are [0, 1, 2] but was [3]"
      }
    ],
"type": "illegal_argument_exception",
"reason": "Valid edit distances are [0, 1, 2] but was [3]"
  },
"status": 400
}

```

Are there other places in Elasticsearch or Lucene where this validation might be occurring? I suspect there might be another layer of checks beyond the `MAXIMUM_SUPPORTED_DISTANCE` constant.

**Environment:**

- Elasticsearch version: 9.2.1

- Lucene version: 10.3.1

---

<div class="post-metadata">

**Author:** ![Mark\_Harwood1](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_harwood1/32/101255_2.png) [@Mark\_Harwood1](https://discuss.elastic.co/u/Mark_Harwood1)\
**Post date:** [November 16, 2025, 9:11am UTC](https://discuss.elastic.co/t/edit-distance-2-is-it-really-unconfigurable/383458/4 "2025-11-16T09:11:08Z")

</div>

This blog offers a glimpse into why it is not just a case of bumping a value:

> **[Lucene's FuzzyQuery is 100 times faster in 4.0](https://blog.mikemccandless.com/2011/03/lucenes-fuzzyquery-is-100-times-faster.html?m=1)**
>
> There are many exciting improvements in Lucene's eventual 4.0 (trunk) release, but the awesome speedup to FuzzyQuery really stands out, not...