At this link you can find a list of the new features that will be added in SQL Server 2025. I wanted to go through some of the new features for T-SQL that may be interesting to other developers.
I’m running the 2025 evaluation edition (17.0.700.9)
I’ve posted a script to GitHub with SQL for the new T-SQL features that I’ve covered.

*) Regular Expressions

In my opinion, the addition of Regular Expressions (regex) will be the feature I’d use the most. SQL Server has matching using LIKE, but regex is much more powerful. If you’ve never used regex, Geeks For Geeks has a good introduction to them. Basically, it’s a set of characters that form a pattern for searching text.

Here’s an example looking for valid email addresses in a list of strings. Here’s SQL to create an EmailTest table:

DROP TABLE IF EXISTS dbo.EmailTest;

CREATE TABLE dbo.EmailTest (Email VARCHAR(100) NOT NULL);

INSERT INTO dbo.EmailTest(Email)
VALUES 
('example@example.com'),
('example1@example.com'),
('EXAMPLE@example.com'),
('example@example.c'),
('example.com'),
('example');

We’ll use a simplified pattern to look for email addresses. We’ll look for strings with letters or numbers, then an at sign, more letters, then a dot with at least two letters behind it. (This doesn’t cover all possible addresses, of course). We’re also only looking for lower case letters, to show the case-sensitivity.

We’ll use the REGEXP_LIKE function to search the Email column for matches:

SELECT Email FROM dbo.EmailTest 
WHERE REGEXP_LIKE(Email, '([a-z0-9]+@[a-z]+\.[a-z]{2,})');

Which will return:
example@example.com
example1@example.com
EXAMPLE@example.com

So the default is case-insensitive. If we wanted a case-sensitive search, we’ll use the optional ‘c’ flag:

SELECT Email FROM dbo.EmailTest 
WHERE REGEXP_LIKE(Email, '([a-z0-9]+@[a-z]+\.[a-z]{2,})', 'c');

Which will return:
example@example.com
example1@example.com

There’s also a ‘i’ flag for case-insensitive, if we want to explicitly declare that.

There are several other regex functions available, for replacing strings, splitting strings on a delimiter, and others.

I have a reference sheet on the site for regex.

*) Fuzzy String Match

There are also functions for fuzzy string matches, to find strings that are similar to one another, but not an exact match.

We’ll start with the EDIT_DISTANCE_SIMILARITY function, which returns a number to indicate how similar two strings are, 100 being an exact match and 0 for no similarity. Here are some calls, with the answer after the dashes:

SELECT EDIT_DISTANCE_SIMILARITY('Attitude', 'Attitude'); -- 100

SELECT EDIT_DISTANCE_SIMILARITY('Attitude', 'Altitude'); -- 88

SELECT EDIT_DISTANCE_SIMILARITY('Zero', 'One'); -- 0

There’s also an EDIT_DISTANCE function. It returns the number of changes needed to convert one string into the other. The documentation describes changes as “insertions, deletions, substitutions, and transpositions”.

SELECT EDIT_DISTANCE('Attitude', 'Attitude'); -- 0

SELECT EDIT_DISTANCE('Attitude', 'Altitude'); -- 1

SELECT EDIT_DISTANCE('Zero', 'One'); -- 4

Both of these function use the Damerau-Levenshtein algorithm for their calculations. There are also two functions that use the Jaro-Winkler algorithm:
JARO_WINKLER_DISTANCE
JARO_WINKLER_SIMILARITY

I did find a comparison of the two algorithms here, if you are interested in that.

*) REST Calls From Database Engine

The next feature is the introduction of the sp_invoke_external_rest_endpoint stored procedure, which will make REST calls from the database engine. I know Postgres has this functionality, I worked at a place that made use of it. I’m not sure the database engine is the best place to make a REST call from, but there may be cases where this is useful.
sp_invoke_external_rest_endpoint will allow us to make a call to a URL that will return data to us.

Before starting, we’ll need to enable the feature. There’s also a permission to be granted. I was running as an DB owner, so I didn’t need the permission.

--Enable:
EXECUTE sp_configure 'external rest endpoint enabled', 1;
RECONFIGURE WITH OVERRIDE;

--Permission:
GRANT EXECUTE ANY EXTERNAL ENDPOINT TO [user];

We’ll use a simple example. I found a call that doesn’t require authentication and is free to use. This call will return holidays in the United States in the year 2025:
https://date.nager.at/api/v3/publicholidays/2025/US

DECLARE @ReturnCode AS INT;
DECLARE @Response AS NVARCHAR (MAX);

EXECUTE
    @ReturnCode = sp_invoke_external_rest_endpoint
    @url = N'https://date.nager.at/api/v3/publicholidays/2025/US',
    @method = 'GET',
    @response = @response OUTPUT;

SELECT @ReturnCode AS ReturnCode,
       @Response AS Response;

We can also set Payload and Headers, if needed.

Return value (@ReturnCode) is 0 for a successful (2xx) call. A call with an error will return the response code.
In this case, the @response value is a JSON document.

Part 2:
I’ll follow up with a second post on additional T-SQL features.