rss.livelink.threads-in-node

Unlocking the Power of Azure Resource Graph Explorer for Comprehensive Database Inventory

akumaranchath — Fri, 29 May 2026 16:03:38 GMT

Why Taking Inventory is Crucial

Taking inventory of databases in Azure is a critical practice for any organization managing cloud resources. It ensures that all databases are accounted for, providing a comprehensive overview of the organization’s data assets. This visibility is essential for effective management and optimization of resources, as it allows for better planning and allocation based on actual usage and requirements.

An accurate inventory also plays a key role in identifying potential vulnerabilities and compliance issues. By knowing exactly what databases exist and where they reside, organizations can take proactive measures to secure sensitive data and adhere to regulatory standards.

Additionally, maintaining an up-to-date inventory facilitates efficient troubleshooting and maintenance. When issues arise, having detailed insights into the configuration and status of each database significantly reduces resolution time.

In short, keeping an accurate inventory of Azure databases supports operational efficiency, security, and compliance.

Who Does This Matter To

For roles such as product owners or operations managers, this task becomes even more critical. You may need to query the entire data estate to consolidate information for governance, reporting, or strategic planning. Without a centralized view, managing large-scale environments becomes challenging and prone to errors.

How Azure Resource Graph Explorer Helps

Azure Resource Graph Explorer is a powerful tool designed to extend Azure Resource Management by enabling efficient and performant resource exploration across multiple subscriptions. It allows users to:

Query resources with complex filtering, grouping, and sorting by resource properties.
Explore resources at scale across multiple subscriptions.
Iterate queries based on governance requirements.

This makes ARG an ideal solution for managing and governing large-scale environments where visibility and control are paramount.

An Azure Resource Graph query like this one can help users to get an inventory of Azure SQL installations from data estates spanning across multiple subscriptions.

resources | where type =~ "microsoft.sqlvirtualmachine/sqlvirtualmachines" | project SubscriptionId = subscriptionId, ResourceGroup = resourceGroup, Name = name, type, Location = location, tags, elasticPoolId = "", ServiceType = "SQL VM", Edition=tostring(properties.sqlImageSku), Environment=tostring(tags.opEnvironment), PricingModel="vCores", ServiceTier=tostring(properties.sqlImageOffer), IsAHB = iff(tostring(properties.sqlServerLicenseType) =~ "AHUB", "Yes", iff(tostring(properties.sqlServerLicenseType) =~ "PAYG" and tostring(tolower(properties.sqlImageSku)) =~ "Developer", "Yes", "No")) | join kind=inner (resources | where ['type'] =~ 'microsoft.compute/virtualmachines' | project SubscriptionId = subscriptionId, ResourceGroup = resourceGroup, Name = name, Location = location, Num=tostring(properties.hardwareProfile.vmSize)) on Name, ResourceGroup, Location, SubscriptionId | project-away SubscriptionId1,ResourceGroup1,Name1,Location1 | union ( Resources | project SubscriptionId = subscriptionId, ResourceGroup = resourceGroup, Name = name, type, Location = location, tags, elasticPoolId = tolower(tostring(properties.elasticPoolId)), ServiceType = case(type =~ "microsoft.sql/managedinstances", "Azure SQL MI", type =~ "microsoft.sql/servers/databases", iff(tolower(properties.currentSku.tier)=~"datawarehouse", "Synapse", "Azure SQL DB"), type =~ "microsoft.sql/servers/elasticpools", "Azure SQL DB Elastic Pools", "Azure SQL VM"), Edition = case(type in~ ("microsoft.sql/managedinstances","microsoft.sql/servers/databases","microsoft.sql/servers/elasticpools"), iff(tolower(properties.currentSku.tier)=~"datawarehouse", "Dedicated Pools", "Azure SQL") , "SQL VM"), Environment=tostring(tags.opEnvironment), Num = tostring(case(type =~ "microsoft.sql/managedinstances", toint(sku.capacity), type =~ "microsoft.sql/servers/databases", toint(properties.currentSku.capacity), type =~ "microsoft.sql/servers/elasticpools", toint(properties.perDatabaseSettings.maxCapacity), 0)), PricingModel = case(type =~ "microsoft.sql/managedinstances", "vCores", type =~ "microsoft.sql/servers/databases", iff(tolower(properties.currentSku.tier)=~"datawarehouse", "DWU", iff((tolower(sku.tier) in ("basic","standard","premium")), "DTU", "vCores")), type =~ "microsoft.sql/servers/elasticpools", iff((tolower(sku.tier) in ("basic","standard","premium")), "DTU", "vCores"), "vCores"), ServiceTier = case(type =~ "microsoft.sql/managedinstances", sku.tier, tolower(properties.currentSku.tier)), MaxDatabaseSizeGB = iff(tostring(properties.currentSku.tier)=~"hyperscale", 1000,properties.maxSizeBytes/(1024 * 1024 * 1024)), IsAHB = case(properties.licenseType == 'BasePrice', "Yes", "No"), Is_Replica=iff(tostring(properties.secondaryType) in("Geo","Standby"), "Yes","No"), Is_Standby_Replica=iff(tostring(properties.secondaryType)=~ "Standby", "Yes","No") | where (type =~ 'Microsoft.Sql/servers/databases' or type =~ "microsoft.sql/managedinstances" or type =~ "microsoft.sql/servers/elasticpools") and ServiceTier !in~ ("system") | join kind=leftouter ( Resources | where type =~ 'microsoft.sql/servers/elasticpools' | project elasticPoolId = tolower(id), elasticPoolName = name, elasticPoolSize=tostring(properties.perDatabaseSettings.maxCapacity)) on elasticPoolId | project-away elasticPoolId1 ) | order by ['Name'] asc

This process can be further bolstered by automating the running of Azure Resource Graph queries and even acting on the results.

Let us know if any of these resonate with you or if have more suggestions!

Feedback

If you have feedback or suggestions for improving this data migration asset, please comment here or contact the Azure Databases SQL Customer Success Engineering Team (datasqlninja@microsoft.com) directly. Thanks for your support!

Note: For additional information about migrating various source databases to Azure, see the Azure Database Migration Guide.

The Odd Couple - Latches and KEEP_NULLS

David_Lyth — Fri, 29 May 2026 15:58:10 GMT

Introduction

Bulk loading is one of the most heavily optimised data paths in SQL Server. When it works well, hundreds of concurrent sessions can push millions of rows per minute into large tables with minimal CPU overhead. But when it doesn't, the symptoms can be baffling: CPU sits almost idle while every session waits, and throughput collapses by orders of magnitude.

We recently worked with a customer running a large-scale data processing platform on Azure SQL Hyperscale Database. The workload used Spark to bulk-insert data from hundreds of concurrent sessions into multi-billion-row tables, each using SEQUENCE objects to generate surrogate keys. After the team switched from row-by-row inserts to parallel bulk loading - a change that should have been a clear win - job durations went from minutes to over an hour. CPU utilisation sat at 2–5% while latch waits consumed over 98% of elapsed time.

The root cause turned out to be a surprising interaction between two seemingly unrelated SQL Server features: SEQUENCE object latch modes and the KEEP_NULLS bulk insert option. Each is individually well-documented, but their combined effect under high-concurrency bulk insert workloads produced catastrophic serialisation that was not obvious from the documentation alone.

This post distils the lessons learnt from that engagement into a reusable guide. We explain the mechanism, demonstrate the issue with reproducible tests on SQL Server 2025, and provide four independent fixes - the simplest of which is a single client-side configuration change that requires no schema modifications, no table rebuilds, and no downtime.

Note: Results may vary depending on hardware, SQL Server version, and workload patterns. All tests in this post were run on SQL Server 2025 (CU3). We recommend validating in your own dev/test environment.

Background: The Ingredients

The workload used a common pattern for generating surrogate keys during bulk inserts:

SEQUENCE objects - CREATE SEQUENCE ... AS NUMERIC(28,0) - provided unique IDs
DEFAULT constraints - ALTER TABLE ... ADD CONSTRAINT ... DEFAULT (NEXT VALUE FOR dbo.MySequence) - auto-populated IDs for rows that didn't supply them
INSERT BULK - Spark's JDBC SQLServerBulkCopy loaded data in parallel from ~350 concurrent sessions
The application called sp_sequence_get_range to pre-allocate ID ranges and supplied IDs with every row - the DEFAULT was there as a safety net, not the primary path

Each component is sensible on its own. The problem emerges from their interaction.

The Problem: Two Layers of Serialisation

Layer 1: INSERT BULK Fires the DEFAULT - Even When You Supply Values

When INSERT BULK (the TDS protocol used by BCP, BULK INSERT, and JDBC SQLServerBulkCopy) runs without the KEEP_NULLS option, the engine sets an internal flag (HNT_KEEPDEFAULT) that wraps every DEFAULT-constrained column as:

ISNULL(source_value, default_expression)

The default_expression - in this case NEXT VALUE FOR - is evaluated by a Sequence Project iterator that runs unconditionally per row, before the ISNULL decides whether to use it. Even though every row in our workload supplied a valid non-NULL ID, the sequence latch was still acquired, the counter was incremented, and the generated value was discarded.

This is fundamentally different from a regular INSERT ... SELECT statement, where NEXT VALUE FOR only fires if the column is actually omitted from the column list.

Layer 2: NUMERIC Sequences Take Exclusive Latches

SQL Server's sequence generator uses different synchronisation strategies depending on the sequence data type:

Sequence Type	Latch Mode	Concurrency
`NUMERIC` / `DECIMAL`	Exclusive (EX) per row	Fully serialised - one thread at a time
`BIGINT` / `INT`	Shared (SH) + atomic CPU increment	Concurrent - multiple threads progress

The difference is not in the sequence cache (which only reduces disk I/O) but in the in-memory latch that protects the counter. With a NUMERIC(28,0) sequence, every single row - across all 350 concurrent sessions - must wait in line for one exclusive latch.

The Combined Effect

Combining both layers produces catastrophic serialisation:

350 sessions × 50,000 rows each = 17.5 million unnecessary exclusive latch acquisitions per bulk load cycle
Each acquisition blocks all other sessions
CPU sits idle while threads wait in the latch queue
With NUMERIC(28,0) + no KEEP_NULLS, the workload was 98% wait time and 2% CPU time

The diagnostic signature is unmistakable: LATCH_EX dominant in wait stats, low CPU utilisation, and all waiting sessions blocked on METADATA_SEQUENCE_GENERATOR.

Proving It: The KEEP_NULLS Experiment

The simplest proof is to BCP 10,000 rows - all with application-supplied IDs - and check whether the sequence counter advances.

Setup

CREATE SEQUENCE dbo.Seq_Orders AS NUMERIC(28, 0) START WITH 1 INCREMENT BY 1 CACHE 50000000; GO CREATE TABLE dbo.Orders ( OrderID NUMERIC(28, 0) NOT NULL CONSTRAINT DF_Orders_ID DEFAULT (NEXT VALUE FOR dbo.Seq_Orders), CustomerID INT NOT NULL, OrderDate DATE NOT NULL, Amount DECIMAL(10, 2) NOT NULL, Filler CHAR(80) NOT NULL DEFAULT ('x'), CONSTRAINT PK_Orders PRIMARY KEY CLUSTERED (OrderID) ); GO

Generate a BCP data file with IDs 1-10,000 pre-assigned by the application.

Test 1: BCP Without KEEP_NULLS (Default Behaviour)

bcp MyDB.dbo.Orders in orders.dat -c -t"," -S localhost\sql25 -T

Result:

Metric	Value
Rows stored	10,000
Stored OrderIDs	1-10,000 (app-supplied - correct)
Sequence current_value	20,000 (advanced from 1)

The sequence advanced by at least 10,000 values, even though the stored IDs are entirely from the application. The NEXT VALUE FOR default fired per-row, consumed sequence values, and discarded them all.

Test 2: BCP With KEEP_NULLS

bcp MyDB.dbo.Orders in orders.dat -c -t"," -S localhost\sql25 -T -k

Result:

Metric	Value
Rows stored	10,000
Stored OrderIDs	1-10,000 (app-supplied - correct)
Sequence current_value	1 (unchanged)

With -k (KEEP_NULLS), the sequence did not advance at all. The ISNULL wrapper was not applied, the Sequence Project iterator was not added to the plan, and all 10,000 latch acquisitions were eliminated.

Test 3: Table Without DEFAULT (Control)

bcp MyDB.dbo.Orders_NoDefault in orders.dat -c -t"," -S localhost\sql25 -T

Result: Sequence unchanged at 1. No DEFAULT means no Sequence Project, regardless of KEEP_NULLS.

Summary

Scenario	DEFAULT Exists	KEEP_NULLS	Sequence Advances?	Latch Per Row?
BCP (default behaviour)	Yes	No	Yes - wasted	Yes - serialised
BCP with `-k`	Yes	Yes	No	No
BCP, no DEFAULT	No	N/A	No	No
Regular INSERT...SELECT	Yes	N/A	No (column supplied)	No

The fourth row is important: a standard INSERT ... SELECT that includes the OrderID column does not fire the DEFAULT. This behaviour is specific to the INSERT BULK protocol.

Proving It: NUMERIC vs BIGINT Latch Contention

Even when the DEFAULT must fire (for example, when the application genuinely relies on it), the sequence data type determines the severity of the contention.

We tested three configurations at 32 concurrent sessions, each inserting 20,000 rows via INSERT ... DEFAULT VALUES:

Metric	NUMERIC(28,0)	BIGINT→NUMERIC	BIGINT
Latch wait requests	137,321	7	23
Latch total wait (ms)	37,661	210	384
Latch max single wait (ms)	53	54	18

(32 sessions × 20,000 rows, SQL Server 2025, localhost)

The "BIGINT→NUMERIC" column uses a BIGINT sequence feeding a NUMERIC(28,0) column. This proves that the latch mode follows the SEQUENCE type, not the column type. Changing the sequence from NUMERIC(28,0) to BIGINT is a metadata-only operation (DROP SEQUENCE + CREATE SEQUENCE AS BIGINT) that delivers a 99.4% reduction in latch waits without requiring any table rebuild.

IDENTITY Columns Have the Same Issue

The NUMERIC-vs-BIGINT latch behaviour is not limited to SEQUENCE objects - it applies equally to IDENTITY columns. An IDENTITY column defined as NUMERIC(28,0) or DECIMAL(28,0) takes an exclusive latch on the identity counter for every inserted row, while BIGINT IDENTITY uses a shared latch with atomic increments. The identity counter latch class (IDENTITYVALUE_GENERATOR) follows the same exclusive-vs-shared pattern as METADATA_SEQUENCE_GENERATOR.

For tables that use NUMERIC IDENTITY under high-concurrency insert workloads, changing the column type to BIGINT eliminates the serialisation. Unlike sequences, changing an identity column's data type requires ALTER TABLE ... ALTER COLUMN, which triggers a table rebuild for large tables. Plan this as a maintenance window operation for billion-row tables.

The Fixes

Four independent fixes address different layers of the problem. Any one of them helps; the combination eliminates the issue entirely.

Fix 1: Enable KEEP_NULLS in the Bulk Copy Client

This is the single highest-impact fix. When the application supplies all column values, enabling KEEP_NULLS prevents the engine from evaluating any DEFAULT constraint during INSERT BULK.

Spark JDBC:

.option("bulkCopyForBatchInsertKeepNulls", "true")

JDBC directly:

SQLServerBulkCopyOptions opts = new SQLServerBulkCopyOptions(); opts.setKeepNulls(true);

BCP:

bcp ... -k

BULK INSERT:

BULK INSERT dbo.Orders FROM 'data.dat' WITH (KEEPNULLS);

Impact: Eliminates 100% of unnecessary sequence latch acquisitions during bulk insert. If the application already supplies the ID column, this fix has zero behavioural side effects.

Warning: KEEP_NULLS applies to all columns, not just the sequence column. When enabled, any column where the source data contains NULL will store NULL rather than the column's DEFAULT value. If your table has other DEFAULT constraints that the application relies on - for example, CreatedDate DATE DEFAULT GETDATE() or Status VARCHAR(20) DEFAULT 'Pending' - those defaults will not fire for NULL values when KEEP_NULLS is active. Before enabling this option, verify that the application supplies values for every column, or that NULL is acceptable for columns the application omits. If some columns genuinely need their defaults, Fix 2 (dropping only the sequence DEFAULT) is the safer server-side alternative.

Fix 2: Drop the DEFAULT Constraint

If every insert path supplies the ID column, the DEFAULT constraint serves no purpose. Dropping it is an instant metadata-only DDL operation:

ALTER TABLE dbo.Orders DROP CONSTRAINT DF_Orders_ID;

Impact: Same as Fix 1, but enforced server-side. No client configuration required. Consider this if multiple applications insert into the table and you cannot guarantee all of them will set KEEP_NULLS.

Fix 3: Change NUMERIC Sequences to BIGINT

For scenarios where the DEFAULT must fire - for example, ad-hoc inserts, SSMS, or stored procedures that omit the ID column - changing the sequence type from NUMERIC(28,0) to BIGINT switches from exclusive to shared latching:

-- Wrap in a transaction so the workload never sees a moment without the DEFAULT. -- Without the transaction, inserts that rely on the DEFAULT would fail between -- the DROP CONSTRAINT and the ADD CONSTRAINT. BEGIN TRANSACTION; -- Step 1: Record current value DECLARE @current BIGINT; SELECT @current = CAST(current_value AS BIGINT) FROM sys.sequences WHERE name = 'Seq_Orders'; -- Step 2: Drop DEFAULT, drop sequence, recreate as BIGINT, re-add DEFAULT ALTER TABLE dbo.Orders DROP CONSTRAINT DF_Orders_ID; DROP SEQUENCE dbo.Seq_Orders; CREATE SEQUENCE dbo.Seq_Orders AS BIGINT START WITH @current INCREMENT BY 1 CACHE 50000000; ALTER TABLE dbo.Orders ADD CONSTRAINT DF_Orders_ID DEFAULT (NEXT VALUE FOR dbo.Seq_Orders) FOR OrderID; COMMIT TRANSACTION;

Wrapping the four statements in a single transaction ensures that concurrent inserts never see a state where the DEFAULT constraint is missing. Without the transaction, any insert that relies on the DEFAULT would fail with an error between the DROP CONSTRAINT and the ADD CONSTRAINT. All four operations are metadata-only and the transaction completes in under a second. The column type (NUMERIC(28,0)) does not need to change - SQL Server implicitly converts BIGINT to NUMERIC on insert.

Impact: 99.4% reduction in latch wait time when the DEFAULT does fire. BIGINT covers values up to 9.2 × 10^18, which is sufficient for virtually all surrogate key scenarios.

Fix 4: Right-Size Sequence Cache

The sequence CACHE setting controls how many values are pre-allocated in memory before the next disk write to the system catalog. The default cache is 50, which is far too small for high-volume bulk inserts:

ALTER SEQUENCE dbo.Seq_Orders CACHE 50000000;

Impact: Reduces disk I/O during sequence value generation. This does not change the latch mode - it only reduces how often the latch must also perform a catalog write. Fix 3 addresses the latch mode; this fix addresses the I/O.

When Each Fix Applies

Scenario	Fix 1 (KEEP_NULLS)	Fix 2 (Drop DEFAULT)	Fix 3 (BIGINT)	Fix 4 (Cache)
App supplies IDs via bulk insert	Primary fix	Backup/server-side	Reduces residual contention	Helpful
App relies on DEFAULT for IDs	N/A	N/A	Primary fix	Required
Mixed: some paths supply, some don't	For bulk paths	N/A	For DEFAULT paths	Required
SEQUENCE used in sp_sequence_get_range only	Not needed	Drop it	Helpful	Helpful

How to Detect This Pattern

Wait Stats

Query sys.dm_os_wait_stats or sys.dm_os_latch_stats for the signature:

-- Check for sequence latch contention SELECT latch_class, waiting_requests_count, wait_time_ms, max_wait_time_ms FROM sys.dm_os_latch_stats WHERE latch_class = 'METADATA_SEQUENCE_GENERATOR' AND waiting_requests_count > 0;

If METADATA_SEQUENCE_GENERATOR appears with high waiting_requests_count alongside LATCH_EX dominating sys.dm_os_wait_stats, this pattern is likely active.

Sequence Consumption Rate

Compare the sequence advance rate against actual row insertions:

-- If sequence advances much faster than rows are inserted, -- DEFAULT is firing unnecessarily during bulk inserts SELECT s.name AS sequence_name, CAST(s.current_value AS BIGINT) AS current_value, s.data_type, s.cache_size FROM sys.sequences s WHERE s.data_type IN ('numeric', 'decimal');

Sequences typed as NUMERIC or DECIMAL under high-concurrency workloads are the risk profile.

Execution Plans

Look for a Sequence Project iterator in the execution plan of INSERT BULK operations. If the application supplies the ID column, a Sequence Project indicates the DEFAULT is being evaluated unnecessarily.

Test Scripts

The scripts used for all benchmarks in this post are included below. Each can be run on any SQL Server 2019+ instance.

Setup: Database, Sequences, and Tables

USE master; GO IF DB_ID('LatchKeepNullsDemo') IS NOT NULL BEGIN ALTER DATABASE LatchKeepNullsDemo SET SINGLE_USER WITH ROLLBACK IMMEDIATE; DROP DATABASE LatchKeepNullsDemo; END GO CREATE DATABASE LatchKeepNullsDemo; GO USE LatchKeepNullsDemo; GO -- Table WITH NEXT VALUE FOR DEFAULT (demonstrates the problem) CREATE SEQUENCE dbo.Seq_Orders_Numeric AS NUMERIC(28, 0) START WITH 1 INCREMENT BY 1 CACHE 50000000; GO CREATE TABLE dbo.Orders_WithDefault ( OrderID NUMERIC(28, 0) NOT NULL CONSTRAINT DF_Orders_ID DEFAULT (NEXT VALUE FOR dbo.Seq_Orders_Numeric), CustomerID INT NOT NULL, OrderDate DATE NOT NULL, Amount DECIMAL(10, 2) NOT NULL, Filler CHAR(80) NOT NULL DEFAULT ('x'), CONSTRAINT PK_Orders_WithDefault PRIMARY KEY CLUSTERED (OrderID) ); GO -- Table WITHOUT DEFAULT (control) CREATE TABLE dbo.Orders_NoDefault ( OrderID NUMERIC(28, 0) NOT NULL, CustomerID INT NOT NULL, OrderDate DATE NOT NULL, Amount DECIMAL(10, 2) NOT NULL, Filler CHAR(80) NOT NULL DEFAULT ('x'), CONSTRAINT PK_Orders_NoDefault PRIMARY KEY CLUSTERED (OrderID) ); GO -- NUMERIC(28,0) sequence for latch test CREATE SEQUENCE dbo.Seq_Latch_Numeric AS NUMERIC(28, 0) START WITH 1 INCREMENT BY 1 CACHE 50000000; GO CREATE TABLE dbo.Inserts_Numeric ( ID NUMERIC(28, 0) NOT NULL DEFAULT (NEXT VALUE FOR dbo.Seq_Latch_Numeric), Filler CHAR(100) NOT NULL DEFAULT ('x'), CONSTRAINT PK_Inserts_Numeric PRIMARY KEY CLUSTERED (ID) ); GO -- BIGINT sequence for latch test CREATE SEQUENCE dbo.Seq_Latch_BigInt AS BIGINT START WITH 1 INCREMENT BY 1 CACHE 50000000; GO CREATE TABLE dbo.Inserts_BigInt ( ID BIGINT NOT NULL DEFAULT (NEXT VALUE FOR dbo.Seq_Latch_BigInt), Filler CHAR(100) NOT NULL DEFAULT ('x'), CONSTRAINT PK_Inserts_BigInt PRIMARY KEY CLUSTERED (ID) ); GO -- BIGINT sequence + NUMERIC column (proves latch follows sequence type) CREATE SEQUENCE dbo.Seq_Latch_Mixed AS BIGINT START WITH 1 INCREMENT BY 1 CACHE 50000000; GO CREATE TABLE dbo.Inserts_Mixed ( ID NUMERIC(28, 0) NOT NULL DEFAULT (NEXT VALUE FOR dbo.Seq_Latch_Mixed), Filler CHAR(100) NOT NULL DEFAULT ('x'), CONSTRAINT PK_Inserts_Mixed PRIMARY KEY CLUSTERED (ID) ); GO

-- Helper: Generate BCP test data with app-supplied IDs CREATE OR ALTER PROCEDURE dbo.GenerateBCPData @RowCount INT = 10000 AS BEGIN SET NOCOUNT ON; ;WITH Nums AS ( SELECT TOP(@RowCount) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS n FROM sys.all_objects a CROSS JOIN sys.all_objects b ) SELECT CAST(n AS NUMERIC(28,0)) AS OrderID, ABS(CHECKSUM(NEWID())) % 10000 + 1 AS CustomerID, CAST(DATEADD(DAY, -(n % 365), '2026-03-31') AS DATE) AS OrderDate, CAST(ABS(CHECKSUM(NEWID())) % 100000 / 100.0 AS DECIMAL(10,2)) AS Amount, REPLICATE('x', 80) AS Filler FROM Nums; END GO

Test: BCP KEEP_NULLS Comparison

# Step 1: Export test data bcp "EXEC LatchKeepNullsDemo.dbo.GenerateBCPData @RowCount=10000" \ queryout orders.dat -c -t"," -S localhost\sql25 -T # Step 2: Record sequence starting value sqlcmd -S localhost\sql25 -d LatchKeepNullsDemo -Q \ "SELECT name, CAST(current_value AS VARCHAR(30)) AS val FROM sys.sequences WHERE name = 'Seq_Orders_Numeric';" # Step 3a: BCP WITHOUT KEEP_NULLS (DEFAULT fires per-row) bcp LatchKeepNullsDemo.dbo.Orders_WithDefault in orders.dat \ -c -t"," -S localhost\sql25 -T # Check: sequence should have advanced (values wasted) sqlcmd -S localhost\sql25 -d LatchKeepNullsDemo -Q \ "SELECT name, CAST(current_value AS VARCHAR(30)) AS val FROM sys.sequences WHERE name = 'Seq_Orders_Numeric';" # Step 3b: Reset, then BCP WITH KEEP_NULLS (DEFAULT suppressed) sqlcmd -S localhost\sql25 -d LatchKeepNullsDemo -Q \ "TRUNCATE TABLE dbo.Orders_WithDefault; ALTER SEQUENCE dbo.Seq_Orders_Numeric RESTART WITH 1;" bcp LatchKeepNullsDemo.dbo.Orders_WithDefault in orders.dat \ -c -t"," -S localhost\sql25 -T -k # Check: sequence should NOT have advanced sqlcmd -S localhost\sql25 -d LatchKeepNullsDemo -Q \ "SELECT name, CAST(current_value AS VARCHAR(30)) AS val FROM sys.sequences WHERE name = 'Seq_Orders_Numeric';"

Test: Concurrent Latch Comparison (PowerShell)

# Compare NUMERIC vs BIGINT sequence latch contention # under N concurrent sessions, each inserting via INSERT...DEFAULT VALUES param( [int]$Sessions = 16, [int]$RowsPerSession = 10000, [string]$Server = "localhost\sql25" ) $db = "LatchKeepNullsDemo" function Invoke-ConcurrentInserts { param([string]$TableName, [string]$Label) sqlcmd -S $Server -E -d $db -Q "TRUNCATE TABLE dbo.$TableName;" -b 2>&1 | Out-Null sqlcmd -S $Server -E -d $db ` -Q "DBCC SQLPERF('sys.dm_os_latch_stats', CLEAR) WITH NO_INFOMSGS;" ` -b 2>&1 | Out-Null $sql = "SET NOCOUNT ON; DECLARE @i INT = 0; " + "WHILE @i < $RowsPerSession BEGIN " + "INSERT INTO dbo.$TableName DEFAULT VALUES; SET @i += 1; END" $sw = [System.Diagnostics.Stopwatch]::StartNew() $jobs = @() for ($s = 0; $s -lt $Sessions; $s++) { $jobs += Start-Job -ScriptBlock { param($srv, $database, $query) sqlcmd -S $srv -E -d $database -Q $query -b 2>&1 | Out-Null } -ArgumentList $Server, $db, $sql } $jobs | Wait-Job | Out-Null $sw.Stop() $jobs | Remove-Job -Force # Capture latch stats $raw = sqlcmd -S $Server -E -d $db ` -Q "SELECT latch_class, waiting_requests_count, wait_time_ms, max_wait_time_ms FROM sys.dm_os_latch_stats WHERE latch_class = 'METADATA_SEQUENCE_GENERATOR';" ` -W -s "," -h -1 2>&1 $line = $raw | Where-Object { $_ -match 'METADATA' } | Select-Object -First 1 $requests = 0; $waitMs = 0; $maxMs = 0 if ($line -match 'METADATA_SEQUENCE_GENERATOR\s*,\s*(\d+)\s*,\s*(\d+)\s*,\s*(\d+)') { $requests = [long]$Matches[1]; $waitMs = [long]$Matches[2]; $maxMs = [long]$Matches[3] } Write-Host (" {0,-20} Elapsed: {1,6} ms | Latch waits: {2,8} | Wait: {3,6} ms" ` -f $Label, $sw.ElapsedMilliseconds, $requests, $waitMs) return @{ Label = $Label; Elapsed = $sw.ElapsedMilliseconds; Requests = $requests; WaitMs = $waitMs; MaxMs = $maxMs } } Write-Host "Sessions: $Sessions | Rows/session: $RowsPerSession" $rNum = Invoke-ConcurrentInserts -TableName "Inserts_Numeric" -Label "NUMERIC(28,0)" $rMix = Invoke-ConcurrentInserts -TableName "Inserts_Mixed" -Label "BIGINT->NUMERIC" $rBig = Invoke-ConcurrentInserts -TableName "Inserts_BigInt" -Label "BIGINT" if ($rNum.WaitMs -gt 0) { $mixPct = [math]::Round((1 - $rMix.WaitMs / $rNum.WaitMs) * 100, 1) $bigPct = [math]::Round((1 - $rBig.WaitMs / $rNum.WaitMs) * 100, 1) Write-Host "`nBIGINT->NUMERIC latch reduction: $mixPct%" Write-Host "BIGINT latch reduction: $bigPct%" }

Key Takeaways

INSERT BULK without KEEP_NULLS evaluates DEFAULT expressions per-row - even when the source data supplies non-NULL values. For NEXT VALUE FOR defaults, this means one latch acquisition per row, per session, regardless of whether the value is used. This is documented behaviour, but the performance implications for sequence-based defaults under concurrency are rarely discussed.
NUMERIC / DECIMAL sequences use exclusive latches; BIGINT / INT use shared latches with atomic increments. The sequence cache setting reduces disk I/O only - it does not change the latch mode. The latch mode is determined by the sequence type, not the column type.
The combination creates a force multiplier. Each factor is tolerable in isolation. Exclusive latching with a few sessions is fine. Unnecessary DEFAULT evaluation at low concurrency has negligible cost. But 350 sessions × exclusive latch × per-row evaluation = complete serialisation.
The diagnostic signature is clear. LATCH_EX dominant in wait stats + METADATA_SEQUENCE_GENERATOR in sys.dm_os_latch_stats + low CPU utilisation = this pattern. Low CPU under high concurrency means serialisation, not low demand.
The fix is simple. Setting KeepNulls = true in the bulk copy options eliminates the issue entirely when the application supplies all values. No schema changes required, no table rebuilds, no downtime.

Documentation References

BULK INSERT (Transact-SQL) - KEEPNULLS - Documents the KEEPNULLS behaviour: "Specifies that empty columns should retain a null value during the bulk import operation, instead of having any default values for the columns inserted."
bcp Utility -k flag - BCP command-line equivalent of KEEPNULLS.
SQLServerBulkCopyOptions.setKeepNulls - JDBC bulk copy configuration for the keepNulls option.
Sequence Numbers (SQL Server) - Overview of SEQUENCE objects, caching behaviour, and usage patterns.
sp_sequence_get_range - Pre-allocating contiguous ID ranges with a single latch acquisition.
CREATE SEQUENCE (Transact-SQL) - Sequence data type options and cache configuration.
sys.dm_os_latch_stats - DMV for diagnosing latch contention by class.
IDENTITY (Property) - IDENTITY column behaviour and data type considerations.

Feedback and Suggestions

If you have feedback or suggestions, please contact the Databases SQL Customer Success Engineering (Ninja) Team (datasqlninja@microsoft.com).

Note: For additional information about migrating various source databases to Azure, see the Azure Database Migration Guide.

PostgreSQL Meets AI at POSETTE: An Event for Postgres 2026 (T-3 weeks)

scoriani — Fri, 29 May 2026 17:24:40 GMT

POSETTE: An Event for Postgres 2026 is where that evolution comes into focus, please visit conference’s site to register and add the event to your calendar!

Artificial intelligence is changing how we build applications, but not in the way many people expected. The hardest problems aren’t about writing the perfect prompt or choosing the “best” model. Once teams move past demos and start putting systems in front of real users, the pain shows up somewhere else: in the data layer.

The recurring failure modes of production AI are remarkably consistent. Systems return answers that sound plausible but aren’t grounded. They pull the wrong records, miss key context, or stitch together fragments from unrelated sources. Sometimes they are correct, but wildly expensive. And when you let an AI system generate queries dynamically, the operational questions get sharper very quickly: what stops it from issuing a destructive statement, scanning a massive table, or repeatedly hammering a hot index until your p95 latency falls off a cliff?

In other words, the hard part is not generation. The hard part is retrieval, how data is accessed, shaped, governed, and observed. That’s exactly why the AI track at POSETTE: An Event for Postgres 2026 is so compelling this year: it treats PostgreSQL not as a passive database at the end of a request, but as an active foundation for the next wave of AI, native applications.

What’s emerging across the agenda is a new mental model. PostgreSQL, long trusted as a durable, transactional system, has become the place where “truth” lives for many applications. And as AI agents become the interface to those applications, Postgres increasingly becomes the retrieval backbone that keeps those agents honest.

From queries to agents: when the database becomes a tool

In traditional application design, we assume a deterministic relationship between intent and query. The application decides what it needs, SQL expresses it precisely, and the database returns a predictable result set. We tune the query, we add an index, we cache the hot path, and we move on.

Agentic systems break that contract.

An agent doesn’t just execute a query. It interprets intent, decides what tools to use, and often iterates, sometimes several times, based on intermediate results. That “tool use” framing is central to Pamela Fox’s session An MCP for your Postgres DB, which explores how MCP (Model Context Protocol) turns a database into an explicit, discoverable interface, one where design choices directly influence whether an LLM behaves safely and predictably when it interacts with Postgres.

In parallel, Abe Omorogbe’s From Queries to Agents: The Next Era of Data Retrieval on PostgreSQL frames the evolution in a way that resonates with anyone building production systems: as agents move from demos to reality, the challenge isn’t the model, it’s “reliable, safe, and context, aware data retrieval.” In practice, that means dealing with failures that don’t show up in toy examples: agents producing SQL that’s syntactically valid but semantically wrong; pulling the right table but the wrong slice; or forming queries that quietly explode costs because there’s no natural “stop” condition.

Once you accept that agents are going to query your system in ways you didn’t anticipate, PostgreSQL becomes part of your application’s safety boundary. It must handle unpredictable access patterns without falling over. It must protect you from unsafe operations, whether accidental or adversarial. And increasingly, it must support multi, modal retrieval, because the context an agent needs rarely lives in a single shape of data.

That’s the pivot POSETTE: An Event For Postgres 2026 is capturing: the database is no longer just queried, it is increasingly negotiated with by AI systems.

RAG in practice: why PostgreSQL keeps showing up

Retrieval, Augmented Generation (RAG) has become the default architecture for serious AI applications. It’s a pragmatic response to a simple reality: models are good at language, but they aren’t systems of record. If you care about accuracy, freshness, or traceability, you retrieve relevant information first, then generate a response grounded in that retrieved context.

The interesting question isn’t “does RAG work?”, it does. The interesting question is where teams choose to implement it.

A growing number of teams are using PostgreSQL as the core retrieval substrate for RAG pipelines because it lets them keep the system cohesive. You can store structured records, join across metadata, filter and rank, and now, thanks to the ecosystem, incorporate vector similarity search without standing up a separate database whose contents need to be continuously synchronized.

That’s the practical framing behind Julia Schröder Langhaeuser and Paula Santamaría’s session Production RAG at Scale with Azure Database for PostgreSQL. Their talk centers on what it takes to go from prototype to production, including architecture choices, performance tuning, and the operational discipline required when you’re serving RAG workloads at meaningful scale. The message is less “Postgres can do vectors” and more “RAG becomes real when you can observe it, tune it, and trust it.”

This distinction matters, because the failure modes of RAG systems are rarely about embeddings. They are about context assembly. The best answer in the world is useless if the system retrieved the wrong snippets, missed an important constraint, or pulled stale policy text from last quarter.

PostgreSQL’s value here is subtle but powerful: it gives you a place to combine retrieval signals, structured filters, semantic similarity, graph, like relationships, business rules, inside a system whose behavior you can reason about.

The real problem is retrieval, not generation

If you spend time around production AI teams, you start to hear the same phrase: retrieval is the hard part.

Models can generate fluent text easily. But without high, quality input, and without guardrails around what the system is allowed to do, they generate confident nonsense, partial answers, and occasionally harmful advice. In the worst cases, they can become operational liabilities: issuing expensive queries repeatedly, pulling sensitive data into prompts, or creating “self, inflicted incidents” that look like outages but are really uncontrolled tool usage.

That’s why POSETTE’s AI programming doesn’t just celebrate capability. It spends real time on safety and operational control.

Building safety tooling for risk, free AI tuning of Postgres: Fast cars need fast brakes by Mohsin Ejaz captures this mindset perfectly. The title says what many teams learn too late: if you’re going to let an automated system tune or optimize database behavior, the safety net matters more than the accelerator. Guardrails, validation, monitoring, and rollback discipline aren’t “nice to have”, they’re the difference between a neat demo and a system you can run while you sleep.

When you connect that back to the agent conversation, you get a coherent picture. Whether the system is generating queries, selecting tools, or attempting optimizations, the foundation of reliability is the same: controlled access, predictable performance, and strong observability.

PostgreSQL contributes here not because it’s magical, but because it’s mature. It has deep access control primitives, transactional guarantees, and an ecosystem that has spent decades building operational muscle. The AI shift doesn’t eliminate those fundamentals, it makes them more important.

The emerging retrieval stack: what sits between agents and data

One of the most useful ways to interpret this year’s sessions is as the early shape of a new architectural layer: a retrieval stack that lives between AI agents and your data systems.

This stack is not a single product. It’s a set of practices and components that make agent, to, data interactions safe and effective. It includes abstraction layers (like MCP, style tool interfaces), orchestration logic that can combine relational queries with vector similarity (and, increasingly, graph, aware traversal), context shaping that ranks and filters results into something a model can actually use, and governance controls that define what data may be accessed in which situations.

What’s exciting about POSETTE: An Event For Postgres 2026 is that the agenda treats this as a real engineering problem, not a buzzword. Pamela Fox’s work on MCP surfaces the interface, design angle: when you expose Postgres as tools, the shape of those tools determines whether the agent behaves well. Abe Omorogbe’s framing pushes toward retrieval architectures that are robust by design rather than bespoke glue code. Julia Schröder Langhaeuser and Paula Santamaría bring the production perspective: what breaks at scale, and what you need to monitor. And Mohsin Ejaz anchors the safety story: the more automation you introduce, the more you need reliable brakes.

That same story now extends all the way to the developer experience. In Matt McFarland’s session PostgreSQL Tooling Across AI Editors and Agents, the focus shifts from retrieval architecture inside applications to the environments where developers and AI assistants actually work. By showing how PostgreSQL capabilities such as connection management, query execution, schema analysis, plan inspection, and performance insights can be surfaced consistently across VS Code, Cursor, and the GitHub Copilot CLI through an MCP server, the session adds an important dimension to the overall AI track: if agents are going to become part of everyday software development, PostgreSQL tooling also needs to become agent-aware, portable, and usable wherever those workflows happen. It’s a practical reminder that the AI future of Postgres is not only about what runs in production, but also about how humans and AI systems collaborate around the database during development itself.

Together, these sessions sketch a coherent future: PostgreSQL isn’t just where data sits. It’s becoming one of the engines that powers retrieval, first application design.

Why this matters if you build real systems

If you’re building applications today, this shift is not theoretical. It changes how you think about database design, performance tuning, security, and cost.

You can’t assume query predictability anymore, because agents don’t behave like carefully written application code. You can’t treat access control as a static checklist, because prompts are leaky abstractions and tool use creates new attack surfaces. And you can’t ignore cost modeling, because AI, generated queries can be expensive in ways that traditional workloads rarely are, especially when they iterate.

POSETTE: An Event For Postgres 2026 tackles these realities head, on. Not with hype, but with practical patterns, real failure modes, and the kind of engineering trade, offs you only learn when systems meet production constraints.

What you’ll take away from the AI track at POSETTE: An Event for Postgres this year

If there’s a single theme to keep in mind, it’s this: AI isn’t replacing databases. It’s forcing us to use them differently.

The AI sessions at POSETTE: An Event For Postgres 2026 will help you build a clearer mental model of how agents interact with PostgreSQL, how RAG systems become production, ready, and what it means to design retrieval layers with safety and observability from day one. And, importantly, you’ll leave with a vocabulary for discussing these systems without hand, waving: where the risk is, where the cost is, and where the true engineering work lives.

PostgreSQL’s flexibility and extensibility make it a natural foundation for this transition, but the real advantage will go to teams that treat retrieval as an engineering discipline, not an afterthought.

At POSETTE, that transformation is on full display.

A quick call to action

POSETTE: An Event for Postgres 2026 is a can’t, miss event for the PostgreSQL community. Register to get updates and save the livestream sessions you want to attend on your calendar.

Why do I see many VDI_CLIENT_WORKER sessions in Azure SQL Database — and do they impact performance?

Ashriti_Jamwal — Fri, 29 May 2026 06:52:21 GMT

Sometimes you’ll notice many sessions showing the command VDI_CLIENT_WORKER in Azure SQL Database—often around scaling, replica/copy workflows, or internal seeding operations. These sessions can look alarming, especially during a performance investigation, but they are typically internal background workers. This post explains how to recognize them, what’s safe to do (and what isn’t), and how to focus on the real bottlenecks like blocking/deadlocks or log rate throttling when you’re troubleshooting slowness.

Why you might see VDI_CLIENT_WORKER sessions in Azure SQL Database

The symptom

You run a session query (for example, using sys.dm_exec_requests or a monitoring tool) and observe:

Many sessions with command text VDI_CLIENT_WORKER
They may appear to be “stuck,” persist longer than expected, and can’t be killed
Teams may worry these sessions are “the cause” of slowness

Why it shows up in Azure SQL

In Azure SQL, VDI_CLIENT_* wait types and VDI_CLIENT_WORKER sessions are commonly associated with platform operations that involve copying/seeding—for example:

Scaling operations (service objective changes)
Geo-replication / copy workflows
Replica seeding-like behaviors

Important: The presence of these sessions does not automatically mean they are the bottleneck.

How to validate whether VDI_CLIENT_WORKER is benign?

1) Correlate to recent platform operations.

Ask: did you recently perform (or did the platform perform) one of these?

Scale up/down.
Creation of replicas / geo-secondary operations.
Any database copy-like workflow.

If yes, it’s a strong indicator you’re seeing background workers tied to that lifecycle event.

2) Check whether they consume resources.

A practical approach:

Look for CPU/IO/log pressure at the database level.
Compare the timing of slowness reports with spikes in waits/locks/log write percentage.

If these sessions show minimal resource consumption and are just “present,” treat them as background noise while you investigate real contention.

3) Don’t try to kill them!

These sessions are typically system/internal. Attempts to kill them may fail or be ineffective—and generally aren’t recommended.

4) If you need them to disappear.

In many cases, these internal workers naturally age out. If they remain visible and you need a cleanup path, operational actions like failover/restart may clear stale workers (use change control / maintenance windows as appropriate for your environment).
(This is a practical operational observation; always weigh downtime/impact.)

When performance is actually slow: focus on what usually hurts.

In many real-world incidents, the main causes of slowness are:

Blocking chains / deadlocks.
Transaction log rate throttling (LOG_RATE_GOVERNOR) during heavy DML.
Hot queries running concurrently and contending on the same objects.

Key takeaways

Seeing many VDI_CLIENT_WORKER sessions is often expected around platform copy/seeding workflows and doesn’t automatically indicate a bottleneck.
Don’t attempt to kill system/internal workers; instead, validate resource impact and focus on actual bottlenecks.
For real slowness, prioritize diagnosing blocking/deadlocks and LOG_RATE_GOVERNOR-driven DML throttling.

General Availability of the MySQL Flexible Server Quota Management Self-Service Experience

karlaescobar — Thu, 28 May 2026 05:58:27 GMT

What’s New?

The updated experience introduces a dedicated Azure Database for MySQL Flexible Server Quotas blade in the Azure portal, offering a streamlined and intuitive interface to:

View current usage and limits across the various SKU families and regions
Request quota increases tailored to your MySQL Flexible Server deployment needs

This new experience empowers developers, DBAs, and IT admins to proactively manage resources, avoid deployment failures, and optimize database performance — all without needing to file a support ticket for most scenarios.

Benefits at a Glance

Benefit	Description
Self-Service	Request quota increases directly from the Azure portal without filing a support ticket for most scenarios.
Real-Time Visibility	View current vCore usage and limits across all SKU families and regions at a glance.
Automatic Approval	Many quota increase requests are automatically approved within minutes — no waiting for manual review.
Inline Adjustments	Request increases directly from the quota table — no need to navigate to a separate page or form.
Proactive Management	Identify SKU families nearing their limits before they cause deployment failures.
Fraud and UPA as Safeguard	Requests that exceed limits or indicate risk are automatically escalated for review, not blindly approved.

How It Works

Each MySQL Flexible Server compute tier is represented as a separate SKU family. If you intend to scale up or down within a specific tier, ensure you have sufficient quota for each applicable SKU family in that tier.
You can filter by region, subscription, provider, or usage. Note that your portal will show "Azure Database for MySQL Flexible Server" for the Provider name.
You can also group the results by usage, quota (SKU family), or location (region).
Current usage is represented as vCores. This allows you to quickly identify which SKU families are nearing their quota limits.
Adjustments can be made inline: there is no need to visit another page. This is covered in detail in the next section.

Step-by-Step: Viewing Usage and Requesting a Quota Increase

Step 1: Navigate to the Quotas Blade

Sign in to the Azure portal at https://portal.azure.com.
In the search bar at the top, type "Quotas".
Select "Quotas" from the search results under Services.

Alternative navigation: You can also navigate via Subscriptions > select your subscription > Usage + quotas in the left-hand menu.

Step 2: Select the Azure Database for MySQL Provider

On the Quotas page, locate and select "Azure Database for MySQL" from the list of resource providers.

Use the Subscription filter at the top to select the subscription you want to review and apply additional filters for regions as needed.

Step 3: Review Your Quota Usage and Limits

The quota details page displays a table with the following information:
- Quota Name — The SKU family name (e.g., "Burstable BS Series vCores", "General Purpose DS Series vCores", "Business Critical DS Series vCores").
- Region — The Azure region where the quota applies.
- Current Usage — The number of vCores currently in use.
- Limit — The maximum quota limit for that SKU family.
- Usage Bar — A visual indicator showing how much of the quota is consumed.
Review the usage bars to identify quotas that are nearing their limits. Use the search box to find specific SKU families quickly.

Step 4: Request a Quota Increase

Clicking the pen icon next to a quota opens a fly-out window to capture the quota request.

Step 5: Enter the New Limit

The quota type (MySQL Flexible Server SKU family) is already populated, along with current usage. Note that your request is not incremental: you must specify the new limit that you wish to see reflected in the portal.
For example, to request an additional 10 vCores for Burstable Series (BS family), and your current limit is 35, you would enter 45 as the new limit.
- Enter the desired new limit in the "New limit" field.
- The portal will indicate whether the request can be automatically approved or if it requires manual review.

Step 6: Submit and Monitor the Request

Click Submit to send the request for automatic processing.
Immediately upon submitting a quota request, you will see a processing dialog:

If the quota request can be automatically fulfilled, then no support request is needed. You should receive confirmation within a few minutes of submission:

If the request cannot be automatically fulfilled, then you will be given the option to file a support request with the same information:

Step 7: Verify the Quota Increase

Navigate back to the Quotas blade and select the Azure Database for MySQL provider.
Confirm that the Limit column now reflects the new, increased value.
If you forget the region or SKU family that was requested, you can reference them in your notifications pane.

Filing a Support Ticket

When creating a support ticket, you will need to repopulate the Region and MySQL Flexible Server SKU family details; the new limit has already been populated for you.
If you choose to create a support ticket, you will interact with the capacity management team for that region. This is a 24x7 service, so requests may be created at any time. Once you have filed the support request, you can track its status via the Help + support dashboard.
If your deployment requires quota for many subscriptions, then we recommend filing a support ticket with issue type "Service and subscription limits (quotas)" and quota type “Quota increase”:

Known Limitations

Closing the quota request fly-out window will stop meaningful notifications for that request. You can still view the outcome of your quota requests by checking actual quota, but if you want to rely on notifications for alerts, we recommend leaving the quota request window open for the few minutes that it is processing.

Feedback

If you notice any aspect of the experience that does not work as expected or you have feedback on how to make it better, please share your thoughts! Your feedback is critical as we work toward an improved quota management self-service experience.

Introducing PostgreSQL Hub for Azure Developers

ShreyaAithal — Wed, 27 May 2026 16:33:28 GMT

When you're building applications with PostgreSQL, finding the right resources can be harder than it should be. Documentation lives in one place, samples in another, tutorials scattered across blogs, and community discussions fragmented across forums. You end up with multiple browser tabs open just to piece together a working architecture for your project. Whether you're just getting started or you've been building for years, if all you want is a faster path from "I have an idea" to "this is running in production", then PostgreSQL Hub for Azure Developers is for you.

It brings everything together in one place. But it's more than just a content aggregator. Here's what makes it different:

Curated resources to help you build. From sample apps and solution accelerators to tutorials, videos, workshops, and relevant documentation, you'll find what you need to build core applications, AI-powered solutions, and multi-agent architectures on PostgreSQL. Resources are maintained and updated as new capabilities ship.
Structured learning pathways. Instead of navigating documentation on your own, you get guided paths that take you from fundamentals through intermediate patterns to advanced AI scenarios like vector search, AI functions, and building agents. The pathways are designed to help you develop a solid understanding at every stage.
Community space. Beyond content, the hub also includes a Developer Forum powered by GitHub Discussions where you can share product feedback, learn from fellow developers, and collaborate directly with Microsoft engineers on your use cases. Whether you want to discuss an architecture decision, share what you've built, or contribute a sample, the forum is the place for it. Real-time chat for quick questions and webinars is coming soon.

Who is this for?

No matter what stage you're at in building with PostgreSQL on Azure, there's something here for you. The hub is especially relevant if you are:

An application developer looking for curated resources, end-to-end guidance, and patterns to build or scale your projects on PostgreSQL
An AI builder exploring use cases like vector search, embeddings, AI functions, or agent architectures
A new learner looking for a clear starting point with structured content to guide you
An enterprise user with existing workloads on Azure looking to understand the full breadth of intelligent application development capabilities available with PostgreSQL

The sample apps, patterns, and learning content are valuable irrespective of whether you're already building on PostgreSQL or just exploring what's possible.

Get Started

The surface area of what you can build with PostgreSQL has expanded significantly, and finding the right resource at the right time shouldn't slow you down. That's exactly what this hub is here to solve.

Here's a quick walkthrough of the Postgres Hub:

Head over to aka.ms/postgres-hub to explore further! Browse the sample apps, pick a learning pathway that matches where you are, or join the community discussions to connect with other developers and Microsoft engineers.

We're actively growing this hub based on what the community needs. Your feedback, your questions, and your contributions will shape what comes next.

Demystifying LWLock: MultiXact SLRU Wait Events in Azure Database for PostgreSQL

Gayathri_Paderla — Wed, 27 May 2026 14:20:20 GMT

What Is the MultiXact Subsystem?

Before diving into the wait events, it helps to understand what PostgreSQL is protecting. When a single transaction modifies a row, PostgreSQL stores that transaction's ID (XID) directly in the row header's xmax field. Simple and fast. But what happens when two or more transactions need to hold locks on the same row simultaneously? For example:

Two sessions run SELECT ... FOR KEY SHARE on the same row, OR
A SELECT ... FOR UPDATE session encounters a row already locked by a foreign key check (FOR KEY SHARE), OR
Multiple sub-transactions created by SAVEPOINT all reference the same row

In these cases, PostgreSQL cannot store two XIDs in a single xmax field. Instead, it creates a MultiXact ID (MXID) — a composite identifier that points to a list of all involved transaction IDs. These mappings are stored in two on-disk structures:

pg_multixact/offsets/ — maps each MXID to its position in the member's file
pg_multixact/members/ — stores the actual list of member XIDs

To avoid reading these files from disk on every row visibility check, PostgreSQL caches them in memory using a SLRU (Simple Least Recently Used) cache — a small, fixed-size ring buffer with just 8 buffer slots by default (64 KB) for offsets and 16 slots (128 KB) for members.

Each of those buffer slots is protected by an LWLock (Lightweight Lock). And that LWLock is exactly where the bottleneck hides.

The Core Insight:
Cache Hits and Lock Contention are not mutually exclusive

This is the most important concept in this entire post:

pg_stat_slru measures I/O misses. pg_stat_activity wait events measure lock contention.

Here is what actually happens at the microsecond level:

Session A: Needs MXID 5,000,023 → Page is in SLRU cache (blks_hit++) → LWLock is needed on buffer slot 3 → Session B already holds that LWLock → Session A WAITS → wait_event = 'MultiXactOffsetSLRU' recorded

The cache is warm, the page is in memory, but what happens when 50 concurrent sessions suddenly all need that same buffer slot's LWLock? Only one request can hold the LWLock at a time. Every session that queues behind the lock holder generates a wait event record, all while no disk I/O is occurring.

What Triggers MultiXact SLRU Wait Events?

Below are the scenario's which could trigger MultiXact SLRU Wait Events.

Thundering Herd — Mass Concurrent Row Locking

When dozens or hundreds of sessions simultaneously attempt to lock the same small set of rows, PostgreSQL must create and resolve MXIDs at high frequency. Each resolution requires an SLRU lookup. When all lookups target the same few SLRU pages, the buffer lock becomes a serialization point. A classic reconnect avalanche triggered when the connection pool detected server slowness and all clients retried simultaneously.

Foreign Key FOR KEY SHARE vs. FOR UPDATE Conflicts

This is one of the most common hidden triggers. Every time a child row is inserted or updated, PostgreSQL implicitly acquires FOR KEY SHARE on the referenced parent row to prevent the parent from being deleted. If another session simultaneously holds FOR UPDATE on that same parent row, PostgreSQL must combine both lock modes into a new MXID:

-- Session A (updater): SELECT * FROM orders WHERE id = 1 FOR UPDATE; -- Session B (child inserter — FK check): INSERT INTO order_items (order_id, amount) VALUES (1, 99.00); -- Implicitly: SELECT * FROM orders WHERE id = 1 FOR KEY SHARE; -- PostgreSQL creates MXID combining both transactions → SLRU write

SAVEPOINT and Sub-transaction Churn

Every SAVEPOINT creates a sub-transaction XID. ORM frameworks and JDBC drivers with autosave=always silently wrap every statement in a SAVEPOINT, generating sub-XIDs that accumulate rapidly. When these sub-XIDs reference the same rows across concurrent sessions, MXID creation accelerates. Each exception handler internally creates a SAVEPOINT, even when no explicit savepoint is declared.

Idle Sessions Holding MXID References Open

Long-running idle-in-transaction sessions hold their MXID references open, preventing PostgreSQL's autovacuum from cleaning up old multixact entries. As the MXID space grows without cleanup, the SLRU cache (fixed at 8 pages) cannot hold all active pages simultaneously. New MXID lookups begin evicting cached pages, and under concurrency the eviction/reload cycle itself creates LWLock contention.

VACUUM FREEZE During High Concurrency

When autovacuum runs VACUUM FREEZE to prevent MXID wraparound, it reads and resolves every MXID on every row in the table. During this process it holds SLRU buffer locks for each lookup. Concurrent application sessions needing the same SLRU pages must wait; generating MultiXactOffsetSLRU wait events even when the underlying cause is a routine maintenance operation.

How to Diagnose This in Real Time

Step 1: Confirm Active Wait Events

Start by querying pg_stat_activity to confirm which sessions are actively waiting on MultiXact SLRU events. Use \watch 1 to refresh every second since SLRU LWLocks are held for microseconds and brief spikes can be missed. Pay close attention to the wait_event column, MultiXactOffsetSLRU and MultiXactMemberSLRU indicate pure lock contention on cached pages, while MultiXactOffsetBuffer indicates the page was evicted from cache and is being reloaded from disk.

SELECT pid, wait_event_type, wait_event, state , now() - query_start AS duration, left(query, 100) AS query FROM pg_stat_activity WHERE wait_event IN ( 'MultiXactOffsetSLRU', 'MultiXactMemberSLRU', 'MultiXactOffsetBuffer' ) ORDER BY duration DESC;

Step 2: Distinguish Lock Contention From Disk I/O

Once wait events are confirmed, determine whether the root cause is cache under sizing (disk I/O problem) or LWLock queue depth (lock contention problem). These look identical in pg_stat_activity but require completely different fixes. Query pg_stat_slru and focus on the blks_read and blks_zeroed columns. A blks_read = 0 alongside active wait events is the definitive signature of pure lock contention: the cache is warm but the LWLock protecting each buffer slot is the bottleneck.

SELECT name, blks_hit, blks_read, blks_zeroed, flushes , ROUND(100.0 * blks_hit / NULLIF(blks_hit + blks_read, 0), 2) AS hit_pct FROM pg_stat_slru WHERE name LIKE 'MultiXact%';

Interpretation	Meaning
blks_read = 0 AND wait events are present	Pure lock contention — the cache is warm, the lock is the bottleneck
blks_read > 0 AND wait events are present	Cache miss + lock contention — the SLRU cache is undersized
blks_zeroed are increasing rapidly	High MXID creation rate — inspect application pattern issues
flushes are high (2,000+)	Frequent checkpoint SLRU flushes holding an exclusive lock

Step 3: Check MXID Age and Identify Hot Tables

A high MXID age means autovacuum is not keeping pace with MXID creation. This causes the MXID space to span far more SLRU pages than the 8-slot cache can hold, directly worsening lock contention. Check MXID age at both the database and table level. Any database approaching 1.5 billion should be treated as a critical incident. At the table level, focus on tables with the highest mxid_age combined with high row counts and stale last_autovacuum timestamps — these are your primary VACUUM FREEZE targets.

-- Database-level MXID age (watch for values > 1 billion) SELECT datname, mxid_age(datminmxid) AS mxid_age FROM pg_database ORDER BY mxid_age DESC; -- Table-level — find the worst offenders SELECT relname, mxid_age(relminmxid) AS mxid_age , pg_size_pretty(pg_total_relation_size(oid)) AS table_size, n_live_tup FROM pg_stat_user_tables t JOIN pg_class c USING (relname) WHERE c.relkind = 'r' ORDER BY mxid_age DESC LIMIT 10;

Step 4: Find Queries Driving MXID Creation

Once the hot tables are identified, use pg_stat_statements to pinpoint the specific queries generating MXIDs at a high rate. Focus on queries using FOR UPDATE, FOR KEY SHARE, or FOR SHARE, as these are the direct triggers for concurrent row locking. Also watch for INSERT-heavy workloads on child tables with FK references, as these implicitly acquire FOR KEY SHARE on parent rows and are a common hidden driver of MXID creation.

SELECT left(query, 200) AS query, calls, mean_exec_time::numeric(10,2) AS avg_ms FROM pg_stat_statements WHERE query ILIKE '%for update%' OR query ILIKE '%for key share%' OR query ILIKE '%for share%' ORDER BY calls DESC LIMIT 10;

Step 5: Catch Long-Running Idle Transactions

Idle-in-transaction sessions are one of the most damaging contributors to SLRU contention. They hold row-level locks while doing nothing, preventing autovacuum from cleaning up MXIDs and forcing other sessions to queue on the same SLRU pages indefinitely. Query pg_stat_activity filtered to idle-in-transaction states and focus on sessions idle for more than 2 minutes; these are almost always stuck client tool connections (DBeaver, pgAdmin) or misbehaving application threads that opened a transaction and never committed.

SELECT pid, usename, application_name, state, now() - xact_start AS txn_age , now() - state_change AS idle_duration, left(query, 100) AS last_query FROM pg_stat_activity WHERE state IN ('idle in transaction', 'idle in transaction (aborted)') AND now() - state_change > interval '2 minutes' ORDER BY idle_duration DESC;

Fixes and Mitigation Strategies

Terminate long-running idle-in-transaction sessions

The fastest way to break the contention cycle during an active incident is to terminate sessions holding locks while idle. This immediately releases row-level locks, unblocks autovacuum, and allows MXID cleanup to resume. Always preview before terminating to avoid disrupting legitimate long-running batch jobs.

-- Preview candidates first SELECT pid, usename, application_name, now() - state_change AS idle_duration FROM pg_stat_activity WHERE state = 'idle in transaction' AND now() - state_change > interval '5 minutes' ORDER BY idle_duration DESC; --then run the terminate SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE state = 'idle in transaction' AND now() - state_change > interval '5 minutes';

Set timeouts to prevent recurrence

After immediate relief, set timeouts to automatically kill idle-in-transaction sessions before they accumulate again. Both parameters take effect immediately via pg_reload_conf() with no server restart required. Choose values appropriate to your workload, use more aggressive for high-concurrency OLTP, more lenient for batch or reporting workloads.

ALTER SYSTEM SET idle_in_transaction_session_timeout = 'XXmin'; ALTER SYSTEM SET statement_timeout = 'XXmin'; SELECT pg_reload_conf();

VACUUM FREEZE the most affected table

Running VACUUM FREEZE on the tables identified in Step 3 immediately clears old MXIDs from row headers, replacing them with frozen values that never require SLRU lookups. This directly reduces SLRU page access and LWLock contention. For very large tables, use INDEX_CLEANUP FALSE on the first pass for speed, then run a full vacuum during off-peak hours.

VACUUM FREEZE VERBOSE your_hot_table;

Connection pooling

Connection pooling is the most impactful long-term fix for preventing thundering herd connection storms. PgBouncer in transaction mode absorbs connection spikes at the pooler layer, ensuring PostgreSQL never sees more simultaneous sessions than the pool size, and directly reducing the number of concurrent MXID lookups and SLRU LWLock contention. On Azure PostgreSQL Flexible Server, PgBouncer is available as a built-in feature. Simply enable it via Server Parameters (pgbouncer.enabled = ON) and connect on port 6432. No separate installation is required.

# Key PgBouncer settings for OLTP workloads

pool_mode         = transaction   # Release connection after each transaction

default_pool_size = 100           # Real PG connections per database/user pair

max_client_conn   = 5000          # Total clients PgBouncer will accept

Conclusion

MultiXact SLRU wait events are deceptive. A server can show 100% cache hit ratio, nominal disk I/O, and moderate CPU, all while simultaneously stalling hundreds of sessions on a lock held for microseconds. The cache appears healthy, and the problem is invisible... until sessions start piling up.

The single most important diagnostic insight is this:

pg_stat_slru measures I/O efficiency.
pg_stat_activity measures lock contention.

A 100% hit ratio does not mean there are no problems, it means the bottleneck is the lock protecting the cached page, not the cache itself.

Once you know this, the path forward is clear. Use pg_stat_slru and pg_stat_activity together, never in isolation. Track mxid_age proactively, and do not wait for autovacuum to raise the alarm. Eliminate idle-in-transaction sessions before they become lock holders. Use the weakest lock mode that satisfies your application's consistency requirements. Use FOR NO KEY UPDATE instead of FOR UPDATE wherever possible. And deploy PgBouncer (available as a built-in feature on Azure Database for PostgreSQL Flexible Server) to absorb connection storms before they reach the SLRU layer.

MultiXact contention is not inevitable. It is the compounded result of concurrent locking patterns, under-tuned autovacuum, and unbounded connection growth, all of which are fully controllable. The earlier you instrument for it, the less likely it becomes an incident.

SELECT * FROM build2026_sessions WHERE postgres = true;

Pooja_Y — Tue, 26 May 2026 14:13:21 GMT

Microsoft Build 2026 is around the corner, and this year it’s shaping up to be a big one for PostgreSQL experts and enthusiasts. If you’re a developer working with Postgres, or just love exploring new database technology, there's plenty to get excited about. Microsoft’s new cloud-first evolution of PostgreSQL, Azure HorizonDB, alongside sessions featuring Azure Database for PostgreSQL, will highlight how Postgres is powering the next wave of AI-driven applications.

A new horizon in Postgres

Build 2026 arrives at a time when the role of databases in modern apps is evolving rapidly. From enabling AI model integration to scaling seamlessly across the cloud, PostgreSQL developers today are dealing with more complex demands than ever. That’s why Azure HorizonDB – Microsoft’s new cloud-native PostgreSQL service – is generating so much buzz ahead of Build.

What is Azure HorizonDB? In short, it’s a reimagined version of PostgreSQL designed for cloud-scale performance and AI-era workloads. Azure HorizonDB, introduces a distributed architecture that decouples compute and storage, delivering sub-millisecond latencies and three times the throughput of self-managed Postgres at massive scale. It aims to preserve Postgres’s beloved features and SQL ecosystem while adding next-generation capabilities: built-in vector indexing for high-speed AI/ML retrieval, the ability to run AI models and vector operations directly in the database, and multi-zone replication for resilience. For Postgres developers, this means less time stitching together external data stores or machine learning services – and more time building powerful apps on a unified platform that’s both familiar and built for the future.

The bottom line: Microsoft Build 2026 is an ideal opportunity for developers to see Azure HorizonDB in action, learn best practices for modern PostgreSQL architectures, and understand how to leverage Postgres in new scenarios like generative AI and multi-agent applications. Read on for a rundown of sessions covering these topics, complete with what you’ll learn from each one.

Top sessions for PostgreSQL databases on Azure

Below are key sessions tailored for PostgreSQL users and those interested in Azure HorizonDB, with session types and highlights of what you’ll gain by attending.

🎤 Breakout: From Rows to Reasoning: Designing Databases for AI Apps and Agents (BRK223, 45 min, in-person and digital options)

Discover how to architect databases that can power tomorrow’s intelligent applications. This technical breakout will show how AI-ready databases can move beyond plain transactions. You’ll see live demos of integrating transactional, analytical, and vector data in one unified platform, with Azure’s new database capabilities, including Azure HorizonDB. Learn how to simplify your stack by eliminating separate analytics engines or vector stores. The session will highlight patterns that reduce data movement and latency so your apps can efficiently reason over live data with minimal complexity.

🧪 Hands-on lab: Create Advanced Postgres-Powered Agentic Apps with Azure HorizonDB (LAB511, 75 min, in person and digital options)

Roll up your sleeves and get hands-on building a real multi-agent AI application with Postgres. In this advanced lab, you’ll create a production-ready AI agent powered by Azure HorizonDB as an all-in-one data, search, and intelligence layer. Experiment with retrieval-augmented generation (RAG) by combining semantic vector search (DiskANN) with traditional SQL queries right inside the database. Implement hybrid search and agent workflows without resorting to external vector databases or glue code – thanks to HorizonDB’s built-in vector indexing and in-database AI model capabilities. This lab is perfect for developers who want to experience how HorizonDB can simplify your stack and boost performance for AI-driven apps.
Multiple hands-on labs are offered to suite your schedule.

💻 Demo: Simplify App Dev with Cloud-Native PostgreSQL in Azure HorizonDB (DEM364, 25 min, in-person and digital options)

See how to cut your development time and complexity with built-in AI and search features in Postgres. This fast-paced demo shows how Azure HorizonDB helps eliminate the need for separate search engines and AI services by pulling those capabilities straight into PostgreSQL. Expect to learn how you can run hybrid vector + keyword queries using SQL, integrate AI models directly from within the database, and apply full-text search (BM25) and semantic ranking to get smarter results. If you’re eager to deliver intelligent apps faster, with fewer moving parts, this session will show how HorizonDB simplifies your architecture without sacrificing performance.

⚡Lightning Talk: Cloud-Native PostgreSQL, Rebuilt for Scale: Azure HorizonDB (LTG413, 15 min, in-person only)

Get a rapid-fire introduction to the architecture behind HorizonDB’s eye-popping performance. This short talk dives into how HorizonDB re-architects core PostgreSQL to deliver effortless scale out and blazing speed. Learn how decoupled compute and storage, predictive caching, and multi-region replication combine to achieve sub-millisecond query latencies and 3× higher throughput than standard Postgres. If you care about performance tuning and high-scale database design, don’t miss this quick primer on the tech under HorizonDB’s hood.

👥 Interactive Table Talk: Scaling PostgreSQL for AI Apps: Patterns and Tradeoffs (TT622, 45 min, in-person only)

Bring your questions and ideas to this collaborative discussion. In this open round-table session with community and Microsoft experts, you’ll explore architecture patterns for scaling PostgreSQL to meet the demands of agent-based and AI-driven applications. Discuss real-world strategies for handling vector embeddings in Postgres, unifying relational and document data, integrating with AI models, and more. Compare the trade-offs between different scaling approaches – from monolithic to microservices, sharding strategies, and new technologies like HorizonDB – and learn where each design shines or struggles in production. Come ready to share your experiences and learn from others in the room.

▶️ On-Demand: Smarter PostgreSQL Migrations to Power Modern, Intelligent Apps (OD822, 30 min, digital only)

Planning to migrate to Postgres or move your databases to Azure? Start here. This on-demand session focuses on new tools and proven strategies to migrate large-scale databases to Azure Database for PostgreSQL quickly and safely. You’ll see AI-assisted migration tools in action that minimize downtime and risk when moving terabytes of data. Just as importantly, you’ll learn how migrating to Azure unlocks advanced capabilities – from boosted performance and enhanced security to AI-ready features – helping you turn your newly migrated data into intelligent apps and services.
On-demand session will be available to stream on the first day of Build.

Meet the team: PostgreSQL expert meetups

If you’re attending Build in person, stop by the Expert Meetup (EMU) area and head to the relational cloud databases booth. This is your chance to talk directly with the engineers and product teams behind PostgreSQL on Azure.

Bring your questions about architecture decisions, scaling patterns, migrations, AI workloads, or anything else on your mind. Whether you want to sanity-check a design, dig deeper into something you saw in a session, or give direct feedback, the EMU space is designed for exactly that convo.

How to get the most out of Build (and what to do next)

With so much great content lined up, how do you decide where to start? It really depends on what you’re most excited about:

Curious about AI and agentic apps: Start with From Rows to Reasoning, then go deeper with the Simplify App Dev with HorizonDB demo or get hands-on at the Azure HorizonDB labs to see how these ideas work in practice.
Performance and scale are your focus: The short Lightning Talk on HorizonDB’s cloud-native architecture and the Table Talk on scaling Postgres will both provide unique insights and pro tips for running Postgres at massive scale.
Planning a migration to PostgreSQL on Azure: Watch the Smarter PostgreSQL Migrations on-demand session to learn how to migrate large workloads with minimal downtime, and the benefits you can unlock after moving to Azure.
Looking for real answers to your specific questions: Make time for the PostgreSQL Expert Meetup area to connect directly with the team.

No matter which sessions you choose, Build 2026 promises to be an exciting event for the PostgreSQL developer community. Browse the session catalog, save the sessions that match your interests, and we’ll see you at Build.

Regex support for LOB types in T-SQL—available in Azure SQL & SQL Server 2025

abhimantiwari — Fri, 22 May 2026 20:28:26 GMT

At a glance — Native regular expression (regex) functions in T-SQL now accept varchar(max) and nvarchar(max) inputs of up to 2 MB across all seven regex functions, including the two table-valued functions (REGEXP_MATCHES and REGEXP_SPLIT_TO_TABLE). This capability ships in SQL Server 2025 CU5 and is already available in Azure SQL Database, SQL Database in Fabric and Azure SQL Managed Instance configured with the Always-up-to-date update policy. It will reach Managed Instances on the SQL Server 2025 update policy as part of the CU5 rollout. You no longer need to split log files, HTML documents, or large JSON payloads into 8,000-byte chunks just to run a pattern match.

1. Introduction

Regular expressions have long been a cornerstone of modern data processing — used for validation, parsing, transformation, and extracting structured insights from unstructured text. With SQL Server 2025 and Azure SQL, regex is now a first-class T-SQL capability, removing the historical need to rely on SQLCLR functions or application-tier processing.

While the initial release made native regex broadly available, large-object (LOB) inputs were not yet supported on every function. CU5 closes that gap.

Under the hood, T-SQL regex implements POSIX Extended Regular Expression (ERE) semantics, augmented by a curated set of Perl-style features, and is powered by the RE2 engine. RE2 is a linear-time, non-backtracking implementation, which means it is not susceptible to catastrophic backtracking (a class of denial-of-service issue commonly known as ReDoS). That guarantee becomes far more important when the input is a 1.8 MB log blob than when it is an 8,000-byte string.

Release timeline

Milestone	What shipped
Ignite 2025 — General Availability	Regex went GA in SQL Server 2025 and Azure SQL. LOB inputs were initially supported only on REGEXP_LIKE, REGEXP_COUNT, and REGEXP_INSTR. LOB support on REGEXP_REPLACE and REGEXP_SUBSTR was deferred, and the two table-valued functions (TVFs) accepted only non-LOB string types.
Azure SQL (post-GA service updates)	LOB inputs enabled across all seven functions.
SQL Server 2025 CU5	LOB inputs up to 2 MB enabled on all seven functions in the SQL Server.

What’s new in CU5

varchar(max) and nvarchar(max) inputs are accepted on every regex function.
The input string is capped at 2 MB per function call. The pattern is still capped at 8,000 bytes, which is far larger than any maintainable regular expression should ever need.
Behavior is consistent between Azure SQL and SQL Server, so code you write today is fully portable.

Note — The 2 MB limit applies to the input passed to a single function call, not to the column or row. A single value in a varchar(max) column can still store up to 2 GB; the constraint is that no single regex evaluation can consume more than 2 MB of that value.

Prerequisites

SQL Server 2025 CU5 or later, or Azure SQL Database, or SQL Database in Fabric or Azure SQL Managed Instance configured with the SQL Server 2025 / Always-up-to-date update policy.
The two table-valued functions (REGEXP_MATCHES and REGEXP_SPLIT_TO_TABLE) require database compatibility level 170, unless the database-scoped configuration ALLOW_BUILTIN_TVF_IN_ALL_COMPAT_LEVELS (preview) is enabled.

Note — On Azure SQL Managed Instance (Always-up-to-date), this capability is rolling out region by region. It is already live in regions where the rollout has completed and will light up in the remaining regions as the deployment finishes. Instances on the SQL Server 2025 update policy will receive it as part of the CU5 rollout — coming soon.

Verify compatibility level (170 required for the TVFs) –

SELECT name, compatibility_level FROM sys.databases WHERE name = DB_NAME(); -- If necessary: -- ALTER DATABASE [<your-database>] SET COMPATIBILITY_LEVEL = 170;

2. Working with LOB Data

This section demonstrates the CU5 capabilities against a realistic LOB data. We build a LogEntries table whose RawPayload column holds multi-KB to multi-MB chunks of web server and application output, plus an HtmlPages table for HTML cleansing examples.

2.1 Create the sample schema and data

IF OBJECT_ID('dbo.LogEntries', 'U') IS NOT NULL DROP TABLE dbo.LogEntries; IF OBJECT_ID('dbo.HtmlPages', 'U') IS NOT NULL DROP TABLE dbo.HtmlPages; CREATE TABLE dbo.LogEntries ( LogId BIGINT IDENTITY(1,1) PRIMARY KEY, Source SYSNAME NOT NULL, IngestedAt DATETIME2(3) NOT NULL DEFAULT SYSUTCDATETIME(), RawPayload VARCHAR(MAX) NOT NULL -- LOB column ); CREATE TABLE dbo.HtmlPages ( PageId INT IDENTITY(1,1) PRIMARY KEY, Url NVARCHAR(2048) NOT NULL, Body NVARCHAR(MAX) NOT NULL -- LOB column (Unicode) );

Now generate realistically large rows. The REPLICATE(CAST(... AS varchar(max)), n) pattern is required because REPLICATE returns NULL when the result would exceed 8,000 bytes unless its first argument is a max type.

-- Synthetic web access-log payload (~252 KB in row 1, plus a separate ~586 KB row). DECLARE @logLine VARCHAR(500) = '127.0.0.1 - alice [21/May/2026:10:15:32 +0000] "GET /api/orders/42 HTTP/1.1" 200 1532 ' + 'user-agent="Mozilla/5.0" ip=10.0.0.7 email=alice@contoso.com card=4111-1111-1111-1234' + CHAR(10); DECLARE @bigLog VARCHAR(MAX) = REPLICATE(CAST(@logLine AS VARCHAR(MAX)), 1500) -- ~252 KB + '127.0.0.1 - mallory [21/May/2026:10:16:01 +0000] "POST /login HTTP/1.1" 500 0 ' + 'ip=203.0.113.99 ssn=123-45-6789' + CHAR(10); INSERT INTO dbo.LogEntries (Source, RawPayload) VALUES ('web-01', @bigLog), -- ~252 KB ('web-02', REPLICATE(CAST('OK ' AS VARCHAR(MAX)), 200000)); -- ~586 KB -- Synthetic HTML page (~775 KB / ~396,000 characters). DECLARE @htmlChunk NVARCHAR(MAX) = N'<div class="row"><p>Hello <b>world</b>! Contact <a href="mailto:bob@contoso.com">bob</a>.</p></div>'; INSERT INTO dbo.HtmlPages (Url, Body) VALUES (N'https://contoso.example/page-1', N'<html><head><title>Big Page</title></head><body>' + REPLICATE(@htmlChunk, 4000) + N'</body></html>'); -- Confirm payload sizes in bytes. SELECT LogId, Source, DATALENGTH(RawPayload) AS PayloadBytes FROM dbo.LogEntries; SELECT PageId, DATALENGTH(Body) AS BodyBytes, LEN(Body) AS BodyChars FROM dbo.HtmlPages;

Results:

LogId	Source	PayloadBytes
1	web-01	258,110
2	web-02	600,000

PageId	BodyBytes	BodyChars
1	792,124	396,062

Before CU5, feeding any of these payloads into REGEXP_REPLACE, REGEXP_SUBSTR, REGEXP_MATCHES, or REGEXP_SPLIT_TO_TABLE would have failed with a type-mismatch error or required a LEFT(RawPayload, 8000)-style truncation. The same queries now run end-to-end.

2.2 REGEXP_LIKE — Filter rows by LOB content

-- Find logs that contain at least one HTTP 5xx response. SELECT LogId, Source, DATALENGTH(RawPayload) AS PayloadBytes FROM dbo.LogEntries WHERE REGEXP_LIKE(RawPayload, '"[A-Z]+\s[^"]+\sHTTP/1\.[01]"\s5[0-9]{2}\s');

REGEXP_LIKE is a Boolean predicate: it evaluates to true when the pattern matches anywhere in the input and false otherwise. Because it returns a Boolean rather than a bit, use it directly in WHERE, CASE WHEN, IIF, or CHECK constraint contexts — do not compare it with = 1 or = 0 (the parser rejects that syntax).

Note — REGEXP_LIKE itself requires database compatibility level 170. The other scalar regex functions (REGEXP_COUNT, REGEXP_INSTR, REGEXP_REPLACE, REGEXP_SUBSTR) are available at all compatibility levels.

Results:

LogId	Source	PayloadBytes
1	web-01	258,110

2.3 REGEXP_COUNT — Counting at scale

-- Per-row tally of GET requests, POST requests, and 5xx responses -- across the entire LOB payload. SELECT LogId, Source, REGEXP_COUNT(RawPayload, '"GET\s') AS Gets, REGEXP_COUNT(RawPayload, '"POST\s') AS Posts, REGEXP_COUNT(RawPayload, '\s5[0-9]{2}\s') AS ServerErrors FROM dbo.LogEntries;

Results:

LogId	Source	Gets	Posts	ServerErrors
1	web-01	1,500	1	1
2	web-02	0	0	0

2.4 REGEXP_INSTR — Locate the first error

-- 1-based character position (or 0 if no match) of the FIRST 5xx response in each payload. SELECT LogId, Source, REGEXP_INSTR(RawPayload, '\s5[0-9]{2}\s', 1, 1, 0) AS FirstErrorPos FROM dbo.LogEntries;

Parameter recap: REGEXP_INSTR(string, pattern, start, occurrence, return_option [, flags [, group ]]). A return_option of 0 returns the starting position of the match; 1 returns the position immediately after the last character of the match.

Results:

LogId	Source	FirstErrorPos
1	web-01	258,072
2	web-02	0

2.5 REGEXP_REPLACE — Redact sensitive data in place

PII redaction over LOB payloads was one of the most-requested CU5 scenarios. Before CU5, it required a custom chunked-replace routine; it is now a single expression.

-- Redact credit-card-shaped tokens, U.S. SSN-shaped tokens, and email addresses -- across the entire payload. SELECT LogId, REGEXP_REPLACE( REGEXP_REPLACE( REGEXP_REPLACE( RawPayload, '\b[0-9]{4}[- ]?[0-9]{4}[- ]?[0-9]{4}[- ]?[0-9]{4}\b', '****-****-****-****'), '\b[0-9]{3}-[0-9]{2}-[0-9]{4}\b', '***-**-****'), '\b[A-Za-z0-9._%+\-]+@[A-Za-z0-9.\-]+\.[A-Za-z]{2,}\b', '[redacted-email]' ) AS RedactedPayload FROM dbo.LogEntries;

Or strip every HTML tag from an nvarchar(max) page in a single call:

SELECT PageId, LEN(Body) AS OriginalLen, LEN(REGEXP_REPLACE(Body, N'<[^>]+>', N'')) AS TextOnlyLen FROM dbo.HtmlPages;

Results — the ~775 KB HTML document collapses from 396,062 to 100,008 characters of plain text in a single call:

PageId	OriginalLen	TextOnlyLen
1	396,062	100,008

2.6 REGEXP_SUBSTR — Extract a single value

-- Pull the first IPv4 address out of each log payload. SELECT LogId, REGEXP_SUBSTR(RawPayload, '\b(?:[0-9]{1,3}\.){3}[0-9]{1,3}\b', 1, -- start position 1, -- occurrence 'c', -- flags: case-sensitive 0 -- group: 0 returns the whole match ) AS FirstIp FROM dbo.LogEntries;

To return the contents of a specific capture group instead of the entire match, pass its 1-based group number as the final argument.

Results:

LogId	FirstIp
1	127.0.0.1
2	NULL

2.7 REGEXP_MATCHES — Every match, set-based

This is where the combination of TVF and LOB delivers the largest productivity gain: extract every structured value from a megabyte of unstructured text in a single set-based query, with no client round-trips.

REGEXP_MATCHES returns one row per match with these columns:

Column	Type	Description
match_id	bigint	Sequence number of the match (1-based).
start_position	int	1-based start index of the match.
end_position	int	1-based end index of the match.
match_value	same type as string_expression	The entire matched substring.
substring_matches	json	JSON array describing each capture group, with the shape [{"value":"…","start":N,"length":N}, …].

-- Every email address in every log payload, alongside its row of origin. SELECT l.LogId, m.match_id, m.match_value AS EmailFound FROM dbo.LogEntries AS l CROSS APPLY REGEXP_MATCHES( l.RawPayload, '\b[A-Za-z0-9._%+\-]+@[A-Za-z0-9.\-]+\.[A-Za-z]{2,}\b' ) AS m ORDER BY l.LogId, m.match_id;

Capture groups are even more useful — you can project the parts of every log line as columns by reading from the substring_matches JSON document:

-- Parse Common-Log-Format-ish entries into ip, user, status, and bytes columns. -- The pattern has four capture groups, accessed below as $[0] through $[3]. SELECT l.LogId, m.match_id, JSON_VALUE(m.substring_matches, '$[0].value') AS Ip, JSON_VALUE(m.substring_matches, '$[1].value') AS UserName, JSON_VALUE(m.substring_matches, '$[2].value') AS Status, JSON_VALUE(m.substring_matches, '$[3].value') AS Bytes FROM dbo.LogEntries AS l CROSS APPLY REGEXP_MATCHES( l.RawPayload, '^([0-9.]+)\s-\s(\S+)\s\[[^\]]+\]\s"[^"]+"\s([0-9]{3})\s([0-9]+)', 'm' -- multi-line: ^ and $ anchor to each line, not just the whole input ) AS m ORDER BY l.LogId, m.match_id;

Important — Without the 'm' flag, the ^ anchor matches only at the start of the entire 250 KB input, so you would receive exactly one match for the first line. The multi-line flag is what unlocks per-line extraction.

Results (first two parsed rows):

LogId	match_id	Ip	UserName	Status	Bytes
1	1	127.0.0.1	alice	200	1532
1	2	127.0.0.1	alice	200	1532

2.8 REGEXP_SPLIT_TO_TABLE — Shred a LOB into rows

-- Project the entire log payload as one row per non-empty line. SELECT l.LogId, s.ordinal AS [LineNo], s.value AS LineText FROM dbo.LogEntries AS l CROSS APPLY REGEXP_SPLIT_TO_TABLE(l.RawPayload, '\r?\n') AS s WHERE l.LogId = 1 AND s.value <> '' ORDER BY s.ordinal;

You now have a tabular projection of a multi-megabyte text blob without leaving the engine. You can feed it into a CTE, aggregate it, join it to dimension tables, or materialize it into a staging table — all set-based.

Results (first three rows):

LogId	ordinal	LineText (first 80 chars)
1	1	127.0.0.1 - alice [21/May/2026:10:15:32 +0000] "GET /api/orders/42 HTTP/1.1" 200
1	2	127.0.0.1 - alice [21/May/2026:10:15:32 +0000] "GET /api/orders/42 HTTP/1.1" 200
1	3	127.0.0.1 - alice [21/May/2026:10:15:32 +0000] "GET /api/orders/42 HTTP/1.1" 200

Tip — composing LOB regex pipelines — CROSS APPLY (and OUTER APPLY when you need to preserve rows that produce no matches) is the primary composition primitive. You can stack REGEXP_SPLIT_TO_TABLE (lines) feeding REGEXP_MATCHES (fields per line) feeding ordinary aggregates, all within a single query plan.

2.9 The 2 MB ceiling — strategies for larger inputs

The 2 MB limit applies to the input string of a single regex call. If the value passed to a regex function exceeds 2 MB, the call raises an error (error number 19311, severity 16) rather than silently truncating. That is the intended behavior — silent truncation would hide correctness bugs.

In practice, 2 MB is a generous ceiling: a single log file or HTML document of that size is already unusual, and most real-world LOB data sit comfortably below it. When individual values do exceed the limit, the most reliable approach is to split them into smaller logical units before they land in the column you want to query — for example, by writing one log line, one document section, or one record per row at ingestion time. Because every regex function (including the two TVFs) shares the same 2 MB ceiling, sharding at query time is not generally feasible; doing it at the load path keeps every regex call well under the limit and avoids per-query workarounds.

Bytes vs. characters — The 2 MB limit is measured in bytes, not characters, and the byte count is based on the UTF-8 encoding of the input regardless of the column’s declared type. ASCII characters take 1 byte each, so plain ASCII text can run to roughly two million characters; non-ASCII characters take 2–4 bytes in UTF-8, so fewer characters fit. Keep in mind that DATALENGTH() reports storage size in the column’s own encoding, which may differ from the UTF-8 byte count used by the limit, and LEN() (which counts characters) is best avoided as a sizing check here.

To measure the UTF-8 byte length that the limit actually checks, cast the value to varchar(max) under a UTF-8 collation and take its DATALENGTH:

SELECT DATALENGTH( CONVERT(varchar(max), Body COLLATE Latin1_General_100_CI_AS_SC_UTF8) ) AS Utf8Bytes FROM dbo.HtmlPages;

Anything above 2 * 1024 * 1024 (2,097,152) bytes will be rejected by a regex call on that value.

Have a scenario that genuinely needs more than 2 MB? If your workload requires regex evaluation on individual values larger than the current 2 MB ceiling, we would like to hear about it. Please share the details — data shape, payload size, pattern, and business need — on the Azure SQL feedback portal. Customer feedback directly informs how we prioritize future limit changes.

2.10 Cleanup

DROP TABLE IF EXISTS dbo.LogEntries; DROP TABLE IF EXISTS dbo.HtmlPages;

3. Summary

What changed in CU5

Before CU5 — LOB inputs were accepted on REGEXP_LIKE, REGEXP_COUNT, and REGEXP_INSTR. The remaining functions — REGEXP_REPLACE, REGEXP_SUBSTR, and the two TVFs (REGEXP_MATCHES, REGEXP_SPLIT_TO_TABLE) — required non-LOB string inputs, which often meant truncating with LEFT(..., 8000) or chunking in the application tier.
After CU5 (and already in Azure SQL) — All seven functions accept varchar(max) and nvarchar(max) inputs of up to 2 MB. The pattern remains capped at 8,000 bytes.

Quick reference

Function	Returns	LOB input (CU5)	Common use case
REGEXP_LIKE	Boolean (predicate)	Yes	Filter rows in WHERE / CASE / CHECK predicates
REGEXP_COUNT	int	Yes	Count occurrences of a pattern
REGEXP_INSTR	int	Yes	Position of the nth match
REGEXP_REPLACE	string	Yes	Redact, cleanse, or normalize text
REGEXP_SUBSTR	string	Yes	Extract a single value
REGEXP_MATCHES (TVF)	(match_id, start_position, end_position, match_value, substring_matches)	Yes	Extract every match plus capture groups (via JSON), set-based
REGEXP_SPLIT_TO_TABLE (TVF)	(value, ordinal)	Yes	Split a LOB into rows by a regex delimiter

Real-World Success Stories with PostgreSQL on Azure

Pooja_Y — Wed, 20 May 2026 17:34:35 GMT

Organizations rarely leap into cloud migrations or AI-powered systems overnight. They progress in deliberate stages, establishing a reliable data foundation, optimizing for performance, and then accelerating innovation. Across healthcare, financial services, and AI startups, companies are navigating this journey on Azure Database for PostgreSQL: a fully managed, enterprise-ready PostgreSQL environment with 58% lower total cost of ownership (TCO) compared to on-premises deployments.

This post walks through real customer stories that span the full arc, from lift-and-shift migration to production-grade AI agent development, illustrating how Azure Database for PostgreSQL supports scalability, performance, security, and AI-readiness at every stage.

Migrating with Confidence: Apollo Hospitals & August AI

Apollo Hospitals operates a network of more than 74 hospitals and needed to move beyond a legacy on-premises Oracle system that had become difficult to manage and couldn't keep pace with growing data volumes. IT teams were spending their time on maintenance rather than innovation.

Apollo migrated its core hospital information system backend to Azure Database for PostgreSQL. Working with partner Quadrant Technologies, the team lifted and shifted critical applications while using Azure DevOps to orchestrate CI/CD pipelines and Azure Application Insights for telemetry and observability. The results:

99.95% availability across hospital systems
Database transactions executing within 5 seconds
40% reduction in deployment times via modern CI/CD pipelines
Decreased operational overhead, freeing IT staff for higher-value work

With a stable, scalable PostgreSQL backend in place, Apollo is now exploring real-time analytics and AI-enabled tools like Microsoft 365 Copilot to advance patient care.

"We saw Azure Database for PostgreSQL as the right foundation for the future. It's open, cost-effective, and capable of supporting the hospital information system we built in-house." — Shankar Krishna A., General Manager of IT, Apollo Hospitals

Apollo's experience is not unique. August AI, a healthcare-tech startup offering an AI-driven medical companion, migrated its entire stack to Azure—with Azure Database for PostgreSQL storing mission-critical patient data while meeting strict compliance requirements such as HIPAA. The result: scaling from roughly 500,000 users to 3.5 million+ users worldwide, with zero downtime during the cutover, completed in just three months. As Founder and CEO Anuruddh Mishra noted: "We receive a log of queries that are not performing optimally, and within a couple of minutes we can optimize that query with PostgreSQL on Azure and move on".

Modernizing at Scale: Nasdaq

Migration is often the first step. Nasdaq demonstrates what becomes possible when organizations modernize their architecture on a scalable data foundation.

To improve its Nasdaq Boardvantage platform—used by corporate boards to collaborate on governance documents—Nasdaq re-architected on Azure. The team containerized services with Azure Kubernetes Service (AKS) and adopted Azure Database for PostgreSQL alongside Azure Database for MySQL as persistent data stores for governance workloads. This architecture provided the flexibility, performance, and security required for a multitenant platform handling sensitive board materials.

With the data layer in place, Nasdaq integrated Microsoft Foundry and Azure OpenAI to deliver AI-powered summarization and workflow automation. The measurable outcomes:

60% reduction in reading time through AI-powered document summarization
25% decrease in administrative preparation time across board workflows
Up to 97% accuracy in AI-generated summaries and meeting minutes
A reusable AI framework established for future extensibility

"Both Azure Database for PostgreSQL and Azure Database for MySQL gave us the right balance of performance, security, and control. The governance workloads we handle are unique, so we needed something that could meet those isolation and encryption requirements." — Scott Ellison, Vice President of Technology, Nasdaq

Building Intelligent Applications: SubgenAI and OpenAI

Azure Database for PostgreSQL now supports native vector search via pgvector, high-performance DiskANN indexing, semantic operators and AI model management, and integrated graph capabilities for relationship reasoning—making it a production-ready foundation for intelligent applications.

SubgenAI, a European generative AI company, built its flagship platform Serenity Star on Azure Database for PostgreSQL and Microsoft Foundry to transform AI agent development from a code-heavy, fragmented process into a streamlined, no-code experience. A core technical requirement: the platform's retrieval-augmented generation (RAG) system needs efficient vector search against embedded content while maintaining enterprise-grade reliability. After evaluating several database options, SubgenAI chose Azure Database for PostgreSQL with pgvector for its accurate and scalable vector similarity search. Serenity Star customers can now:

Launch AI agents in as little as 15 minutes
Cut coding and development time by 50%
Resolve most AI agent queries in under 60 seconds [

"With Microsoft and Azure Database for PostgreSQL we have total control and an environment that is truly dynamic and can adapt to the evolution we're looking for." — Julia Schröder Langhaeuser, VP of Product Serenity Star, SubgenAI

At the extreme end of scale, OpenAI runs PostgreSQL on Azure to support production systems behind ChatGPT. As write scalability limits emerged on an initially unsharded single primary instance, OpenAI offloaded write-heavy operations to other systems and optimized read workloads using PgBouncer for connection pooling. The Azure Database for PostgreSQL team responded by developing the elastic clusters feature, enabling horizontal scaling through row-based and schema-based sharding. The team reduced connection latency from approximately 50 ms to under 5 ms, scaled reads horizontally with multiple replicas, and improved reliability by prioritizing critical requests—all achieved by a small team making systematic optimizations on open-source PostgreSQL.

"After all the optimization we did, we are super happy with Postgres right now for our read-heavy workloads. It's really scalable and reliable." — Bohan Zhang, Member of the Technical Staff, OpenAI

Meeting You Where You Are

Beyond these stories, organizations like BMW Group (cloud-native applications at global scale), Ahold Delhaize (highly available retail applications), Mott MacDonald (an AI agent accelerating onboarding and spreading best practices across 220,000 employees), and Multitude (scaling responsibly in regulated environments) all run on Azure Database for PostgreSQL. The service offers 99.99% availability with automatic failover and SLA, independent compute and storage scaling, and intelligent performance recommendations, available across 60+ Azure regions. Developer tooling including the PostgreSQL extension for Visual Studio Code with GitHub Copilot further accelerates productivity.

Whether you are planning your first migration or building production AI agents, these stories share a clear signal: Azure Database for PostgreSQL delivers a scalable, secure, AI-ready data foundation at every stage of growth.

Explore full customer stories in depth in the eBook: Customer Success Stories with Azure Database for PostgreSQL.

Native Database/Query Monitoring with Azure Database for PostgreSQL

soudey — Wed, 20 May 2026 14:14:33 GMT

Monitoring PostgreSQL Database Engine

The PostgreSQL database engine provides multiple administrative views, which can be leveraged to capture metrics of activities inside of the database engine including, but not limited to, database activities, query activities, execution time, database resource locks etc for initial and deep analysis on database & query performance. Database Administrators should use these views and their corresponding metrics to perform initial level analysis. Critical insights can be gathered around database activity, performance and system activity for reactive and proactive analysis.

In this blog, I am going to show the important administrative views and their corresponding SQL statements for capturing database and query details.

The following section provides details about the statistics views and their usage. It contains the most important and mostly used statistics views, there are other views available that can be used to get into further details.

NOTE: The queries and flows provided below are a few of the ways for each scenario. Eventually, the final approach will depend on and be dictated by the issue at hand or its symptoms.

Pre-requisites

The following parameters should be enabled in Azure Database for PostgreSQL “Server parameters” before using the statistics views:

track_activities
track_counts
track_io_timing
pg_stat_statements.track = ALL

The following extensions should be installed before using the stats:

create extension pg_stat_statements; create extension pgstattuple;

NOTE: All SQL queries mentioned below are as per PostgreSQL version 18.

Schema & Data for Analysis

All the "Example Scenario" mentioned in the analysis queries are based on the following schema and corresponding volumetrics:

Table Name	No. of rows
customer	993,814
invoice	20,229,119
orders	4,497,292
product	2,818,000

Statistics Views and SQL Queries for Analysis

The following SQL statements can be used to perform 1^st level monitoring on the database, tables and queries. Note that the output counters and metrics from the SQL statements represent cumulative data since the last server restart. The statistics should be reset to zero before performing troubleshooting or performance tuning exercises. Use the below mentioned SQL statements to reset statistics at database, table and IO level.

Database level stats reset
- SELECT pg_stat_reset();

IO level stats reset.
- SELECT pg_stat_reset_shared('io');

Reset pg_stat_statements metrics per user, query and database id or for the entire database - pg_stat_statements contain query level metrics for a database, user or a single query. We can reset the statistics at these individual levels. If any of the parameters are not specified, the default value 0 is used for each of them and the statistics that match with other parameters will be reset. "userid", "dbid" (Database ID), "queryid" can be fetched from pg_roles (column - oid), pg_stat_database (column - datid) and pg_stat_activity (column - query_id) respectively.
- SELECT pg_stat_statements_reset(userid, dbid, queryid);
- SELECT pg_stat_statements_reset();

SQL Activity Monitoring:

This query uses pg_stat_activity statistics view, which contains details of current activities in the database server. It can be used to track queries in transactions, transaction execution time, wait event details if any etc. The WHERE clause can be used to filter activities based on client IP address (client_addr), application name (application_name), user (usename) who has submitted the query and text of the SQL statement.

SELECT datname AS dbname, pid, usename as username, application_name, client_addr as client_ip_addr, xact_start AS transaction_start_time, query_start AS query_start_time, wait_event_type AS db_waitign_on, wait_event AS waiting_activity, CAST(query AS varchar(100)) AS sql_query, backend_type AS db_operation FROM pg_stat_activity WHERE <conditions>;

Interpreting output: This output should be used to find overall activity in your database.

username, application_name, client_ip_addr - The user, application and client IP address from where the query is being executed.
transaction_start_time - When transaction started (using BEGIN keyword or corresponding API).
query_start_time - Start time of currently active query in the transaction.
wait_event and wait_event_type columns output the events on which the query is waiting, if applicable. Refer to the official links for details on wait events and wait event types.
db_operation - Type of database operation that is being performed by the application. E.g. autovacuum, parallel worker, client backend, etc.

Example Scenario: Application team is complaining about higher load in "retail_db" database and it is causing multiple SQL statements to run slow, team wants to know whether ad-hoc SQL statements are being run using "psql" client by application developers. As a DBA, you want to look at the entire database activity - no. of SQL statements, who are running to SQLs and which client are they coming from. Above mentioned SQL can be used with filters on "application_name" (value = "psql") and "dbname" (value = "retail_db"). It generates the following output:

Analysis: From the above output, it can be seen that "psql" client is indeed getting used from a few IP addresses.

Next Step: pg_terminate_backend(<pid>) can be used to kill the applications with pid 22210, 22209 and 21993.

Similarly, the same SQL statement can be used to look at overall SQL activities in individual database.

SQL Statement Level monitoring

This is one of the most important SQL statements that describes operations at query level. It provides execution time detail of queries, read time, write time, disk read and disk write. Output of this query should serve as one of the starting point of query troubleshooting and query optimization.

SELECT queryid , CAST(query AS varchar(100)) AS sql_stmt, calls AS no_of_executions, total_exec_time, min_exec_time, max_exec_time, mean_exec_time AS avg_exec_time, rows AS rows_fetched, shared_blks_hit AS blocks_read_from_buffer, shared_blks_read AS blocks_read_from_disk, shared_blks_written AS blks_written_to_disk, shared_blk_read_time, shared_blk_write_time FROM pg_stat_statements WHERE query LIKE '%<sql-stmt>%';

Interpreting output: Output of this query can be used to dive deeper into SQL performance issues.

sql_stmt - Provides the SQL statement that is being run. This is the query that is being analyzed for tuning.
no_of_executions - How many times this SQL statement has been executed so far (since the reset of pg_stat_statements).
total_exec_time - This is the execution time for the query combining all runs. e.g. if the query was run 10 times and each time took 1.5s, then total_exec_time would be 15s.
min_exec_time - Min. time the query took to execute. This can be considered as the benchmark execution time for this query.
max_exec_time - Max. time the query took to execute.
avg_exec_time - Avg. execution time of the query. This time should fall within the query SLA.
rows_fetched - No. of rows needed by application (SQL query)
blocks_read_from_buffer & blocks_read_from_disk - Data blocks (8KB size) read from PostgreSQL shared memory and from disk respectively.
shared_blk_read_time & shared_blk_write_time - Total time spent in reading from and writing to disk. This time is included in total_exec_time. If ratio of shared_blk_read_time or shared_blk_write_time or both with total_exec_time is higher, then IO is causing high execution time in this query. If the ratio is less then other complex SQL operations like join, order by, group by, functions etc. are taking longer to execute.

Example Scenario: We will be using the same SQL statement that was used in the example scenario of "3. Application-wise IO Activities". But in this case, using "SQL Statement Level monitoring" we will look at the execution details of the query rather than IO usage. Following is the output of first execution (after server restart - shared memory was empty) of the SQL statement

Analysis: Here is the observation, execution time of the query was 154.81 seconds. Total rows needed by application was 4,497,292 out of which 341 8KB blocks were read from shared memory (PostgreSQL bufferpool) and 58504 8KB blocks were read from disk.

Following is the output after 2nd execution (after resetting pg_stat_statements):

Analysis: The query was executed 4 times. Execution time got reduced to 95 seconds, but it is still high. Even though all rows (4497292 x 4) were read from shared memory (buffer pool) as blocks_read_from_disk was zero, execution time is very high.

Next Step: Even if the execution time is found to be within SLA, the query needs to be analyzed for its execution plan. Use EXPLAIN ANALYZE command to analyze the access plan or execution path of the query. Query optimization must be done for this SQL statement.

Table-level Bloat Statistics

PostgreSQL uses MVCC (Multi Version Concurrency Control) to avoid read and write conflicts, which means one application can read rows while they are being modified by another application. This is done by storing multiple versions of the same row. But over time older versions, which are not needed by applications, become overhead as they occupy space. This is known as "Bloating". It can cause both storage and performance issue. The query mentioned below provides bloating percentage on a table, which should be monitored on a regular basis and DBAs should decide on the autovaccuum settings.

SELECT (table_len/1024/1024) AS table_size_mb, tuple_count AS no_of_live_rows, (tuple_len/1024/1024) AS live_row_size_mb, dead_tuple_count AS no_of_dead_rows, (dead_tuple_len/1024/1024) AS dead_row_size_mb, tuple_percent AS live_rows_percent, dead_tuple_percent AS dead_rows_percent, free_percent AS free_space_percent, (((table_len – tuple_len)/table_len)*100) AS bloat_percent FROM pgstattuple('<table-name>');

Interpreting output:

table_size_mb - This is the total table size, including bloating.
no_of_live_rows - No. of actual usable rows in the table.
live_row_size_mb - This is the actual size of the table. This is the amount of data in this table that can be used by applications.
no_of_dead_rows - No. of irrelevant rows in the table.
dead_row_size_mb - Size of irrelevant rows in the table. This is the amount of data that is not needed by any application, but is still there in the table and occupying storage. This is the data that has to be removed from the table.
bloat_percent - Percentage of dead rows occupying the table. If it goes beyond 25-30%, manual VACUUM should be used to remove bloating.

Example Scenario: invoice_history table contains more than 20 M rows and has a size of 1630 MB. Deleting records from a table does not reduce the size in PostgreSQL because of MVCC support to keep multiple versions of the same row. The deleted rows still occupy storage space, it is known as bloating as shown below.

"Table level Bloat Statistics" can be used to find the bloat percentage of a table.

Next Step: Aggressive AUTOVACUUM has to be configured to remove bloating on time. As AUTOVACUUM does not free up storage space, manual FULL VACUUM has to be executed to reclaim storage space. Note that full vacuum takes exclusive lock on tables. Bloat percentage changed after executing full vacuum.

Table Bloat using Stat table

Table bloating information using statistics table.

SELECT schemaname, relname AS tblname, n_live_tup AS live_rows, n_dead_tup AS dead_rows, ((n_dead_tup - n_live_tup)/100) AS tbl_bloat_percent, last_vacuum AS last_manual_vacuum, last_autovacuum FROM pg_stat_all_tables WHERE relname = '<tblname>';

Interpreting output: Same as "Table-level Bloat Statistics".

Database Activity Monitoring

This SQL statement provides row level counters of DML statements for a database.

SELECT datname AS dbname, blks_read AS total_no_of_read_ops, blks_hit AS no_of_blks_read_from_bufferpool, tup_returned AS no_of_rows_scanned, tup_fetched AS no_of_rows_fetched, tup_inserted AS no_of_rows_inserted, tup_updated AS no_of_rows_updated, tup_deleted AS no_of_rows_deteled, deadlocks AS no_of_deadlocks, (blk_read_time/1000) AS blk_read_time_s, (blk_write_time/1000) AS blk_write_time_s FROM pg_stat_database;

Interpreting output: Output shows the impact of DML operations in a database.

total_no_of_read_ops - This is the total block read request executed by the database engine.
no_of_blks_read_from_bufferpool - Out of total read requests, how many blocks were already there in memory or shared_mem.
no_of_rows_scanned & no_of_rows_fetched - Total no. of rows read from the database and the total no. of rows actually needed by application. Higher difference in the two metrics should call for query tuning using better indexes, join strategies etc.
blk_read_time_s & blk_read_write_s - Time taken in seconds, to perform read and write operations.
no_of_deadlocks - Higher no. of deadlocks should be investigated. Execution of application SQL queries might have to be re-looked if higher deadlocks create performance or application issues.

Index-level Bloat Statistics – Live rows, dead rows, bloat

This is similar to query no. 8, but it provides bloating information at index level.

SELECT (index_size/1024/1024) AS idx_size_mb, (index_size/8192) AS index_pages, empty_pages, deleted_pages, ((index_pages - deleted_pages)/index_pages) * 100 AS idx_bloat_percent FROM pgstatindex('<idx-name>');

Interpreting output: The output is similar to table-level bloat statistics, but it is for indexes.

Monitor IO activities

Output of the following SQL statement shows the overall IO (Input/Output) activities for a database. It can be used to infer whether database workload is read heavy or write heavy. For read workloads, database level bufferpool_hit_ratio metrics can be used to increase or decrease shared memory configuration parameter.

SELECT backend_type , object, context AS reason_for_io, reads AS no_of_reads, (read_bytes/1024) AS read_data_kb, read_time AS read_time_ms, writes AS no_of_writes, (write_bytes/1024) AS write_data_kb, write_time AS write_time_ms, writebacks AS no_of_blocks_to_storage, writeback_time AS block_to_storge_write_time_ms , hits AS no_of_reads_from_bufferpool, 100 * (hits / (hits + reads)) AS bufferpool_hit_ratio FROM pg_stat_io;

Interpreting output: The output showcases database level IO metrics.

backend_type - Type of database operation that is being performed by the application. E.g. autovacuum, parallel worker, client backend, etc.
reason_for_io - corresponding IO operation. Following are the possible output values to look out for.
- normal - Read from or write to shared buffers.
- vacuum - IO used by VACUUM operation.
- bulkread & bulkwrite - Disk read and write operations.
no_of_reads - Total read operations.
read_data_kb - Amount of data read (in KB) across all operations.
no_of_writes - Total write operations.
write_data_kb - Amount of data written (in KB) across all operations.
read_time_ms & write_time_ms - Duration of all read & write operations.

Example Scenario: Extending the previous example, application team is complaining about overall performance of the database. As a DBA you want to find out the overall read and write operations to confirm whether it is causing slowness in the database. It will give an idea about how busy the database has been. "Monitor IO Activities" SQL can be used to find out the trigger of higher IO activities in the database. Following is the output:

Analysis: Output above shows that most of the read and write operations are emanating from applications ("backend_type" = "client backend"). This gives an idea of database usage by the applications.

Next Step: If resource utilization of this database is high, we can create read replica to offload the reads and increase server memory and CPU to handle the load. Or else, if possible, application throttling can be infused by reducing the no. of max connections or using application level throttling.

Application-wise IO Activities

Query no. 2 above provides database level IO, the following SQL statement can be used to track application level IO summary. As there is to one-to-one mapping between application id in pg_stat_activity and pg_stat_io, backend_type is the only way to relate these two admin views.

SELECT psa.datname AS dbname, pid, psa.usename AS username, psa.application_name, psa.client_addr as client_ip_addr, psa.xact_start AS transaction_start_time, psa.query_start AS query_start_time, psa.wait_event_type AS db_waitign_on, psa.wait_event AS waiting_activity, CAST(psa.query AS varchar(100)) AS sql_query, state as current_state, psa.backend_type AS db_operation, psi.context AS reason_for_io, psi.reads AS no_of_reads, psi.writes AS no_of_writes FROM pg_stat_activity psa JOIN pg_stat_io psi ON psa.backend_type = psi.backend_type WHERE psa.query LIKE '%<sql-stmt>%';

Interpreting output:

username, application_name and client_ip_addr column output can be used to track user who submitted the query, application from where the query was submitted and IP address of the application server from where query was executed.
transaction_start_time & query_start_time show the execution start time of transaction and currently active query inside of the transaction. These metrics should be used to find the execution time of transaction and queries inside of the transaction.
wait_event and wait_event_type columns output the events on which the query is waiting, if applicable. Refer to the official links for details on wait events and wait event types.
reason_for_io column outputs corresponding IO operation. Following are the possible output values to look out for.
- normal - Read from or write to shared buffers.
- vacuum - IO used by VACUUM operation.
- bulkread & bulkwrite - Disk read and write operations.
no_of_reads & no_of_writes - Total no. of read and write operations by the query.

Example Scenario: So far we have been looking at database-level activities. In most of the cases, we need to track application level activities like read, write operations, application elapsed time (how long the query is getting executed for). These are some of the critical information that DBA should use while troubleshooting query performance or application slowness issue. Whereas pg_stat_statements should be the go to place to look at SQL or application-level statistics, above SQL statement can be used to monitor application level IO operations.

Executed SQL statement :

SELECT c.cust_id, c.cust_email, c.cust_type, o.order_no, o.order_date FROM customer c, orders o WHERE c.cust_id = o.cust_id ORDER BY o.order_date DESC;

Output of the query can be filtered using partial SQL statement in the WHERE clause or using PID of the SQL statement as shown below.

Following is the output of the query above (showing only relevant columns):

Analysis: Highlighted output above shows 3 types of IO operations - normal, bulkwrite and bulkread. "normal" means that client is reading from buffer, but "bulkread" and "bulwrite" indicates read from disk and write to disk (temporary file write for sorting!).

Next Step: SQL statement should to be analysed further for index usage, high disk read and write IO. EXPLAIN (with ANALYZE) statement can be used to understand query behaviour. Other monitoring SQL statements should be used to dig deeper into the execution details.

Table & Index Operations

The following SQL statement can be used to capture table-level DML operations and its corresponding index read operations. Output of this query can be used to create index if sequential scans on a table is high, also, how an application is impacting the table rows using INSERT, UPDATE, DELETE statements.

SELECT t.schemaname AS tabschema, t.relname AS tabname, t.seq_scan AS no_of_seq_scan, t.seq_tup_read AS seq_scan_rows_read, t.n_tup_ins AS rows_inserted, t.n_tup_upd AS rows_updated, t.n_tup_del AS rows_deleted, t.n_live_tup AS total_active_rows, t.n_dead_tup AS total_dead_rows, i.schemaname AS idxschema, i.indexrelname AS idxname, i.idx_tup_read AS idx_rows_read, i.idx_tup_fetch AS idx_rows_fetched FROM pg_stat_all_tables t JOIN pg_stat_all_indexes i ON t.relid = i.relid AND t.relname = i.relname ;

Interpreting output: It is almost similar to database activity monitoring except for the following columns.

total_dead_rows - Total no. of rows that are not relevant for any transaction in PostgreSQL.
total_active_rows - Total no. of actual rows in the table.

If the ratio of dead rows vs active rows is higher, it shows VACUUM is not working properly. It can be fixed by running manual vacuum or changing the configuration of AUTOVACUUM.

Table level Read IO

This SQL statement provides critical metrics on read operations for all or individual tables. heap_blks_read and heap_blks_hit should be used to find out the disk read vs memory read in tables. Higher disk read indicates memory crunch and can be a factor in deciding whether to increase shared memory size.

SELECT schemaname AS tabschema, relname AS tabname, heap_blks_read AS no_of_tab_blks_read, heap_blks_hit AS no_of_buffer_blks_read, idx_blks_read AS no_of_idx_blks_read, idx_blks_hit AS no_of_buffer_idx_blks_read FROM pg_statio_all_tables WHERE relname = '<table-name>';

Lock Information

Data modification by applications or system commands locks rows and tables. Other application trying to modify the same row will get into waiting state thereby increasing the response time. Following SQL statement can be used to find out what type of locks is being held by applications on all or specific tables.

SELECT db.datname AS dbname, tbl.relname AS tblname, lck.pid, lck.locktype , mode AS lock_mode, CASE lck.granted WHEN True THEN 'lock_held' WHEN False THEN 'lock_waiting' ELSE 'not_known' END AS lock_status, lck.waitstart AS lock_wait_start_time FROM pg_database db JOIN pg_locks lck ON lck.database = db.oid JOIN pg_class tbl ON lck.relation = tbl.oid WHERE tbl.relname NOT LIKE '%pg_%' AND tbl.relname = '<tablename>';

Interpreting output: Output rows contain database name, table name, process id of the query and the following fields.

locktype - Object of the lock. E.g. table, page, row (tuple) etc.
lock_status - Whether the lock has been granted to this application or application is waiting for lock.
lock_wait_start_time - If lock waiting state, then when the wait was started.

Example Scenario: Following SQL statement takes a lock on "orders" table as it is getting executed inside of a transaction which has not been either committed or rolled back. "Lock Information" SQL can be used to find out who is holding lock on a table as shown below:

Next Step: If lock needs to be released then the application with pid 15505 must be terminated using pg_terminate_backend(15505).

Who is Holding and who is Waiting for Locks

If locks are being held long enough to block a critical application, it becomes imperative to terminate the application holding the lock. Following SQL statement provides information about applications waiting for locks and applications holding those locks so that necessary actions can be taken by DBA.

WITH lock_holder AS (SELECT db.datname AS dbname, tbl.relname AS tblname, pid, locktype , mode AS lock_mode FROM pg_database db JOIN pg_locks lck ON lck.database = db.oid JOIN pg_class tbl ON lck.relation = tbl.oid WHERE granted = true), lock_waiter AS (SELECT db.datname AS dbname, tbl.relname AS tblname, pid, locktype , mode AS lock_mode FROM pg_database db JOIN pg_locks lck ON lck.database = db.oid JOIN pg_class tbl ON lck.relation = tbl.oid) SELECT lh.pid AS pid_holding, lh.locktype AS holding_lock_type, lh.lock_mode AS holding_lock_mode, lh.tblname AS holding_lock_table, lw.pid AS pid_waiting, lw.locktype AS waiting_lock_type, lw.lock_mode AS waiting_lock_mode, lw.tblname AS waiting_lock_table FROM lock_holder lh JOIN lock_waiter lw ON lh.tblname = lw.tblname WHERE lw.tblname='<tbl-name>';

Interpreting output: This is an extension of query 11 above. Following are the output columns:

pid_holding - Application that is holding lock.
holding_lock_type - Object (table, page, row) that has been locked.
holding_lock_mode - Lock mode that is being held.
holding_lock_table - Table that is being locked.
pid_waiting - Application that is waiting for lock.
waiting_lock_type - Object (table, page, row) that is waiting for lock.
waiting_lock_mode - Lock mode that is needed.
waiting_lock_table - Lock on table that is waiting.

Example Scenario: There can be scenarios where multiple applications can take write lock on the same rows at the same time. Depending on lock_timeout, one of the applications has to wait for that duration. Criticality of an application might dictate the terms of waiting on locks and DBAs have to terminate application holding the lock. Following is an application that is updating rows in a transaction, but has not released the lock.

And following application has timed out because of lock wait.

Next Step: Using above query we can find out which application is waiting and who is holding lock on a table as shown below. Depending on priority one of the applications can be terminated by DBA.

Diagnostic Flow:

The following chart can be used to decide which admin view to use and when. It also shows how Azure Monitor and PostgreSQL admin views work in tandem at any analysis scenarios.

Summary:

PostgreSQL provides helpful administrative views that can be used by DBAs (Database Administrators) to perform initial level of analysis at engine side before looking at any infrastructure level issues. The initial analysis can be useful in relating infrastructure issues with database performance as well, if there is any.

TLS Certificate Pinning and Best Practices in Azure Database for MySQL

TameikaL — Wed, 20 May 2026 13:00:00 GMT

Transport Layer Security (TLS) encrypts data in transit between client applications and the server and authenticates the service endpoint in client-server authentication.

Azure Database for MySQL server certificates are issued by well-known trusted public Certificate Authorities (CAs), including Microsoft-issued certificates, and are validated by clients during the TLS handshake. Customers do not manage certificates on the server side.

Certificate pinning is a client-side security technique where an application restricts trust to a specific certificate, for example by thumbprint, public key, or CA, rather than relying solely on the default OS or platform trust store. The trust store contains pre-installed root CAs and may also include additional certificates configured by the client. During standard TLS validation, the client will trust any server certificate that chains to one of those root CAs.

Why detecting TLS certificate pinning is not possible by design

Certificate pinning is entirely client-side logic. The server has no visibility into whether pinning is configured on the client. From the server’s perspective, the client either completes the TLS handshake or aborts it. The server never sees:

Which certificate(s) the client trusts
Whether the client is comparing root CA, intermediate CA, leaf certificate or SPKI hash
Whether the trust decision was static or dynamic

What the server can see is TLS handshake failure patterns, TLS protocol, and cipher negotiation.

Why certificate pinning is risky

While certificate pinning was historically used to reduce the risk of man-in-the-middle attacks, it introduces significant operational fragility in cloud environments, particularly during certificate rotations.

Server certificates and certificate authorities (CAs) must be rotated periodically to maintain security and compliance. In Azure Database for MySQL, when certificate pinning is used, clients bind trust to a specific certificate or CA. As a result, any change to the server certificate chain — including CA updates — can cause connection failures, even when the new certificates are fully valid and secure.

One of the most common complications during certificate rotations is certificate pinning.

Recommended TLS certificate trust model for Azure Database for MySQL

Instead of pinning, adopt a CA‑based trust model that allows certificates to change safely.

Trust root CAs, not individual certificates.

Configure clients to use standard TLS validation against Azure-documented root CAs, rather than restricting trust to specific certificates or a narrowly scoped set of certificate authorities. Avoid configurations that effectively implement certificate pinning—such as trusting only a single certificate, public key, or limited CA set—unless explicitly required.

Maintain a flexible and up-to-date trust store

Clients rely on a trust store, key store, or equivalent certificate bundle to validate server certificates during TLS negotiation.

Include the appropriate root and intermediate certificate authorities (CAs) required to validate the server certificate chain
Ensure that trust stores are periodically reviewed and updated in line with provider guidance and announced certificate authority changes.

For the current TLS certificates visit the Azure Database for MySQL documentation.

Use certificate validation modes that rely on standard CA-based trust rather than pinning

For MySQL client configurations, prefer:

ssl-mode=VERIFY_CA
- Validates the server certificate chain against trusted CAs
ssl-mode=VERIFY_IDENTITY
- Validates CA and hostname (like PostgreSQL verify-full)

These modes ensure that clients validate the server certificate chain against trusted CAs, and in stricter modes, verify hostname identity. They do not imply certificate pinning by themselves. They rely on standard CA-based trust.

Configurations only become rigid when trust is narrowly restricted, such as to a single certificate or limited CA set, often through custom or overly constrained trust stores. This effectively introduces certificate pinning.

When properly configured, these modes authenticate the service endpoint and protect against spoofing, while remaining resilient to certificate rotations.

Maintain a combined CA during certificate rotations

Azure may rotate root or intermediate CAs over time. When Azure announces a CA rotation:

Add the new root and intermediate CAs to the client trust store before the rotation begins
Retain existing root or intermediate CAs until the transition is fully complete
Avoid removing older certificates prematurely

This combined CA approach, using both the current and upcoming certificate authorities during the transition window, allows clients to continue validating the server certificate chain without interruption.

As you review your current client configurations, ensure your applications rely on CA-based trust, avoid overly restrictive certificate configurations such as certificate pinning, and are prepared to handle routine certificate rotations without disruption.

For a deeper dive, see the full article: TLS Certificate Pinning in PostgreSQL and MySQL: Risks, Rotations, and Best Practices.

Stay Connected

We welcome your feedback and invite you to share your experiences or suggestions at AskAzureDBforMySQL@service.microsoft.com

Thank you for choosing Azure Database for MySQL!

Know before you go: Azure Managed Redis at Microsoft Build 2026

Matthew_Burrows — Fri, 29 May 2026 19:49:14 GMT

Microsoft Build 2026 is almost here, and this year’s event boasts a new format, as well as a deeper technical focus across key themes such as AI agents, cloud-native applications, data platforms, developer tooling, and intelligent infrastructure. The updates showcased at Build signal where Microsoft is investing next—and how customers can start preparing now.

Whether you’re joining in person or online, this is your opportunity to see how Azure is shaping the next generation of AI-powered applications—and where Azure Managed Redis fits into that future.

In this post, we’ll cover everything you need to know to prepare, including what Build is (and how to participate), as well as where you can find Azure Managed Redis across sessions, demos, and the in-person expo experience.

Where to find Azure Managed Redis at Build

Azure Managed Redis’s presence at Build 2026 spans a mix of on-demand digital and in-person experiences, ranging from technical deep dives to open ended developer conversations. No matter your stage of development, Microsoft has you covered.

Lightning talk

Stop by our lightning talk for fast, focused 15-minute sessions designed to give you an early look at what’s new. These in-person discussions spotlight emerging capabilities and real-world scenarios, offering a quick way to understand where the platform is evolving next.

LTG41 | Faster and smarter agents with Redis and Foundry
📅 Wednesday, June 3
🕛 4:20 PM – 4:35 PM PDT

The Azure Managed Redis Lightning Talk will focus on:

How Azure Managed Redis and Microsoft Foundry help developers build more effective AI agents
High-performance in-memory data patterns for powering agent memory and context
Vector search and semantic caching to reduce latency, lower cost, and return more relevant responses
Practical approaches for RAG, persistent memory, and event-driven agent workflows

This session is ideal for anyone looking to understand how Redis can serve as the data and memory layer for production-ready AI agents—helping deliver the right context in milliseconds and enabling richer, real-time reasoning.

Expect to see a preview of upcoming investments across performance, developer experience, and AI-powered workflows. These sessions are ideal if you want a concise view of what’s changing and what it enables—before diving deeper into the full roadmap.

➡️ Tip: Lightning talks are in-person only and not available on demand—plan to attend live.

On-demand session

If you prefer to explore at your own pace, our on-demand sessions provide deeper walkthroughs of key updates and product capabilities. You’ll find detailed demos, scenario-based guidance, and technical insights that help you translate new features into real-world value.

OD823 | Faster AI Responses with Semantic Caching in Azure Managed Redis on-demand session will cover:

Building AI agents with Azure Managed Redis and Microsoft Foundry
Real-time memory and context for agent workflows
Vector search, semantic caching, and agent memory

This session is ideal for:

Developers building copilots or autonomous agents
Architects designing large scale LLM chatbots
Teams modernizing applications for AI

➡️ Tip: Sessions are designed to help you move from awareness to action, with a clearer understanding of how to apply what’s coming next. On-demand session will be available on Build Day 1, so keep an eye out for our Azure Managed Redis Build 2026 announcements blog for the on-demand session link and access details.

Booth and expo presence

Visit us on-site to connect directly with product experts, see live demos, and explore real customer scenarios in action. Build’s interactive spaces are designed for hands-on engagement, giving you the opportunity to ask questions, test capabilities, and get guidance tailored to your environment.

Azure Managed Redis will be represented within a shared Azure Data / NoSQL booth experience, showcasing:

Real-time AI application scenarios
Vector search and semantic caching demos
Integration with Azure AI Foundry and agent frameworks

At the booth, you’ll get an early look at upcoming enhancements and how they fit into the broader Azure ecosystem. From performance improvements to new integrations and AI-driven experiences, you’ll leave with a clearer picture of how the product is evolving—and how to take advantage of it.

➡️ Tip: Expect a cross-product narrative aligned with Azure Data + AI platform positioning.

What to expect at Build 2026

Microsoft Build 2026 is the company’s flagship developer conference, bringing together engineers, architects, and technical leaders for two days of hands-on sessions, product announcements, and deep technical engagement.

This year’s event is focused on real code, real systems, and practical AI development, with a strong emphasis on how developers can build, deploy, and scale intelligent applications using Azure and the broader Microsoft platform.

Across keynotes, breakout sessions, demos, and labs, attendees will get early access to the next wave of platform capabilities—from advancements in AI agents and model deployment to updates across cloud infrastructure and developer tooling.

How to prepare

Register for Microsoft Build 2026
Browse the Session Catalog and start building your agenda
Bookmark the Azure Managed Redis Lightning Talk (LTG41)
Attend the Microsoft Build opening keynote to hear from CEO Satya Nadella and Microsoft leaders on how Microsoft is creating new opportunities for developers across its platforms in the era of AI
Stay tuned for the On-Demand Session Catalog going live on Build Day 1, where you can explore Azure Data & AI sessions focused on AI agents, data platforms, and intelligent applications
Visit the Expert Meetup area to connect with Microsoft engineers and product teams
Follow along with Azure Managed Redis on Microsoft Tech Community, as well as Microsoft social channels (LinkedIn, X) for additional key announcements and real-time updates

We look forward to meeting you there!

Ultimate Guide to POSETTE: An Event for Postgres, 2026 edition

clairegiordano — Mon, 18 May 2026 08:20:26 GMT

POSETTE: An Event for Postgres 2026 is back for its 5th year: free, virtual, and unapologetically all about Postgres. No travel budget required and no jet lag involved. Just your laptop, a decent internet connection, and curiosity.

This year the POSETTE 2026 schedule has 4 livestreams (16-18 June) with 44 talks at ~25 minutes each—covering everything from query performance and partitioning to Postgres 19 features, extensions, and use cases. Which is awesome but also a bit of work to figure out which talks are for you. Hence this ultimate guide post. Every talk will land on YouTube afterward (un-gated, of course) so if you miss anything you care about, you can watch it later.

But if you can catch a livestream in June, do it. That’s when the “virtual hallway track” happens on Discord—where you can ask the POSETTE speakers questions and compare notes with other attendees. Meeting other attendees who have the same weird Postgres problems you do can be reassuring somehow. And yes, there will be swag.

This guide is your cheat sheet: I’ve categorized and tagged all 44 talks so you don’t have to read 44 abstracts back-to-back. In this post you'll get:

“By the numbers” summary
Map of the 44 talks
2 Keynote sessions
23 Postgres core talks
11 Postgres ecosystem talks
8 Azure Database talks
Why participate on the virtual hallway track on Discord
A big thank you to our amazing speakers
Join us for POSETTE 2026 & mark your calendars
Official POSETTE 2026 Trailer

“By the numbers” summary for POSETTE 2026

Here’s a quick snapshot of what you need to know about POSETTE this year:

3 days	16-18 June 2026
4 livestreams	In Americas & EMEA time zones but of course you can watch from anywhere
44 talks	All free, all virtual
2 invited keynotes	Driving Postgres forward at Microsoft (Livestream 1), and Postgres 19 Hackers Panel: What’s In, What’s Out, & What’s Next (Livestream 2)
25 minutes	Average length per talk
~1100 minutes	Total minutes in POSETTE 2026 talks
50 speakers	POSETTE 2026 speakers include PostgreSQL hackers and contributors, users, application developers, PG community members, Azure engineers, & Azure customers
6 keynote speakers	Affan Dar & Charles Feddersen (Livestream 1); and Álvaro Herrera, Heikki Linnakangas, Melanie Plageman, & Thomas Munro (Livestream 2)
19 countries	Speakers reside in 19 different countries
23 companies	Speakers hail from 23 different companies
17.6% CFP acceptance rate	42 talks selected from 238 submisssions
75% general Postgres talks	33 talks are not cloud-specific at all, they’re about the Postgres technology & ecosystem
25% Azure-related talks	11 of 44 talks feature Azure Database for PostgreSQL or Azure HorizonDB
1 organizing company	Organized by the Postgres team at Microsoft, in partnership with AMD
17 languages	Published talk videos will have captions available in 17 languages, including English, Czech, Dutch, French, German, Hindi, Italian, Japanese, Korean, Polish, Portuguese, Russian, Spanish, Turkish, Ukrainian, and Chinese Simplified & Chinese Traditional

Map of the 44 talks

To help you quickly navigate all 44 talks, here’s a map of the high-level categories and detailed topics.

Figure 1: A map of the POSETTE 2026 talks—high-level categories and detailed tags to help you find what you care about

2 Keynote sessions

Affan Dar and Charles Feddersen lead the PostgreSQL engineering and product teams at Microsoft, In this keynote, they’ll walk through how Microsoft is contributing to Postgres, both upstream in the open source project and in the cloud database service they build on top of it.

Driving Postgres forward at Microsoft, by Affan Dar & Charles Feddersen (Azure Database for PostgreSQL, Azure HorizonDB, VS Code, Dev tools, community, Postgres hacking, open source, PosetteConf, livestream-1)

Want to understand how Postgres features get decided? This keynote panel with 4 PostgreSQL committers & hackers will peel back the curtain. You’ll hear what made it into Postgres 19, what didn’t (and why), and get a sneak peek into a few of the things in the oven for Postgres 20.

Postgres 19 Hackers Panel: What’s In, What’s Out, & What’s Next, by Álvaro Herrera, Heikki Linnakangas, Melanie Plageman, & Thomas Munro (Postgres 19, Postgres hacking, panel, open source, collaboration, multithreading, livestream-2)

23 Postgres core talks

Data Modeling

JSON in PostgreSQL - evil data type or just needs to be tamed?, by Boriss Mejias (JSON, performance, data modeling, livestream-1)
PostgreSQL Design Patterns, by Chris Ellis (data modeling, SQL, PG use cases, livestream-1)

Graph Data

Exploring property graphs with SQL/PGQ in PostgreSQL, by Ashutosh Bapat (SQL/PGQ, graph data, data modeling, Postgres 19, livestream-4)

LISTEN/NOTIFY

LISTEN Carefully: How NOTIFY Can Trip Up Your Database, by Jimmy Angelakos (LISTEN/NOTIFY, PG use cases, triggers, livestream-4)

Performance

Maintaining Large Tables in PostgreSQL, by Sarat Balijepalli (WAL, performance, scaling Postgres, vacuum, autovacuum, statistics, partitioning, monitoring, livestream-3)
My Postgres partitioning cookbook, by Derk van Veen (partitioning, PG use cases, data modeling, performance, livestream-4)
PostgreSQL 17 vs 18: Side‑by‑Side Performance Wins in Real‑World Queries, by Divya Bhargov (performance, PG use cases, livestream-3)
Vacuuming Enhancements in PostgreSQL 18: Faster, Smarter, More Predictable, by Shashikant Shakya (vacuum, async IO, monitoring, performance, livestream-4)

PG Internals

Linux and PostgreSQL in the Multiverse of Connections, by Josef Machytka (Linux, PG internals, connection pooling, livestream-2)
pg_stats: How Postgres Internal Stats Work, by Richard Yen (statistics, pg_stats, PG internals, query planner, livestream-2)
Postgres isn’t slow, your storage is, by Sai Srirampur (storage, IO, performance, livestream-3)
PostgreSQL queues done right with PgQ, by Alexander Kukushkin (queues, PG internals, extensions, livestream-2)
random_page_cost in Postgres - why the default is 4.0 and should you lower it?, by Tomas Vondra (PG internals, IO, performance, livestream-1)
The Wonderful World of WAL, by Bruce Momjian (WAL, PG internals, replication, livestream-3)
What's new with constraints in Postgres 18, by Gülçin Yıldırım Jelínek (constraints, data modeling, livestream-2)

Postgres Hacking

Fuzzing PostgreSQL, by Adam Wolk (PG internals, testing, Dev tools, libpq, security, livestream-1)
Journey of developing a performance optimization feature in PostgreSQL, by Rahila Syed (Postgres hacking, PG internals, performance, WAL, replication, livestream-4)
The Hitchhiker’s Guide to PostgreSQL Hacking: Don’t Panic, Just Start Small, by Xuneng Zhou (Postgres hacking, PG internals, community, livestream-2)

Replication

Past, Present, and Future: Logical Decoding and Replication in PostgreSQL, by Hari Kiran (replication, logical decoding, PG internals, livestream-4)
Where Does My INSERT Go? A Logical Replication Story, by Hamid Akhtar (replication, PG internals, WAL, livestream-4)

Security

From Dev to Prod: Securing Postgres the Right Way, by Sakshi Nasha (security, roles, PG use cases, extensions, monitoring, livestream-4)
From trust to Tokens: A Short History of PostgreSQL Authentication, by Murat Tuncer (authentication, security, livestream-2)
PostgreSQL vs. SQL Server: Security Model Differences, by Taiob Ali (security, authentication, SQL Server, roles, livestream-1)

11 Postgres ecosystem talks

Analytics

pg_lake: Postgres as a lakehouse, by Marco Slot (pg_lake, extensions, OLAP, data warehouse, Iceberg, DuckDB, analytics, livestream-2)

Apache AGE

Querying & Visualizing Graphs in Postgres with Apache AGE, by Christian Miles (Apache AGE, graph data, data visualization, SQL/PGQ, Azure HorizonDB, livestream-1)

Autotuning

Building safety tooling for risk-free AI tuning of Postgres: Fast cars need fast brakes, by Mohsin Ejaz (autotuning, AI, performance, monitoring, livestream-2)

Change Data Capture

Building Event-Driven Systems with PostgreSQL Logical Replication and Drasi, by Diaa Radwan (Drasi, replication, WAL, CDC, livestream-3)

Citus

Move Less, Move Faster: Speeding Up Citus Cluster Scaling, by Muhammad Usama (Citus, extensions, performance, scaling Postgres, livestream-4)

Dev Tools

An MCP for your Postgres DB, by Pamela Fox (MCP, AI, Python, Dev tools, livestream-1)
pgcov: Bringing Real Test Coverage to PostgreSQL Code, by Pavlo Golub (testing, Postgres hacking, Dev tools, extensions, CI/CD, livestream-3)
PostgreSQL Tooling Across AI Editors and Agents, by Matt McFarland (Dev tools, VS Code, Cursor, AI, data visualization, Apache AGE, graph data, Azure, MCP, Copilot, livestream-1)

Django

PostgreSQL Generated Columns by Example, by Paolo Melchiorre (app dev, Django, generated columns, livestream-2)

Kubernetes

Quorum-Based Consistency for Cluster Changes with CloudNativePG Operator, by Jeremy Schneider & Leonardo Cecchi (CloudNativePG, Kubernetes, PG use cases, livestream-3)

Performance

Modelling Postgres Performance Degradation on Burstable Cloud Instances, by Chun Lin Goh (performance, burstable, compute, QA, livestream-4)

8 Azure Database for PostgreSQL & Azure HorizonDB talks

AI-related talks

From Queries to Agents: The Next Era of Data Retrieval on PostgreSQL, by Abe Omorogbe (AI, MCP, Azure Database for PostgreSQL, graph data, Apache AGE, Azure HorizonDB, livestream-3)
Production RAG at Scale with Azure Database for PostgreSQL, by Julia Schröder Langhaeuser & Paula Santamaría (Azure Database for PostgreSQL, AI, RAG, PG use cases, livestream-3)

AMD

Choose the Right Azure Infrastructure to Improve Postgres Performance by Over 60%, by Andrew Ruffin (AMD, performance, Azure, compute, Azure Database for PostgreSQL, livestream-1)

Azure HorizonDB

Why we built Azure HorizonDB for PostgreSQL, by Dingding Lu (Azure HorizonDB, scaling Postgres, livestream-3)

Flexible Server

pg_duckdb in Action: Accelerating Analytics on Azure Database for PostgreSQL, by Nitin Jadhav (DuckDB, Azure Database for PostgreSQL, extensions, OLAP, analytics, performance, livestream-4)
The Rise of PostgreSQL as the Everything Database, by Varun Dhawan (Postgres history, extensions, graph data, Apache AGE, Azure Database for PostgreSQL, DuckDB, Citus, livestream-3)
What I’ve Learned Teaching Postgres to 200+ field engineers at Microsoft, by Paula Berenguel (training, Azure, Postgres skilling, livestream-1)

Oracle to Postgres

Migrating VLDBs from Oracle to Azure Database for PostgreSQL, by Adithya Kumaranchath (migration, Azure Database for PostgreSQL, Oracle to Postgres, livestream-2)

Why participate in the virtual hallway track on Discord

If you’ve checked out the schedule and plan to watch some of the talks, you might still be wondering: why join live—and why bother with the virtual hallway track on Discord?

Here’s how a few of last year’s attendees described the experience:

“Very impressed by all the speakers and content I am absolutely shattered as there was so much great content in all the talks over the past 3 days but I have probably learnt more in these sessions than I could have in months of reading up.”

“Want to let y’all know how much I got from this onine conference, the speakers were excellent, well-prepared and well-presented. The hosts were informative, engaging, & amusing. The discord hallway channel made me feel connected. I learned a lot and found some new inspiration. I’ll be back next year!”

“I have no idea how I’m going to summarise all the interesting stuff for coworkers.”

The common thread: the live, shared experience—being able to ask questions, compare notes, and learn alongside other people in real time.

How to join the virtual hallway track

Head to the #posetteconf channel on Discord (on the Microsoft Open Source Discord)
That’s where speakers and attendees hang out during the livestreams—it’s where you can ask questions, share reactions, and just say hi

Big thank you to our amazing speakers

Every great event starts with great talks—and great talks start with great speakers. Want to learn more about the people behind these talks?

Visit the POSETTE 2026 Speaker page
Click a speaker’s bio to see their written interview (if available)
If a speaker has been a guest on the Talking Postgres podcast in the past, then you’ll find a link to their episode there, too

Figure 2: Bio pics for all speakers in POSETTE: An Event for Postgres 2026, along with our gratitude

Join us for POSETTE 2026! Mark your calendars

I hope you join us for POSETTE 2026. Consider yourself officially invited. As part of the talk selection team, I’m definitely biased—but I truly believe these speakers and talks are worth your time. I’ll be hosting Livestream 1 and you’ll find me in the #posetteconf Discord chat. I hope to see you there.

And please: tell your Postgres friends, so they don’t miss out!

🗓️ Add the livestreams to your calendar

Livestream 1: Tue 16 June, 8am–2pm PDT (UTC-7)
[ register for updates ] and/or [ add to calendar ]
Livestream 2: Wed 17 June, 8am–2pm CEST (UTC+2)
[ register for updates ] and/or [ add to calendar ]
Livestream 3: Wed 17 June, 8am–2pm PDT (UTC-7)
[ register for updates ] and/or [ add to calendar ]
Livestream 4: Thu 18 June, 8am–2pm CEST (UTC+2)
[ register for updates ] and/or [ add to calendar ]

Watch last year’s POSETTE 2025 talks in advance: And if you want to get ready, you can watch talks from the POSETTE 2025 playlist on YouTube anytime, anywhere. Lots of solid, useful, and evergreen Postgres talks in there.

“Official Trailer” for POSETTE 2026 is on YouTube

To help more developers, community members, and Postgres users discover POSETTE 2026, our team created this short video trailer. Take a peek and share it with friends as an invitation of sorts.

We’re trying to make sure that people don’t miss their opportunity to be part of the livestreams and ask questions on the discord during the conference (as well as watch the talks on YouTube after the event is over.)

Watch and share the trailer: Official Trailer for POSETTE: An Event for Postgres 2026

Acknowledgements & Gratitude

I’ve already thanked the 50 amazing speakers above. In addition, thanks go to Silvano Coriani, Cornelia Biacsics, Aaron Wislang, and My Nguyen for reviewing parts of this post before publication.

I also want to thank the team at AMD for their partnership and support of POSETTE this year! And of course, big thank you to the POSETTE 2026 organizing team and POSETTE talk selection team—without you, there would be no POSETTE!

Figure 3: Visual invitation to join the virtual hallway track for POSETTE 2026 on the Microsoft Open Source Discord, so you can chat with the speakers & others in the Postgres community

Azure ADF boolean parameter changes from true to True and false to False

jgollner — Fri, 15 May 2026 01:15:17 GMT

I just created a new trigger in Azure ADF.
I seems the boolean parameter in the trigger is converted from lowercase to be capitalised.
Is anybody experiencing the same thing?

Automatic Connectivity Tests for Azure SQL Managed Instance

ZoranRilak — Thu, 14 May 2026 15:56:24 GMT

To further enhance connectivity monitoring and improve service reliability, we’re introducing automatic internal connectivity tests for all Azure SQL Managed Instances. These tests are fully automated and require no action from you. Beginning May 2026, the tests will be continuously performed at regular intervals on all managed instances. By proactively monitoring internal network connections, we’re able to quickly identify potential issues and maintain stable end-to-end connectivity.

These tests are performed from a pair of internal IP addresses from the subnet range that hosts the managed instance, so they do not require any external inbound or outbound connectivity. Please note that additional IP addresses will be reserved for these tests and that tests may leave traces in your observability logs.

Automatic tests diagnose issues in internal service and network availability. This results in accelerated issue discovery and shorter time to mitigate incidents that involve degraded connectivity of managed instances’ internal networking components. This suite of connectivity tests examines internal network connections at several levels, boosting the supportability and visibility into the service’s internal state and offering you peace of mind regarding your managed instances.

Do note that your audit and security systems, if configured to track certain types of events emitted by SQL Server, may record failed login attempts. Those are normal and expected byproducts of the end-to-end connectivity test suite. If you would prefer to not have those events register in your SQL Server audit logs, SQL error logs, or captured Extended Events, we provide you with their event signatures so you can set up event filters or configure your SIEM system to ignore them: Observing failed logins caused by end-to-end tests.

You can read more about the automated connectivity tests at Automatic internal connectivity tests for Azure SQL Managed Instance.

April 2026 Recap: Azure Database for PostgreSQL

gauri-kasar — Thu, 14 May 2026 17:27:45 GMT

April brought several updates for Azure Database for PostgreSQL, focused on improving developer productivity, strengthening security and connectivity, and helping customers scale and optimize their PostgreSQL workloads. From new Entra ID token refresh libraries across .NET, JavaScript, and Python to simplify authentication, to guidance on migrating from VNet to Private Endpoint capable configurations, we continue to make it easier to build and manage secure applications. We also introduced enhancements to the PostgreSQL VS Code extension and published deep dives on query performance, data modeling, and real-world scaling patterns.

We also published a blog on how PostgreSQL enters its AI era, which explores ways with which developers can adapt PostgreSQL to meet the needs of AI-driven and rapidly growing applications, with practical guidance on running and scaling PostgreSQL more effectively in these evolving workloads.

POSETTE 2026

Before we dive deeper into the feature updates, POSETTE: An Event for Postgres 2026 is just around the corner, PostgreSQL’s free, virtual conference bringing together the global community. Taking place from June 16–18, the event will feature four livestream tracks with a strong lineup of content, including 44 sessions, 2 keynotes, and 50 speakers. It’s a great opportunity to hear from PostgreSQL experts, learn about the latest trends, and discover real-world best practices across a wide range of topics.

Register today for updates and be part of three days of learning, insights, and community-driven discussions across a wide range of PostgreSQL topics.

Features

Entra-ID token refresh libraries for .NET, JavaScript, and Python: Preview
Migrating from VNet to Private Endpoint: Preview
New enhancements in the PostgreSQL VS Code Extension
Improving Query Performance and Modeling in PostgreSQL
Scaling PostgreSQL for Real-World Application Workloads

Learning Bytes: Preventing accidental server deletion

Entra-ID Token refresh libraries: .NET, JavaScript and Python

We’ve introduced Entra ID token refresh libraries for .NET, JavaScript, and Python to simplify how applications authenticate with Azure Database for PostgreSQL using Entra ID. When using Entra ID–based authentication, access tokens are short-lived and need to be refreshed periodically. This often requires additional logic in the application to handle expiration, retries, and reconnection scenarios. These new libraries take care of that complexity by automatically refreshing tokens behind the scenes, so applications can maintain uninterrupted database connections without custom token management.

With built-in support for token renewal, these libraries help:

Reduce the need for manual token refresh logic in your application code
Improve reliability for long-running or connection-pooled workloads
Simplify adoption of Entra ID authentication across different language stacks

Whether you're building new applications or migrating existing ones to use Entra ID, these libraries make it easier to integrate secure, passwordless authentication while keeping connection handling straightforward.

Migrating from VNet to Private Endpoint

Azure Database for PostgreSQL flexible server can now be migrated from a VNet‑integrated deployment to a network configuration that supports Private Endpoint connectivity. Servers originally deployed inside a VNet may require greater flexibility in networking management. Private Endpoints provide a simpler and more scalable model. Following migration, private access to the server continues over Azure’s backbone network, dependency on delegated subnets is reduced, and database networking can be better aligned with evolving architectural or organizational standards.

The migration can be initiated through Azure CLI, API, or SDK and is designed to be straightforward. Although the operation involves a period of downtime, it enables adoption of Private Endpoint connectivity without recreating the server or manually moving data. After migration, Private Endpoints or firewall rules can be configured based on the desired access model, and infrastructure-as-code templates can be updated accordingly.

New enhancements in the PostgreSQL VS Code Extension

The latest release (v1.21) of the PostgreSQL VS Code extension delivers enhancements to query authoring and analysis workflows, improved cross-extension interoperability, reliability improvements across Object Explorer and connection management, and a set of targeted bug fixes.

Schema-Aware Query Creation: You can now open a new query directly from a schema in Object Explorer, automatically setting the appropriate search_path so unqualified object names resolve correctly without additional setup.
Query Plan Visualization Enhancements: The query plan visualizer now uses PostgreSQL-specific node icons across all views, making it easier to identify scan, join, and aggregate operations during performance analysis.
Improved Multi-Extension Compatibility: The extension now coordinates editor ownership with the MSSQL extension when both are installed, reducing duplicate UI actions and avoiding conflicts in query execution workflows.
Object Explorer Reliability Improvements: The Object Explorer has been refactored for more consistent refresh, expansion, and reconnection behavior, especially in long-running sessions and databases with many schemas.
Enhanced IntelliSense Behavior: IntelliSense now respects the configured search_path, improving the relevance of suggestions and helping you work more efficiently across schemas.
Bug Fixes: This release includes fixes across object scripting (including partitioned tables), connection profile handling, Docker container creation, and initial extension setup for improved reliability and stability.

Improving Query Performance and Modeling in PostgreSQL

This month, we also shared a set of technical blogs highlighting advanced PostgreSQL scenarios and practical guidance for real-world workloads:

Guide on workload observability with Query store: This blog dives into how Query Store can be used to gain end-to-end visibility into query performance across both primary and replica nodes. It highlights the importance of understanding query behavior in distributed setups and how bottlenecks can surface differently across nodes. The post also shares practical guidance on using these insights to troubleshoot issues and optimize workload performance effectively.
Guide on Common Table Expressions(CTEs) with Data Skew: This deep dive unpacks a complex query planning scenario in PostgreSQL v17, where data skew can lead to unexpected and suboptimal execution plans involving CTEs. It explains why the optimizer may choose inefficient plans and how this impacts real-world workloads. The blog also outlines strategies to diagnose and mitigate these issues, helping users better predict and tune query performance.
Guide on PostgreSQL as a Graph Database: This blog explains how PostgreSQL can be leveraged to model and query graph-like relationships, making it highly relevant for AI-driven applications. It demonstrates how relational capabilities can be extended to support graph workloads without introducing additional systems. The post also highlights practical patterns and use cases that enable developers to build more connected, intelligent applications using PostgreSQL as a unified data platform.

Scaling PostgreSQL for Real-World Application Workloads

Alongside performance tuning and data modeling topics, we also explored how PostgreSQL behaves under real-world application patterns especially in scenarios involving high concurrency, background job processing, and connection-heavy workloads. These blogs focus on common architectural choices developers make and the trade-offs to consider when scaling reliably.

Guide on using Postgres as a Job Queue: Thisblog takes a deeper look at the implications of using PostgreSQL as a job queue, a pattern commonly adopted for simplicity and tighter integration. It walks through how queue-like workloads can introduce contention due to frequent updates, row locking, and long-running transactions. The post highlights how these patterns can impact throughput, vacuum efficiency, and overall database health as scale increases. It also discusses when this approach is appropriate, and when teams should consider dedicated queuing systems to avoid performance bottlenecks.

Guide on Connection Scaling with Elastic Clusters: This blog dives into the challenges of handling large volumes of concurrent connections, which is a common bottleneck for modern, microservices-based applications. It explains how Elastic Clusters help distribute connections and workload across multiple nodes, improving scalability and resilience under heavy load. The post also touches on connection management patterns, including pooling strategies, and how they work in conjunction with Elastic Clusters to prevent resource exhaustion and ensure consistent performance at scale.

Azure Postgres Learning Bytes 🎓

Preventing accidental server deletion

In production environments, accidental deletions can lead to significant downtime and data loss. To safeguard critical resources like Azure Database for PostgreSQL servers, Azure provides resource locks that add an extra layer of protection beyond standard role-based access control (RBAC). A commonly used option is the CanNotDelete (Delete Lock), which ensures that a resource cannot be deleted even by users with elevated permissions until the lock is explicitly removed.

You can apply a delete lock easily using the Azure CLI by targeting the specific resource:

az lock create --name PreventDelete --lock-type CanNotDelete --resource-group <rg-name> --resource-type Microsoft.DBforPostgreSQL/flexibleServers --resource-name <resource-name></resource-name></rg-name>

Once applied, any delete operation on the resource will be blocked, helping prevent accidental or unintended deletions during maintenance, deployments, or testing. Locks can be applied at different levels subscription, resource group, or individual resources allowing flexibility based on your protection needs.

For more details and step-by-step guidance, read our blog on Preventing accidental deletion of an Azure PostgreSQL Instance.

Unexpected PITR Charges from restorableDroppedDatabases After BC → Hyperscale Migration

Mohamed_Baioumy_MSFT — Thu, 14 May 2026 14:01:54 GMT

Why This Behavior Is by Design

When migrating an Azure SQL Database from Business Critical (BC) to Hyperscale using a manual cutover, some customers notice unexpected Point-in-Time Restore (PITR) backup storage charges appearing under the following resource:

/Microsoft.Sql/servers/<server>/restorableDroppedDatabases/<database>

At first glance, this can be confusing—especially when:

No customer-initiated drop or delete was performed
The database is online and healthy post-migration
Test migrations may not have shown similar charges

This post explains why this happens, why it is expected by design, and how these charges naturally expire.

The Observed Scenario

After a BC → Hyperscale manual cutover, customers may see PITR charges tied to:

restorableDroppedDatabases/<database-name>

Despite the database being active and available in Hyperscale, these charges start appearing immediately after the migration cutover and gradually decrease over time.

Why Does the Database Appear as “Dropped”?

During a manual cutover migration, Azure SQL performs an internal platform-driven workflow to complete the transition between architectures.

From a control-plane perspective:

The source Business Critical logical database is internally dropped
This drop is not initiated by the customer
It is a required system step to complete the Hyperscale migration

Telemetry confirms that the migration workflow transitions through states such as:

Internal drop of the source physical and logical database
Cleanup of metadata and completion of the migration

This entire sequence completes within seconds and is fully platform managed.

Why Are Backup Charges Generated?

Although the source BC database is internally dropped, its pre-migration PITR backups are still retained according to the configured backup retention period.

Here’s the key point:

Backups taken before upgrading to Hyperscale are retained and billed using the dropped-database backup billing model.

Because the source database is now considered dropped (from the BC perspective):

The 1× database-size discount no longer applies
The full data file size is added to the billable backup size
Charges appear under restorableDroppedDatabases

This behavior is explicitly documented as expected in internal Azure SQL billing guidance.

Why Do Charges Decrease Over Time?

These charges are not permanent.

They:

Decrease daily
Continue only while the pre-migration PITR backups are retained
Automatically stop once the retention window expires

In practical terms:

Charges stop when: days_since_migration > configured_backup_retention_days

No cleanup action is required from the customer—the platform handles this automatically.

Why Didn’t Test Migrations Show Similar Charges?

In many reported cases, test or smaller databases migrated using the same method did not generate noticeable charges.

This can be explained by two documented optimizations:

Backup size threshold – very small backup footprints are not charged
Low activity optimization – inactive or low-change databases generate fewer snapshots

As a result, smaller or lightly used test databases may fall below the billing threshold, while larger production databases do not.

Is This a Billing Error or Credit Scenario?

No.

Although the operation is platform-driven:

The behavior is by design
The charges are for temporary retention of valid PITR backups
They naturally expire based on retention

Therefore, this scenario is not considered a billing defect and does not typically warrant credits.

How Can Customers Reduce Charges Faster?

If needed, customers can:

Reduce the PITR backup retention period (minimum is 1 day)
Wait up to 24 hours for billing to reflect the change

This shortens how long the pre-migration backups are retained and billed.

FAQ – restorableDroppedDatabases Charges After BC → Hyperscale Migration

Q1: Why am I seeing PITR charges for restorableDroppedDatabases when my database is still online?

A: During a Business Critical → Hyperscale manual cutover, Azure SQL internally drops the source BC database as part of the migration workflow. While the Hyperscale database is active and healthy, the pre‑migration BC backups are retained and billed under restorableDroppedDatabases.

Q2: Did the customer initiate a drop or delete operation?

A: No. This drop is platform‑driven and required to complete the migration. It is not initiated by the customer.

Q3: What exactly is being billed?

A: The charges are for Point‑in‑Time Restore (PITR) backups taken before the migration. These backups are retained according to the configured backup retention period and are billed using the dropped database billing model.

Q4: Why does the cost appear higher than expected?

A: Once a database is considered “dropped” (from the BC perspective), the 1× database-size discount no longer applies, and the full data file size is included in the billable backup size.

Q5: Will these charges continue indefinitely?

A: No. The charges decrease daily and automatically stop once the pre‑migration backups expire based on the configured PITR retention period.

Q6: Why didn’t this happen with smaller or test databases?

A: Smaller or low‑activity databases may fall below the backup billing threshold, or benefit from low‑activity snapshot optimizations, resulting in no visible charges.

Q7: Is this a billing bug or credit-worthy scenario?

A: No. This behavior is by design and expected. The charges reflect valid backup retention and do not typically qualify for credits.

Q8: Can the customer reduce these charges sooner?

A: Yes. The customer can reduce the PITR backup retention period (minimum 1 day). Billing changes usually reflect within up to 24 hours.

Key Takeaways

The behavior is expected and by design
Charges come from pre-migration BC backups, not the active Hyperscale database
The database was internally dropped as part of migration, not by the customer
Charges decrease daily and stop automatically
No action is required unless the customer wants to reduce retention early

Final Note

As of the time of writing, this behavior is not clearly described in public customer-facing documentation, which explains why it often appears unexpected. Awareness of this mechanism can help set correct expectations when planning BC → Hyperscale manual cutover migrations.

Zero downtime migration from Oracle to Azure DB for PostgreSQL

Matthew_Burrows — Wed, 13 May 2026 16:00:00 GMT

Co-authored by:
Maxim Lukiyanov, Principal PM Manager, Postgres on Azure, Microsoft

Edward Bell, Senior Director, Global Technical Alliances & Solutions, Striim

Matthew Burrows, Director, Databases Migration and Modernizations, Microsoft

For organizations modernizing mission-critical applications, moving Oracle workloads to Microsoft Azure is a pivotal step toward realizing the benefits of a fully managed, cloud-native data architecture. Azure Database for PostgreSQL offers built-in high availability, elastic scale, enterprise security, and integration across Azure’s analytics and AI ecosystem—all without the operational overhead of managing legacy infrastructure.

The challenge many teams face is how to migrate years of operational data from Oracle into Azure Database for PostgreSQL without introducing downtime, risk, or data drift.

Microsoft and Striim solve this challenge together. Striim’s log-based Change Data Capture (CDC) continuously streams every Oracle transaction into Azure Database for PostgreSQL in real time to deliver zero-data-loss migration, continuous validation, and minimal impact on live applications.

As part of the Microsoft Unlimited Database Migration Program, Striim is optimized to help organizations accelerate and de-risk their journey to Azure by combining enterprise-grade CDC technology, architectural best practices, and hands-on partner expertise. This joint solution empowers enterprises to modernize on Azure faster, with confidence, while paving the way for AI-ready architectures and long-term innovation.

This tutorial walks through the architecture, deployment steps, and best practices for Oracle to Azure Database for PostgreSQL migrations using Striim.

Why Use Striim for Continuous Migration

The strategic partnership between Microsoft and Striim enables continuous data replication from existing databases into Azure in real time, enabling online migrations with zero downtime. Through this Unlimited Database Migration Program, customers gain unlimited Striim licenses to migrate as many databases as they need at no additional cost.

Program highlights include:

Zero-downtime, zero-data-loss migrations across SQL Server, Oracle, MySQL, PostgreSQL, Azure SQL and more.
Support for heterogeneous, mission-critical workloads across relational and non-relational systems.
Real-time, AI-ready data pipelines, preparing workloads for analytics and ML once migrated.

With Striim, data moves continuously via log-based CDC, reading directly from Oracle transaction logs and replicating every insert, update, and delete to Azure in real time. This minimizes impact on production systems while maintaining full data consistency during migration.

Architecture Overview

The jointly recommended architecture consists of:

Source: an existing Oracle instance (on-premises or hosted in another environment).
Processing Layer: Striim, deployed in Azure for low-latency, secure data movement.
Target: Azure Database for PostgreSQL (Flexible Server)

Connectivity is established over standard Oracle (1521) and PostgreSQL (5432) ports, but can also utilize ports configured by the customers. Azure customers can use Private Link, VNets, and other native Azure networking controls to secure traffic throughout the migration.

Step 1: Preparing the Oracle Source

Before replication can begin, configure Oracle so that redo logs are accessible and a CDC user can be used by Striim.

Striim supports multiple CDC methods for Oracle:

Oracle Reader (LogMiner): Uses Oracle’s LogMiner API to read from redo logs. This is the default method.
OJet: A high-performance CDC method, typically used for Oracle 21c or very high-volume workloads that generate large amounts of redo logs.
GoldenGate trail files: If Oracle GoldenGate is already present, Striim can read from existing GoldenGate trail files rather than attaching another CDC process directly to the source database.

All options are log-based, ensuring CDC overhead is typically in the low single-digit percentage range.

Once chosen, ensure Striim can connect to Oracle over the JDBC listener port (default 1521). If Oracle is on-premises, this typically involves VPN/ExpressRoute or an SSH tunnel/jump host from Striim to the Oracle network before you can create a CDC user in Striim.

Creating a CDC user (example)

As an Oracle user, create a dedicated account for Striim and grant the required privileges for redo log access (exact grants may vary by version and CDC method). Please reference Striim’s Oracle CDC docs for the latest instructions:

CREATE USER striim_user IDENTIFIED BY "StrongPassword!";

GRANT CONNECT, RESOURCE TO striim_user;

-- Example privileges for redo/log views (adjust per security and Striim docs)

GRANT SELECT ANY TRANSACTION TO striim_user;

GRANT SELECT ON V_$LOG TO striim_user;

GRANT SELECT ON V_$LOGFILE TO striim_user;

GRANT SELECT ON V_$ARCHIVED_LOG TO striim_user;

GRANT SELECT ON V_$DATABASE TO striim_user;

Once the user is created and networking is in place, Striim can be configured to connect to Oracle using a JDBC URL such as:

jdbc:oracle:thin:@//<oracle-host>:1521/<service_name>

Step 2: Preparing Azure Database for PostgreSQL

On the target side, you must provision Azure Database for PostgreSQL and ensure schema, networking, and permissions are in place before starting data movement.

Schema creation

Prior to starting the data movement pipelines, create tables in Azure Database for PostgreSQL corresponding to those in the Oracle source. This can be done with:

Striim’s Schema Conversion Utility (CLI): Generates SQL DDL for the target system based on Oracle metadata.
Striim’s wizard-based schema creation: Creates target tables directly from the Striim UI during pipeline configuration.
External tools: You can also use existing schema migration utilities or custom DDL as required.

Permissions

Create an Azure DB for PostgreSQL user for Striim with write privileges on the target tables. For example:

CREATE USER striim_user WITH PASSWORD 'strongpassword';

GRANT INSERT, UPDATE, DELETE, SELECT ON ALL TABLES IN SCHEMA public TO striim_user;

ALTER DEFAULT PRIVILEGES IN SCHEMA public

GRANT INSERT, UPDATE, DELETE, SELECT ON TABLES TO striim_user;

Striim will use this user when running Database Writer components against Azure Database for PostgreSQL.

Step 3: Building the migration pipeline

A complete Oracle to Azure Database for PostgreSQL migration typically includes three coordinated stages:

Schema Migration – Create equivalent tables and objects in Azure Database for PostgreSQL.
Initial Load – Bulk-load historical data from Oracle into Azure.
Change Data Capture (CDC) – Continuously stream real-time transactions, keeping source and target in-sync until production cutover.

Initial load & continuous stream

Once the schema is in place using one of the methods above, you can configure Striim to first bulk-load historical data, then switch to continuous CDC.

During the initial load, Striim uses a Database Reader component to extract full tables from Oracle, and a Database Writer component to load them into Azure Database for PostgreSQL. The Striim applications can be built through a drag-and-drop interface, a wizard, or through a text-based interface, shown below.

The Database Writer uses a user-defined batch policy to control how data is written. By default (e.g., EventCount:1000, Interval:60s), Striim will write to PostgreSQL when either 1,000 events are accumulated or 60 seconds have passed, whichever happens first.

A conceptual example of an initial-load configuration using TQL might look like:

CREATE SOURCE OracleInitialLoadReader USING DatabaseReader (

Username:'striim_user',

Password:'strongpassword',

ConnectionURL:'jdbc:oracle:thin:@//oracle-host:1521/ORCL',

Tables:'HR.EMPLOYEES'

);

CREATE TARGET PostgreSQLInitialLoadWriter USING DatabaseWriter (

Username:'striim_user',

Password:'strongpassword',

ConnectionURL:'jdbc:PostgreSQL://pg-host:5432/mydb',

Mode:'Insert',

BatchPolicy:'EventCount:10000,Interval:30s'

)

INPUT FROM OracleInitialLoadReader;

Continuous CDC stream

After the initial load completes, Striim switches to a CDC pipeline that applies new Oracle transactions in real time until cutover. The CDC pipeline uses an Oracle CDC reader (Oracle Reader, OJet, or GoldenGate trail reader) and a Database Writer targeting Azure Database for PostgreSQL.

A CDC example in TQL could look like:

CREATE SOURCE OracleCDCReader USING OracleReader (

Username:'striim_user',

Password:'strongpassword',

ConnectionURL:'jdbc:oracle:thin:@//oracle-host:1521/ORCL',

Tables:'HR.EMPLOYEES'

);

CREATE TARGET PostgreSQLCDCWriter USING DatabaseWriter (

Username:'striim_user',

Password:'strongpassword',

ConnectionURL:'jdbc:PostgreSQL://pg-host:5432/mydb',

Mode:'UpdateOrInsert',

BatchPolicy:'EventCount:1000,Interval:60s'

)

INPUT FROM OracleCDCReader;

To ensure zero data loss, follow the sequencing guidelines in Striim’s documentation for switching from initial load to continuous replication.

Cutover

When the Azure Database for PostgreSQL environment is fully synchronized, and you are ready to move applications off Oracle:

Pause writes to Oracle. Temporarily stop application writes to the source.
Validate record counts. Compare row counts (and optionally checksums or spot checks) between Oracle and Azure Database for PostgreSQL. Striim has recently released a new tool called Validata to automatically do this. Please reach out to learn more.
Redirect application traffic to Azure Database for PostgreSQL. Update connection strings so applications now point at the Azure PostgreSQL instance.

Because Striim’s CDC keeps the source and target continuously in sync, the cutover window is typically very short, minimizing or eliminating downtime for end users.

Adding Transformations and Smart Data Pipelines

Beyond one-to-one replication, Striim allows you to enrich, transform, and validate data in flight using continuous SQL queries or custom Java processors. For example, you can append metadata for auditing:

SELECT *, CURRENT_TIMESTAMP() AS event_time, OpType() AS operation FROM SQLServerStream;

These Smart Data Pipelines enable in-stream transformations (e.g., deduplication, validation, or enrichment) without separate ETL jobs, streamlining modernization into a single continuous flow.

Performance Expectations

In joint Striim–Microsoft testing:

1 TB historical load typically completed in 4–6 hours, which can be further performance-tuned to decrease initial load time.
CDC replication latency averages sub-second for inserts, updates, and deletes.

Performance depends on schema complexity, hardware, and network configuration. For optimal results:

Deploy Striim in the same Azure region as the target.
Use private networking.
Allocate adequate CPU and memory to handle peak CDC throughput.

Support and Enablement

The Microsoft Unlimited Database Migration Program is designed specifically to provide customers direct access to Striim’s field expertise throughout the migration process.

From end-to-end, you can expect:

Onboarding and ongoing support, including installation kits and walkthroughs.
Higher-tier service packages are available as well.
Direct escalation paths to Striim for issue resolution and continuous assistance during migration and replication.
Professional services and funding flexibility, such as ECIF coverage for partner engagements, cutover or weekend go-live standby, and pre-approved service blocks to simplify SOW approvals.

Together, these resources ensure migrations from Oracle to Azure DB for PostgreSQL are fully supported from initial enablement through post-cutover operations, backed by Microsoft and Striim’s combined teams.

Whether your goal is one-time migration or continuous hybrid replication, Striim’s CDC engine, combined with Azure’s PostgreSQL Database, ensures every transaction lands with integrity. Start your modernization journey today by connecting with Striim directly through your Microsoft representative.

Azure Cache for Redis to Azure Managed Redis: A Practical Guide with AI-Assisted Migration Planning

Shruti_Pathak — Tue, 12 May 2026 16:30:00 GMT

Author: Purna Mehta, Product Manager, Redis Inc and Shruti Pathak, Product Manager, Microsoft

Today we’re introducing two capabilities for migrating from Azure Cache for Redis (ACR) to Azure Managed Redis (AMR): an AI-assisted planning skill and a native migration workflow in the Azure portal. Used together, these tools provide a structured path from initial assessment to a fully cleaned-up Azure Managed Redis deployment.

This post walks through each phase of the migration, what to expect at each step, and how the agent and portal work together to reduce complexity and risk.

Why Migrate to Azure Managed Redis?

Azure Managed Redis is Microsoft’s next-generation managed Redis offering for enterprise workloads on Azure. It delivers higher throughput and lower latency than Azure Cache for Redis, along with flexible SKU tiers, enhanced clustering, active geo-replication, and advanced persistence options.

Azure Managed Redis supports Redis-based AI workloads on Azure, including integrations for vector search and intelligent caching. If you’re building AI-powered applications on Azure, Azure Managed Redis is the recommended platform for Redis-based scenarios.

We recognize that migrating a production cache requires care. That is why we built an end-to-end experience that begins with AI-assisted planning and ends with a guided portal migration.

There is also a practical reason to start planning now: Azure Cache for Redis is being retired, and Azure Managed Redis is the path forward for Redis workloads on Azure. Migrating early gives you time to validate dependencies, update configurations, and make the transition on your own schedule instead of under deadline pressure. Just as importantly, the Azure Cache for Redis hostname will eventually expire, so cleaning up references to the old hostname is an important part of completing the migration cleanly. For details, see the retirement announcement and this blog post.

The rest of this post outlines the planning and execution phases for migrating from Azure Cache for Redis to Azure Managed Redis with the Redis migration tooling.

Phase 1: Migration Planning

Before touching any infrastructure, you need a clear view of what you are migrating, what the target should look like, and which risks to address. The new Azure Cache for Redis migration agent skill helps with that. You can also refer to the migration documentation here.

The migration agent skill can be added to any AI agent and invoked from AI-powered chat assistants such as GitHub Copilot and Claude. With read access to your Azure subscription, the skill can inspect your existing Azure Cache for Redis instances and help you:

- Compare and contrast Azure Cache for Redis and Azure Managed Redis

- Guide through selecting the appropriate Azure Managed Redis SKUs

- Help convert IaC templates

- Help with planning and execution of migration along with troubleshooting common issues

You interact with it conversationally, asking questions and refining the plan iteratively until you are confident in the approach.

In a typical planning session, the skill analyzes your source cache configuration in detail, including SKU and tier, memory size, eviction policy, persistence settings, clustering topology, TLS configuration, and any geo-replication setup. It then maps those properties to available Azure Managed Redis tiers and recommends the most appropriate target configuration for your workload. The skill can also fetch real-time cache usage metrics and recommend SKU optimizations.

Beyond the SKU recommendation, the skill identifies potential compatibility issues and configuration gaps you need to address before migrating. This might include client library version requirements, changes to supported Redis commands, differences in eviction policy behavior between tiers, or networking considerations if your cache is deployed in a VNet. Surfacing these issues early, before you have provisioned anything, gives you time to address them without pressure.

The skill can also help you choose a migration strategy. If downtime tolerance is low, it walks you through online migration options and what to expect during cutover. If your workload can tolerate a maintenance window, it can outline a simpler offline path. You can also ask follow-up questions about cost, rollback, or how to validate the new instance before switching traffic.

At the end of the planning session, ask the agent for a structured migration checklist. It should summarize the recommended target configuration, pre-migration action items, and the step-by-step plan for Phases 2 and 3. This gives your team a shared reference for execution.

Note: The AI-assisted migration planner is intended to support planning, not replace expert judgment. For highly critical workloads, we recommend working closely with a Solutions Architect or migration specialist to validate your plan before proceeding.

Phase 2: Provision the Target Azure Managed Redis Cache

With a clear migration plan from Phase 1, you are ready to create your Azure Managed Redis target instance. This step is straightforward, but one constraint matters: the target AMR cache must be in the same subscription and region as the source ACR cache. This is a requirement of the portal migration workflow in Phase 3, which links the two instances together to perform the migration.

In the Azure portal, create a new Azure Managed Redis resource in the same subscription and region as your source cache. Apply the tier and SKU recommended in Phase 1, whether that is Balanced for general-purpose workloads, Memory Optimized for memory-intensive scenarios, or Compute Optimized for throughput-heavy applications. Configure the instance as outlined in your migration checklist, including Redis Users for Entra ID authentication, private endpoints, eviction policy, persistence, clustering, and TLS. The migration agent skill can also help update your IaC templates by converting them from Azure Cache for Redis to Azure Managed Redis.

Once the instance is provisioned and running, note the resource name. You will select it by name when you start migration in Phase 3. At this point the AMR instance is empty, which lets you validate the configuration, test connectivity from your application environment, and confirm everything looks correct before migration.

Note: Redis Migration tooling works by switching the DNS endpoint from your source Azure Cache for Redis instance to the target Azure Managed Redis instance. No data is transferred as part of this process.

Phase 3: Initiate Migration from the Azure Portal

Note: Before using the Redis migration tooling, please review the limitations of the tooling and other migration options.

To use the Redis Migration tooling, navigate to your source Azure Cache for Redis instance in the Azure Portal and select Migrate in the command bar.

Choose a target Azure Managed Redis instance from the dropdown, which lists only AMR instances in the same subscription and region as your source cache.

Review the migration summary comparing source and target configurations. An automated compatibility check surfaces warnings or errors with guidance for resolving them. You can acknowledge warnings to proceed, but errors must be addressed first. We strongly recommend running the migration during a maintenance window or low-traffic period.

Your resource state will update to “Migrating” while the migration is in process. After migration completes, the Azure Cache for Redis hostname redirects requests to the Azure Managed Redis instance, allowing applications to continue using the existing source connection string temporarily.

Note: Keep your source ACR cache running and do not delete it. If you encounter problems after the migration, you can initiate a rollback to the original ACR cache and resume normal operation while you investigate. The source cache remains available and unchanged throughout the migration process. Once you are confident the new instance is stable and performing as expected, you can retry Phase 3 and then proceed to Phase 4 to clean up the source cache.

Phase 4: Ensure success and delete old Azure Cache for Redis instance

After migration, monitor application health to confirm everything is working as expected. If issues arise, you can roll back the migration. Once you have verified success, you can delete the source Azure Cache for Redis instance. The Azure Cache for Redis instance is now decoupled from its hostname and can be deleted safely. The hostname will continue to point to the new Azure Managed Redis instance.

Phase 5: Update applications to use the Azure Managed Redis hostname

After you confirm the migrated Azure Managed Redis instance is running as expected, update your applications to use the Azure Managed Redis connection string instead of the old Azure Cache for Redis connection string. This step is required because the old Azure Cache for Redis hostname will be purged automatically. Because traffic is already flowing to the migrated instance, this update should have minimal impact.

It is easy to postpone this step, but doing it promptly keeps your subscription clean, avoids unnecessary cost, and removes ambiguity about which cache instance is active.

The main cleanup task is purging the source Azure Cache for Redis hostname. Before you do, confirm that no applications or services still reference the old connection string, including Key Vault secrets, environment variables, monitoring dashboards, and background jobs. Take a few minutes to search broadly, since any missed reference will fail after the old hostname is purged.

Once all references have been updated, use the ‘unlink’ API to purge the source Azure Cache for Redis hostname. If the Azure Cache for Redis instance has associated resources such as private endpoints, or diagnostic settings, review whether they should be removed or reconfigured for the new AMR instance. Finally, update any internal documentation, runbooks, and architecture diagrams that still reference the old cache. At that point, the migration is complete.

Getting Started

Both the migration planning agent skill and the portal migration workflow are available today. Here is how to get started:

The migration agent skill is available here and includes setup instructions.
To provision your Azure Managed Redis target, find instructions here.
To start migration, go to your source Azure Cache for Redis cache in the Azure portal and select "Migrate to Azure Managed Redis" from the command bar. More details about the migration tooling are available here.

We recommend starting every migration with a session with the planning agent, even when the migration seems straightforward. It consistently surfaces configuration details and compatibility issues that are easy to miss and can cause problems later. A few minutes of planning up front is well worth the time.

Reach us at AzureManagedRedis@microsoft.com or through your account team with questions, suggestions, or stories from your migration journey.

rss.livelink.threads-in-node

Unlocking the Power of Azure Resource Graph Explorer for Comprehensive Database Inventory

Why Taking Inventory is Crucial

Who Does This Matter To

How Azure Resource Graph Explorer Helps

Feedback

The Odd Couple - Latches and KEEP_NULLS

Introduction

Background: The Ingredients

The Problem: Two Layers of Serialisation

Layer 1: INSERT BULK Fires the DEFAULT - Even When You Supply Values

Layer 2: NUMERIC Sequences Take Exclusive Latches

The Combined Effect

Proving It: The KEEP_NULLS Experiment

Setup

Test 1: BCP Without KEEP_NULLS (Default Behaviour)

Test 2: BCP With KEEP_NULLS

Test 3: Table Without DEFAULT (Control)

Summary

Proving It: NUMERIC vs BIGINT Latch Contention

IDENTITY Columns Have the Same Issue

The Fixes

Fix 1: Enable KEEP_NULLS in the Bulk Copy Client

Fix 2: Drop the DEFAULT Constraint

Fix 3: Change NUMERIC Sequences to BIGINT

Fix 4: Right-Size Sequence Cache

When Each Fix Applies

How to Detect This Pattern

Wait Stats

Sequence Consumption Rate

Execution Plans

Test Scripts

Setup: Database, Sequences, and Tables

Test: BCP KEEP_NULLS Comparison

Test: Concurrent Latch Comparison (PowerShell)

Key Takeaways

Documentation References

Feedback and Suggestions

PostgreSQL Meets AI at POSETTE: An Event for Postgres 2026 (T-3 weeks)

From queries to agents: when the database becomes a tool

RAG in practice: why PostgreSQL keeps showing up

The real problem is retrieval, not generation

The emerging retrieval stack: what sits between agents and data

Why this matters if you build real systems

What you’ll take away from the AI track at POSETTE: An Event for Postgres this year

A quick call to action

Why do I see many VDI_CLIENT_WORKER sessions in Azure SQL Database — and do they impact performance?

Why you might see VDI_CLIENT_WORKER sessions in Azure SQL Database

The symptom

Why it shows up in Azure SQL

How to validate whether VDI_CLIENT_WORKER is benign?

1) Correlate to recent platform operations.

2) Check whether they consume resources.

3) Don’t try to kill them!

4) If you need them to disappear.

When performance is actually slow: focus on what usually hurts.

Key takeaways

General Availability of the MySQL Flexible Server Quota Management Self-Service Experience

What’s New?

Benefits at a Glance

How It Works

Step-by-Step: Viewing Usage and Requesting a Quota Increase

Step 1: Navigate to the Quotas Blade

Step 2: Select the Azure Database for MySQL Provider

Step 3: Review Your Quota Usage and Limits

Step 4: Request a Quota Increase

Step 5: Enter the New Limit

Step 6: Submit and Monitor the Request

Step 7: Verify the Quota Increase

Filing a Support Ticket

Known Limitations

Feedback

Introducing PostgreSQL Hub for Azure Developers

Who is this for?

Get Started

Demystifying LWLock: MultiXact SLRU Wait Events in Azure Database for PostgreSQL

What Is the MultiXact Subsystem?

The Core Insight: Cache Hits and Lock Contention are not mutually exclusive

What Triggers MultiXact SLRU Wait Events?

How to Diagnose This in Real Time

The Core Insight:
Cache Hits and Lock Contention are not mutually exclusive