Comparing strings has always been hard when we don't have great data quality. If we need exact matches, SQL Server works great. However, we often expect users to enter values without typos and know what values they want to find. Or at least know part of the string. However, matching with wildcards or partial strings has performance implications that can slow down our systems.

In SQL Server 2025, we have several new functions that help with fuzzy string matching. These new functions are: EDIT_DISTANCE(), EDIT_DISTANCE_SIMILARITY)(, JARO_WINKLER_DISTANCE)(, and JARO_WINKLER_SIMILARITY(). This article will examine the first two functions and explain how they work. The next article will cover the Jaro-Winkler functions. I hope someone will expand upon this overview with specific articles that help developers solve specific problems (or maybe I will).

This is part of a series on how the T-SQL language is evolving in SQL Server 2025.

Note: Some of these changes are already available in the various Azure SQL products.

Past Solutions

There have been tools in SQL Server that try to help us perform this in an automated way. We've had SOUNDEX() and DIFFERENCE() for years, but these were fairly rudimentary ways of looking for "close" matches for strings. Here at SQL Server Central, we've had these articles published over the years.

• Fuzzy-String Search: Find misspelled information with T-SQL 
• Fuzzy Search
• Roll Your Own Fuzzy Match / Grouping (Jaro Winkler) - T-SQL
• Sound Matching and a Phonetic Toolkit
• Soundex - Experiments with SQL CLR
• Soundex - Experiments with SQLCLR Part 2
• Soundex - Experiments with SQLCLR Part 3

ALTER DATABASE SCOPED CONFIGURATION
SET PREVIEW_FEATURES = ON;

When you do this, you can run the functions, as shown here:

If you don't enable this config, you get an error when attempting to run a function.

create table Names
(
    NameID int not null identity(1, 1)
  , NameVal varchar(100)
)
GO
INSERT INTO dbo.Names
(
    NameVal
)
VALUES
('James')
, ('Mary')
, ('Robert')
, ('Patricia')
, ('John')
, ('Jennifer')
, ('Michael')
, ('Linda')
, ('William')
, ('Elizabeth')
, ('David')
, ('Barbara')
, ('Richard')
, ('Susan')
, ('Joseph')
, ('Jessica')
, ('Thomas')
, ('Sarah')
, ('Charles')
, ('Karen')
go

declare @s1 varchar(10) = 'Steve'
      , @d  int         = 12;

select NameVal
     , edit_distance(NameVal, @s1)
from dbo.Names;

create table Words
(
    Wordid int not null identity(1, 1)
  , Word varchar(20)
);
go
insert dbo.Words
(
    Word
)
values
('Color')
, ('Colour')
, ('while')
, ('Whilst')
, ('colour');
go

DECLARE @s VARCHAR(10) = 'colr';
SELECT Word,
       @s AS WordToMatch,
       EDIT_DISTANCE_SIMILARITY(word, @s) AS DistanceSimilarity,
       EDIT_DISTANCE(word, @s) AS Distance,
       LEN(word) AS WordLen,
       LEN(@s) AS StringLen
FROM dbo.Words;
GO

edit_distance( <char_expression_1>, <char_expression_2>)

The return value is an integer, which is the percentage match, based on the algorithm

A few more examples that might help illustrate this. I'll use my Names table, but I'll add a few names to the list.

INSERT INTO dbo.Names
(
    NameVal
)
VALUES
('Steve')
, ('Steven')
, ('Stephen')
, ('Esteban')
, ('steve')
, ('steven')
, ('stephen')
GO

Now let's query for "Stve", which is a common mistake I'll make when typing too fast. If I do this, I see a similarity that varies quite a bit. I'll sort these by the percentage match descending. Notice that "Steve" is the best match, with "Steven" second. "steve" is only a 67% match with this algorithm. This is because the larger string value in each case is the NameVal, and one is larger than the other. Matching shorter to longer strings can cause this issue.

I've included the EDIT_DISTANCE() to make this easier to calculate.

If we look at a different match, with a bigger misspelling, I get different results. In this case, I still get a different level of matching between "Steve" and "steve" because of a similar string length issue.

I'll include the code below for the queries, so you can test them yourself. I've included two additional queries where I coalesce the expressions to upper case. Lower works as well, and I'll discuss those below.

DECLARE @s VARCHAR(20) = 'Stve';
SELECT NameVal,
       @s,
       EDIT_DISTANCE_SIMILARITY(@s, NameVal)
       , EDIT_DISTANCE(@s, NameVal)
FROM Names
ORDER BY EDIT_DISTANCE_SIMILARITY(@s, NameVal) DESC;
GO
DECLARE @s VARCHAR(20) = 'Stevem';
SELECT NameVal,
       @s,
       EDIT_DISTANCE_SIMILARITY(@s, NameVal)
       , EDIT_DISTANCE(@s, NameVal)
FROM Names
ORDER BY EDIT_DISTANCE_SIMILARITY(@s, NameVal) DESC;
GO 
DECLARE @s VARCHAR(20) = 'Stve';
SELECT NameVal,
       @s,
       EDIT_DISTANCE_SIMILARITY(UPPER(@s), UPPER(NameVal)) DistanceSimilarity
       , EDIT_DISTANCE(UPPER(@s), UPPER(NameVal)) AS Distance
FROM Names
ORDER BY EDIT_DISTANCE_SIMILARITY(UPPER(@s), UPPER(NameVal)) DESC;
GO
DECLARE @s VARCHAR(20) = 'Stevem';
SELECT NameVal,
       @s,
       EDIT_DISTANCE_SIMILARITY(UPPER(@s), UPPER(NameVal)) DistanceSimilarity
       , EDIT_DISTANCE(UPPER(@s), UPPER(NameVal)) AS Distance
FROM Names
ORDER BY EDIT_DISTANCE_SIMILARITY(UPPER(@s), UPPER(NameVal)) DESC;
GO

When I run the last two queries, I get mirror images of the results from a shorter to a longer string, because of the GREATEST() function in the formula. The results are shown here, and notice that the close matches "Steve", Steve", and "steven" are the same with longer to shorter. Shorter to longer has a spread for these values from 80-67.

In the shorter-longer case (Stve to Steve), we find that Stephen shows a 43% match, while in the longer case, it's a 57% match. That's interesting, as a number I might use for matches would be 50%, at least as a guess. Looking at data matters here, as I might want to allow different levels of matching. For example, perhaps I would want to write something like this:

DECLARE @s VARCHAR(20) = 'Stephn';
SELECT NameVal,
       @s,
       EDIT_DISTANCE_SIMILARITY(UPPER(@s), UPPER(NameVal)),
       CASE
           WHEN LEN(@s) > LEN(NameVal)
                AND EDIT_DISTANCE_SIMILARITY(UPPER(@s), UPPER(NameVal)) >= 67 THEN
               'Close match'
           WHEN LEN(@s) <= LEN(NameVal)
                AND EDIT_DISTANCE_SIMILARITY(UPPER(@s), UPPER(NameVal)) >= 50 THEN
               'Close match'
           WHEN LEN(@s) > LEN(NameVal)
                AND EDIT_DISTANCE_SIMILARITY(UPPER(@s), UPPER(NameVal)) >= 50 THEN
               'Partial match'
           WHEN LEN(@s) <= LEN(NameVal)
                AND EDIT_DISTANCE_SIMILARITY(UPPER(@s), UPPER(NameVal)) >= 40 THEN
               'Partial match'
           ELSE
               'poor match'
       END AS DistanceSimilarity
FROM Names
ORDER BY EDIT_DISTANCE_SIMILARITY(UPPER(@s), UPPER(NameVal)) DESC;

This gives me better results, as I'm adjusting the matchings based on the lengths. You can see below that the variations of Steve give me close or partial matches. Non-Steve names are poor matches.

Obviously this is very data dependent, and you could end up with complex query statements, but you do have some tools here to experiment with and test with your data values. I would make sure that you log the values being compared and continuously run tests on what might be considered a close, partial, and poor match. In asking Claude what made sense, I got this as a set of percentages for fuzzy matching

• 90-100%: Exact or near-exact matches - typos, minor misspellings
• 80-89%: Strong matches - acceptable for most matching scenarios
• 70-79%: Moderate matches - may need human review
• Below 70%: Weak matches - usually too dissimilar

You might use this or alter this based on your situation.

Comparison with SOUNDEX

SOUNDEX converts things to upper case, so it works pretty closely to my final experiment. Here are the results of the last query with SOUNDEX values included. I won't add a calculation of matches with SOUNDEX, but the last two columns are very similar in the close match values and close in the partial matches. The exception being the row with "Esteban".

As a comparison, I'll remove the UPPER() clauses and you can see how this works. SOUNDEX looks pretty good still

Summary

There are new functions in SQL Server 2025 (and Azure SQL) to help you determine whether two string expressions are close in matching. This article looked at EDIT_DISTANCE() and EDIT_DISTANCE_SIMILARITY() first, which use the Damerau-Levenshtein algorithm to determine distance and the percentage similarity. We saw how we can get distances returned, as well as a percentage of that distance. Both functions are dependent on case, so you might get results that you do not expect. If you case about case, that's great.

The percentage similarity depends on string length, so testing is needed to determine how to weight the results.

There was a short section that shows how SOUNDEX() compares, and this doesn't seem to be a lot different, though there might be nuances that help you better determine whether there is a fuzzy match or now. There definitely is the ability to get more granular on matching though depending on the changes and if CASE matters, this might not be what you need.

Fuzzy string matching is hard, and there isn't a great solution. I think AI does a better job here than any programmed code with functions, but we will see over time.

In the next article, we will look at the Jaro Winkler functions.