Azure SQL Database’s Dynamic Data Masking just got a significant upgrade: regex-based pattern matching. Instead of relying on a handful of built-in masking functions (default, email, random), you can now define custom regex patterns to match and mask sensitive data – emails, phone numbers, social security numbers, credit card fragments, or any pattern you can express in a regular expression.
This is preview for now, but it closes a gap that has frustrated DBAs and security engineers since DDM launched.
The problem with old DDM
The original Dynamic Data Masking shipped with four masking functions. Default masking shows XXXX for strings. Email masking reveals the first character and masks the rest. Random masking applies a random value within a range. Custom string masking replaces part of the value with a padding string.
These work fine for simple cases but fall apart the moment your data has non-standard formats. Phone numbers stored with different country codes and delimiters. Internal employee IDs with mixed formats. Medical record numbers that follow department-specific patterns. In each case, the built-in functions either miss the data entirely or require you to implement masking logic in your application layer instead of keeping it where it belongs – in the database.
How regex DDM works
Instead of picking from a dropdown of masking functions, you write a regex pattern that identifies the sensitive content within a column value, and specify what replacement string to show in its place. The pattern matches anywhere in the column value (not just the whole value), so a single column containing free text with embedded phone numbers can be masked without touching the rest of the text.
For example, a pattern like \b\d{3}[-.]\d{3}[-.]\d{4}\b catches most US phone number formats. An email pattern like \b[\w.+-]+@[\w-]+\.[\w.-]+\b matches email addresses embedded in notes or comments columns. The replacement text replaces just the matched portion, leaving surrounding content intact.
The setup is done through T-SQL ALTER TABLE ... ALTER COLUMN ... ADD MASKED WITH (FUNCTION = 'regex(pattern, replacement)'). No Azure portal click-throughs, no PowerShell – just a SQL statement that fits naturally into your existing schema migration scripts.
Where this matters most
Three scenarios stand out.
First, columns with mixed content. A notes column that sometimes contains email addresses or phone numbers. A customer comments field with accidental PII. Before regex DDM, you had to either mask the entire column (losing useful data) or handle masking at the application level (easy to miss). Now you can surgically mask only the sensitive patterns.
Second, compliance audits wanting proof that PII is masked at the database level rather than trusting application code. Regex DDM lets you point to a centralized masking policy enforced by the database engine itself. Auditors tend to like that more than “we filter it in the API layer.”
Third, multi-tenant databases where different tenants have different data format requirements. You can apply broader regex patterns that cover all variations rather than maintaining separate application logic per tenant.
Whats still preview behavior
Regex DDM is in preview, which means no SLA and potential breaking changes before GA. The regex engine uses .NET regex syntax (same as SQL Server’s dbo.RegexMatch patterns if you have used those). Test your patterns thoroughly – a regex that is too broad will mask more than intended, and one that is too narrow gives false confidence about protection.
Performance overhead exists. Regex matching at query time adds CPU cost compared to the simple built-in masking functions. Microsoft has not published benchmark numbers yet. For high-throughput OLTP workloads, measure the impact before rolling out regex DDM on hot tables.
The feature is limited to string columns (char, varchar, nchar, nvarchar). Numeric and date columns still rely on the original masking functions. If you need to mask numeric PII like salary or age, you still use random masking. That is not really a limitation – numbers rarely embed in free text the way emails and phone numbers do – but worth knowing before you plan your rollout.
Setting it up
The T-SQL syntax is straightforward. Identify the columns that need pattern-based masking, write your regex, and apply it:
ALTER TABLE dbo.Customers
ALTER COLUMN Notes ADD MASKED WITH (
FUNCTION = 'regex(
''\b[\w.+-]+@[\w-]+\.[\w.-]+\b'',
''***EMAIL***''
)'
);Users without the UNMASK permission see “***EMAIL***” in place of any email addresses embedded in the Notes column, while the rest of the content remains visible. For users with UNMASK, nothing changes – they see the raw data as always.
The takeaway
Regex DDM is one of those features that looks minor on paper but solves a real pain point. The old DDM was good enough for simple cases but left security teams maintaining sidecar masking logic in applications because the database-level masking was too rigid. Regex support makes database-level masking viable for real-world data with its messy, inconsistent formats. If you have been putting off DDM adoption because the built-in functions did not cover your data shapes, this preview is worth testing.