Using REGEXP_LIKE in SQL Server 2025

Problem

Microsoft added several new features in SQL Server 2025, including an exciting suite of regular expression (regex) functions. After years of anticipation, there’s no longer a need to rely on CLR to use regex capabilities. As an experienced SQL developer, I enjoy finding specific rows, and the function that stands out to me is REGEXP_LIKE. I was drawn to it by its name, mainly because I frequently use the LIKE predicate. Right now, we are deciding whether to use it.

Solution

In this article, we’ll explore the REGEXP_LIKE function introduced in SQL Server 2025. First, we’ll review its basic syntax and how it offers more expressiveness than the classic LIKE predicate. Then, we’ll examine a more complex use case and compare the regex performance to classic methods. By the end of this article, I aim to answer the question: Should developers adopt the new REGEXP_LIKE function for string pattern matching in their T-SQL code?

Exploring REGEXP_LIKE

The easiest way I know to explain a regular expression (regex) is as a syntax used for pattern matching. For example, if you want to find an email address in a column that follows RFC rules or locate postal codes that don’t match the usual format, regex can be very helpful.

Let’s take a look at the syntax for the new REGEXP_LIKE function.

REGEXP_LIKE(string_expression, pattern_expression [ , flags ])

The code below shows that the function takes three arguments, with the last one being optional.

1. String_Expression – This is the expression you want to search for, such as the column Description or EmailAddress.
2. Pattern_Expression – This argument is the regex pattern you want to match. For me, the complex part.
3. Flags – This argument is optional, but will come in handy. There are four supported flags (i,m,s,c). I use the i most often to indicate the search is case-insensitive.

Below is an example of using this regex function on an email address. We want to locate any string that ends with @example.com to ensure it at least appears to be an email address.

WHERE REGEXP_LIKE(EmailAddress, '^[^@]+@example\.com$');

From the code above, you can see it’s relatively easy to build a simple pattern.

LIKE Predicate

After reading the section above, you might wonder why we would use the new function when the LIKE predicate could do the job. You’re not wrong. This simple predicate has been around as long as I’ve been writing SQL. It comes in handy when searching for basic string patterns, as shown in the example below.

WHERE EmailAddress LIKE '%@example.com';

However, what about introducing multiple rules? Is LIKE still a good solution?

Email Rules

1. The email can only contain one “@.”
   1. Invalid: jared.westove@r@example.com
2. The domain must contain at least one dot(.) after the “@.”
   1. Invalid: jared.westover@examplecom
3. The email cannot contain consecutive dots.
   1. Invalid: jared..westover@example.com
4. The top-level domain must be at least two characters and consist of letters.
   1. Invalid: jared.westover@e.com

Those are four rules that I came up with, but I’m sure there are many more for an email address to be considered valid per your company’s policy.

Demo Setup

We want to test this new function with a sizable dataset, and a million rows should suffice. For this demo, we’ll create a database containing one table named EmployeeLoad and three columns defined as:

1. Id, a simple integer
2. SampleText for indicating if it’s valid or what rule it violates
3. EmailAddress, this one is self-explanatory.

After creating the table, we’ll insert 1 million rows with email addresses that may be valid or invalid, as indicated in the rules above. Additionally, I’ll create a nonclustered index on the EmailAddress column. Keep in mind that to use the new regex functions, you must be using SQL Server 2025 or one of the Azure variants. Also, ensure database compatibility is set to 170.

/* MSSQLTips.com */
USE [master];
GO
IF DB_ID('RegexLIKEDemo') IS NOT NULL
BEGIN
    ALTER DATABASE RegexLIKEDemo SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
    DROP DATABASE RegexLIKEDemo;
END;
GO
CREATE DATABASE RegexLIKEDemo;
GO
ALTER DATABASE RegexLIKEDemo SET RECOVERY SIMPLE;
GO
USE RegexLIKEDemo;
GO
DROP TABLE IF EXISTS dbo.EmployeeLoad;
GO
CREATE TABLE dbo.EmployeeLoad
(
    Id INT IDENTITY(1, 1),
    SampleText NVARCHAR(100),
    EmailAddress NVARCHAR(255)
        CONSTRAINT PK_EmployeeLoad
        PRIMARY KEY CLUSTERED (Id)
);
GO
;WITH n
 AS (SELECT TOP (100000)
         ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS rn
     FROM sys.all_columns s1
         CROSS JOIN sys.all_columns s2
    )
INSERT INTO dbo.EmployeeLoad
(
    SampleText,
    EmailAddress
)
SELECT v.SampleText,
       v.EmailAddress
FROM n
    CROSS JOIN
    (
        VALUES
            ('Valid - Simple', 'jared.westover@example.com'),
            ('Valid - With numbers', 'henry123@example.com'),
            ('Valid - First initial last name', 'ljames@example.com'),
            ('Valid - With underscore', 'amanda_jones@example.com'),
            ('Valid - Different domain', 'liam.james@example.org'),
            ('Valid - With hyphen', 'noah-davis@example.net'),
            ('Invalid - Double @ (Rule 1)', 'henry.brown@@example.com'),
            ('Invalid - No dot after @ (Rule 2)', 'jared.wilson@examplecom'),
            ('Invalid - Consecutive dots (Rule 3)', 'buddy..miller@example.com'),
            ('Invalid - Short TLD (Rule 4)', 'sally.rodriguez@example.c')
    ) AS v (SampleText, EmailAddress);
GO
CREATE NONCLUSTERED INDEX IX_EmployeeLoad_EmailAddress
ON dbo.EmployeeLoad (EmailAddress);
GO
SELECT TOP (10)
    Id,
    SampleText,
    EmailAddress
FROM dbo.EmployeeLoad
ORDER BY Id ASC;
GO

Classic LIKE

Let’s start with the classic LIKE and rule 2 from above: The domain must contain at least one dot (.) after the “@.” How would we identify this pattern with LIKE? Using a wildcard in the code below should do the trick. I also want to include the CPU and elapsed time.

/* MSSQLTips.com */
SET STATISTICS TIME ON;
SELECT
    COUNT_BIG(1)
FROM dbo.EmployeeLoad
WHERE EmailAddress LIKE '%@%.%';
SET STATISTICS TIME OFF;

Statistics Time Results:

 SQL Server Execution Times:
   CPU time = 1769 ms,  elapsed time = 116 ms.

On the other hand, what if we want to use regex? The code below will work.

/* MSSQLTips.com */
SET STATISTICS TIME ON;
SELECT
    COUNT_BIG(1)
FROM dbo.EmployeeLoad
WHERE REGEXP_LIKE(EmailAddress, '@.*\.');
SET STATISTICS TIME OFF;

Statistics Time Results:

 SQL Server Execution Times:
   CPU time = 43777 ms,  elapsed time = 2488 ms.

The regex function takes nearly 20 times longer to complete while delivering the same results. Keep in mind that performance may vary depending on your hardware, database, and server settings, but based on this example, LIKE for simple patterns runs much faster.

REGEXP_LIKE In Action

Back to regex; now that we have our dataset, let’s build a SELECT statement to extract valid email addresses based on the four rules above. When developing a search pattern, whether with regex or another method, I think in terms of steps, so we’ll review each rule individually.

Rule 1: The email must have exactly one “@” symbol, no more, no less.

REGEXP_LIKE(EmailAddress, '^[^@]+@[^@]+$')

Rule 2: There needs to be at least one dot (.) after the “@” symbol.

REGEXP_LIKE(EmailAddress, '@.*\.')

Rule 3: The email cannot have consecutive dots (..). Notice the NOT in front of the function.

NOT REGEXP_LIKE(EmailAddress, '\.\.')

Rule 4: Finally, the domain must be at least two characters long.

REGEXP_LIKE(EmailAddress, '\.[a-zA-Z]{2,}$')

Now, let’s put it all together with the following SELECT statement and run it.

/* MSSQLTips.com */
SET STATISTICS TIME ON;
SELECT COUNT(1)
FROM dbo.EmployeeLoad
WHERE
   REGEXP_LIKE(EmailAddress, '^[^@]+@[^@]+$')
   AND REGEXP_LIKE(EmailAddress, '@.*\.')
   AND NOT REGEXP_LIKE(EmailAddress, '\.\.')
   AND REGEXP_LIKE(EmailAddress, '\.[a-zA-Z]{2,}$');
SET STATISTICS TIME OFF;
GO

Statistics Time Results:

SQL Server Execution Times:
   CPU time = 155726 ms,  elapsed time = 8983 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

If we wanted to return all the invalid emails, we could flip the logic around and use OR operators.

/* MSSQLTips.com */
SET STATISTICS TIME ON;
SELECT COUNT(1)
FROM dbo.EmployeeLoad
WHERE
   NOT REGEXP_LIKE(EmailAddress, '^[^@]+@[^@]+$')
   OR NOT REGEXP_LIKE(EmailAddress, '@.*\.')
   OR REGEXP_LIKE(EmailAddress, '\.\.')
   OR NOT REGEXP_LIKE(EmailAddress, '\.[a-zA-Z]{2,}$');
SET STATISTICS TIME OFF;

Statistics Time Results:

SQL Server Execution Times:
   CPU time = 153466 ms,  elapsed time = 8829 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

The results are pretty close in time to the prior inclusive method.

What about using a LIKE to accomplish the same thing? You can’t achieve the same results with LIKE alone. At least I couldn’t figure it out. However, you can with a combination of other functions. The code block below attempts to return valid email addresses.

/* MSSQLTips.com */
SET STATISTICS TIME ON;
SELECT COUNT(1)
FROM dbo.EmployeeLoad
WHERE 
    EmailAddress LIKE '%@%'
    AND LEN(EmailAddress) - LEN(REPLACE(EmailAddress, '@', '')) = 1
    AND CHARINDEX('.', EmailAddress, CHARINDEX('@', EmailAddress)) > CHARINDEX('@', EmailAddress)
    AND EmailAddress NOT LIKE '%..%'
    AND LEN(RIGHT(EmailAddress, CHARINDEX('.', REVERSE(EmailAddress)) - 1)) >= 2
    AND RIGHT(EmailAddress, CHARINDEX('.', REVERSE(EmailAddress)) - 1) NOT LIKE '%[^a-zA-Z]%';
SET STATISTICS TIME OFF;
GO

Statistics Time Results:

SQL Server Execution Times:
   CPU time = 7543 ms,  elapsed time = 472 ms.

The same results were returned much faster, and when I compare the outputs, they are identical. The table below summarizes the comparison.

Regex Syntax Complexity

People often argue that regex is complex, and I would agree. For me, writing regex is hard. But just because something is hard doesn’t mean you shouldn’t try. Do I have all of the regex patterns memorized? No way, I Google or use Claude every time I need one. However, there are certain characters I know by heart. The “^” means the start of a string, and “$” matches the end of a string. These two characters are also called anchors. This shows that the more you use it, the better you become.

Clean Up

Once you are done with this demo, don’t forget to delete the database.

/* MSSQLTips.com */
USE [master];
GO
IF DB_ID('RegexLIKEDemo') IS NOT NULL
BEGIN
    ALTER DATABASE RegexLIKEDemo SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
    DROP DATABASE RegexLIKEDemo;
END;
GO

Conclusion

In this article, I aimed to answer the question: Should developers adopt the new REGEXP_LIKE function for string pattern matching in their T-SQL code? Based on my findings, no, they shouldn’t. If the pattern is simple, use the LIKE predicate because it performs much faster. I tested this with multiple instances of SQL Server 2025 and found consistent results. I encourage you to perform your own tests. Brent Ozar, in his post, “T-SQL Has Regex in SQL Server 2025. Don’t Get Too Excited,” observed similar behavior where a simple LIKE outperformed regex.

For complex patterns, it’s a toss-up for me because if you only cared about performance, I would be inclined to say no to REGEXP_LIKE. However, maybe Microsoft will improve its performance down the road. If that day comes, then I believe it could reduce the complexity of stringing together several helper functions. Some developers might still prefer REGEXP_LIKE for readability, especially when performance isn’t a major concern.

Another thing to remember is that you don’t need to rely on just one method. Think of the regex functions as another tool in your toolbox.

Next Steps

• If you would like an overview of each of the new regex functions in SQL Server 2025, check out Scott Murray’s article, “New SQL Regex Functions in SQL Server 2025 and SSMS.”
• Would you like a deeper overview of the REGEXP_LIKE function? Koen Verbeeck delivers one in his article, “REGEXP_LIKE Function in SQL Server 2025.”
• For an overview of the new REGEXP_SPLIT_TO_TABLE function, read Aaron Bertrand’s article “Split strings by Regular Expressions in SQL Server 2025.”

Jared Westover

Jared Westover is a SQL Server specialist with two decades of industry experience covering T-SQL development, performance tuning, administration and Microsoft Fabric. He is currently a software architect at Crowe, an author at Pluralsight and primary contributor at sqlhabits.com.  On MSSQLTips.com, Jared is a respected award-winning author for his clever T-SQL solutions and bringing to light new real-world solutions to age-old development problems.

• MSSQLTips Awards
  • Achiever Award (75+ tips) – 2026
  • Author of the Year – 2023
  • Author Contender – 2024/2025