Regex in SQL Server 2025 & Azure SQL

SQL Server is al sinds 1989 een veelgebruikte database voor het opslaan van gegevens, waarin tekst vaak een belangrijke rol speelt. Ondanks dat SQL veel functionaliteit biedt voor het werken met tekst, heeft het tot de release van SQL Server 2025 geduurd voordat er ondersteuning kwam voor reguliere expressies, oftewel regex. In het verleden heb ik zelf nog een CLR-functie (Common Language Runtime) geschreven om dit mogelijk te maken, maar dat is nu niet meer nodig.

Iedereen die ooit heeft geprobeerd patronen in tekst te vinden, of een check constraint wilde gebruiken om data te valideren, herkent het probleem. Je begint eenvoudig met een LIKE, misschien een CHARINDEX, en voor je het weet zit je in een wirwar van SUBSTRING en geneste REPLACE-calls die lastig te doorgronden zijn.

Met de komst van native regex-functionaliteit in SQL Server 2025 en Azure SQL Database wordt dat een stuk eenvoudiger: expressieve en krachtige patronen, direct in je query’s.
In deze blog laat ik zien wat er mogelijk is, met praktische voorbeelden op basis van de bekende AdventureWorks-database.

Van LIKE naar regex

Voorheen zag een “simpele” validatie er vaak zo uit:

WHERE EmailAddress LIKE '%@%.%'

 Een valide e-mailadres voldoet hieraan, maar het accepteert bijvoorbeeld ook:

• test@. 
• @domain.com 
• …@.............nl

Regex pakt dit fundamenteel anders aan: je beschrijft het volledige patroon, in plaats van losse stukjes tekst.

De nieuwe regex-functies in het kort

De belangrijkste toevoegingen:

• REGEXP_LIKE → valideert of een string voldoet aan een pattern
• REGEXP_SUBSTR → haalt een match uit een string
• REGEXP_REPLACE → vervangt delen van een string

Laten we kijken naar een aantal concrete scenario’s op basis van de AdventureWorks2025 sample database.

1. E-mailvalidatie

Het valideren van e-mailadressen is een veelvoorkomend scenario.

SELECT EmailAddress
FROM Person.EmailAddress
WHERE NOT REGEXP_LIKE(EmailAddress, '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$');

Resultaat:

• We selecteren alle e-mailadressen die niet voldoen aan het pattern 
• Handig voor data quality checks 

Deze regex is overigens niet volledig. Toch laat dit voorbeeld goed zien hoe je met regex eenvoudig dit soort validaties kunt uitvoeren.

2. Domeinen extraheren

je wilt inzicht krijgen in welke domeinen in je dataset voorkomen.

SELECT REGEXP_SUBSTR(EmailAddress, '@(.+)$') AS Domain,
	COUNT(*) AS Count
FROM Person.EmailAddress
GROUP BY REGEXP_SUBSTR(EmailAddress, '@(.+)$')

Resultaat:

• Een overzicht van de verschillende domeinen en hoe vaak deze voorkomen
• Ideaal voor rapportages

3. Data anonimiseren (AVG-proof)

Om te voorkomen dat persoonsgegevens op test- en ontwikkelomgevingen terechtkomen, wordt vaak anonimisatie toegepast. Met de REGEXP_REPLACE-functie kun je bijvoorbeeld e-mailadressen maskeren.

SELECT EmailAddress,
       REGEXP_REPLACE(EmailAddress, '(^.).*(@.*$)', '\1***\2') AS Masked
FROM Person.EmailAddress;

Resultaat:

• De eerste letter blijft zichtbaar
• Het domein blijft intact
• Het middelste deel wordt vervangen

Ideaal voor:

• Testdata
• Logging en auditing

4. Complexe productcodes filteren

Regex is ook goed toepasbaar bij gestructureerde codes. Denk aan Nederlandse postcodes of productcodes, zoals in de AdventureWorks-database.

SELECT Name, ProductNumber
FROM Production.Product
WHERE REGEXP_LIKE(ProductNumber, '^[A-Z]{2}-?[0-9]{4}$');

Resultaat:

• Twee hoofdletters
• Een optioneel streepje
• Vier cijfers

5. Data opschonen

Stel dat je alleen letters wilt behouden:

SELECT FirstName,
       REGEXP_REPLACE(FirstName, '[^A-Za-z]', '-') AS CleanName
FROM Person.Person;

Alles wat geen letter is, wordt vervangen door een streepje.

Dit zou zonder Regex-functionaliteit een gedrocht van een statement worden met veel geneste REPLACE-ketens of een common table expression.

6. Check constraints

Naast het gebruik in queries kun je de regex-functies ook gebruiken in check constraints om te garanderen dat de data in je tabel voldoet aan een bepaald patroon. Bijvoorbeeld een Nederlands telefoonnummer.

ALTER TABLE Person.Person
ADD CONSTRAINT CK_Person_Phone_Format
CHECK (
    REGEXP_LIKE(PhoneNumber, '^(\+31|0)[0-9]{9}$') = 1
);

Een flinke stap vooruit

Wanneer je deze voorbeelden naast de oude aanpak legt, zie je drie duidelijke voordelen:

1. Minder code
- Wat eerst vijf tot tien (of meer) regels code waren, past nu in één expressie.

2. Betere leesbaarheid
- Je beschrijft wat je zoekt, in plaats van hoe je het moet vinden.

3. Minder bugs
- Regex dwingt je om expliciet te zijn over patronen en is goed los van je database te testen.

Performance

Regex staan niet direct bekend om hun snelheid. Complexe patronen kunnen veel CPU kosten. Een eenvoudige LIKE zal daarom in bepaalde scenario’s beter kunnen presteren vergeleken met een regex. Microsoft heeft wel veel moeite gestoken om de performance flink te verbeteren vergeleken met de eerste implementaties die beschikbaar kwamen in Azure SQL Database. Zo worden nu bijvoorbeeld ook indexen gebruikt en is het CPU-gebruik verminderd. Wanneer ik de eerste e-mailcheck uitvoer op een tabel met bijna 20.000 records, laat het execution plan zien dat er geen verschil zit tussen de oplossing met een regex en een LIKE. Ook de client statistics zijn zeer vergelijkbaar.

“It depends” is hier ook van toepassing. Afhankelijk van je data en je regex zul je moeten kijken of de regex-functionaliteit de beste oplossing is.

Conclusie

Met native regex in SQL Server 2025 en Azure SQL Database krijgt SQL een volwassen manier om met tekstpatronen om te gaan.

Wat eerst vaak ingewikkelde workarounds vereiste, wordt nu expressiever, onderhoudbaarder en minder foutgevoelig.

Voor iedereen die regelmatig met datakwaliteit, ETL of stringmanipulatie werkt, is dit geen kleine verbetering, maar een fundamentele stap vooruit.

Meer weten?

Wil je meer weten? Neem dan gerust contact met ons op of bespreek jouw specifieke situatie.