rss.livelink.threads-in-node

ADF - REST API Copy Data Activity - Best Practices

grames — Wed, 03 Jun 2026 19:43:01 GMT

Hey everyone,

I'm relatively new to Azure and am using Azure Data Factory (ADF) to extract data from Vonigo via their API.

Everything is working, but I'm looking for ways to improve efficiency. Right now it takes 30+ minutes to pull all franchise data for a given report.

The challenge is that Vonigo only allows reports to be run for one franchise at a time, and switching franchises requires a separate API call. My current process is:

Select a franchise from a list
Run all required reports for that franchise
Save the results to Blob Storage
Move to the next franchise and repeat

(We'll eventually ingest the files into our silver layer for transformation.)

Speed Issue

One thing that significantly slows the pipeline down is that many activities are running sequentially. If I disable sequential execution, I've seen cases where data gets written to the wrong destination or associated with the wrong franchise.

Has anyone successfully parallelized a similar process while maintaining data integrity? Are there specific points in the workflow where parallel execution would be safe?

Pagination / Loop Issue

Originally, I used a Lookup activity to inspect the most recently created file. An If activity would then determine whether the file contained any records:

If records existed, increment the page number and continue.
If no records existed, end the loop.

This worked, but the Lookup activity added noticeable overhead.

To improve performance, I changed the logic to use the Copy Activity output instead. Specifically, I'm checking the amount of data read from the last API call. Pages with no records appear to consistently return the same data-read value, so I use that to determine when to stop paging.

This approach is much faster, but it feels more fragile since it's relying on an indirect indicator rather than the actual record count.

Would you trust the Copy Activity output in this scenario, stick with the Lookup approach, or recommend a different pattern altogether?

Thanks for any suggestions.

Transparent data encryption in Azure SQL Database now supports AES keys (Public Preview)

PieterVanhove — Wed, 03 Jun 2026 06:21:32 GMT

For teams thinking about long-term cryptographic resilience, this preview is especially relevant. TDE with customer-managed keys has traditionally used asymmetric RSA-based key protectors, while broader industry guidance is increasingly focused on preparing for a post-quantum cryptographic (PQC) future and adopting cryptographic approaches that are better aligned with that transition.

This update aligns with broader security guidance, including the NSA’s CNSA 2.0 recommendations, which emphasize modern cryptographic planning for a quantum-resistant future. For organizations building crypto agility into their platforms, AES support is a practical step in that direction.

Why it matters

Preparing for a post‑quantum world

With current technology, breaking asymmetric algorithms such as Elliptic Curve and RSA-2048 using the best-known classical methods would take billions of years. Even with large-scale distributed computing, it is still considered computationally infeasible.

Asymmetric algorithms are vulnerable to Shor’s algorithm, which means a sufficiently powerful quantum computer could break RSA-2048 much faster. That said, this would require millions of stable qubits, and current quantum systems are still far from that point. AES, as a symmetric algorithm, is not affected by Shor’s algorithm and remains more resistant to known quantum attacks, including Grover’s algorithm, when used with larger key sizes such as AES-256.

The figure below highlights the difference in the estimated effort required to break RSA-2048 and AES-256. For context, the green dashed line represents the age of the universe, about 13.8 billion years.

Aligning with modern security guidance

Security guidance is moving toward stronger crypto agility and long-term resilience. By supporting AES keys for TDE protectors, Azure SQL Database gives customers a way to align data-at-rest protection with evolving security and compliance expectations.

For a broader overview of quantum computing and cryptography, see Microsoft’s post-quantum cryptography overview.

How it works (high level)

At a high level, nothing changes about the purpose of TDE: it still protects data at rest by encrypting the Database Encryption Key (DEK) with a TDE protector. What changes in this preview is the type of key you can use to protect, or wrap, the AES DEK.

The AES DEK encrypts database data files and log files.
The TDE protector encrypts the DEK.
With TDE with customer‑managed keys, the TDE protector is stored in Azure Key Vault or Azure Key Vault Managed HSM.
With this preview, the TDE protector can now be a symmetric AES key instead of an RSA key.

For background on customer-managed TDE, see the Customer-managed transparent data encryption (TDE)

Get started

If you want to try the preview, make sure the following prerequisites are in place:

An Azure SQL Database logical server or database with customer-managed TDE enabled.
An Azure Key Vault Managed HSM with support for AES keys.
Soft-delete and purge protection enabled on the key store.
The required permissions for Azure SQL Database to access the key.

You can review the full prerequisites in Microsoft Learn under requirements to configure customer-managed TDE.

The setup flow for AES keys is essentially the same as for RSA-based TDE protectors. The main difference is the type of key you create and register.

Create an AES key (for example, AES‑256) in Azure Key Vault Managed HSM.
Add the key to your Azure SQL logical server.
Set the AES key as the TDE protector.
Verify that encryption is enabled using system views.

For step-by-step configuration guidance, see Microsoft Learn on Create Azure SQL Database Logical Server Configured with User-Assigned Managed Identity and Customer-Managed TDE.

Example configuration (PowerShell)

The following example shows the basic PowerShell flow: create an AES key, register it with the logical server, and then set it as the TDE protector.

# Variables $hsmName = "MyHSM" $keyName = "TDE-AES-Key" $sqlServerName = "my-sql-server" $sqlResourceGroup = "my-sql-rg" # Create an AES-256 HSM-backed key in MHSM Add-AzKeyVaultKey ` -HsmName $hsmName ` -Name $keyName ` -KeyType oct-HSM ` -Size 256 # Get key URI $key = Get-AzKeyVaultKey -HsmName $hsmName -Name $keyName # Register the key with the SQL server Add-AzSqlServerKeyVaultKey ` -ResourceGroupName $sqlResourceGroup ` -ServerName $sqlServerName ` -KeyId $key.Id # Set the key as the TDE protector Set-AzSqlServerTransparentDataEncryptionProtector ` -ResourceGroupName $sqlResourceGroup ` -ServerName $sqlServerName ` -Type AzureKeyVault ` -KeyId $key.Id

After you enable TDE with AES keys, you can verify the database encryption status by running the following query:

SELECT DB_NAME(database_id) AS DatabaseName, encryption_state_desc, encryptor_type FROM sys.dm_database_encryption_keys WHERE database_id <> 2;

If the database is encrypted, the view returns an ENCRYPTED state, or ENCRYPTION_IN_PROGRESS while encryption is still underway, with SYMMETRIC_KEY shown as the encryptor type.

Public preview notice

Transparent data encryption in Azure SQL Database with AES keys support is currently in Public Preview. Preview features are provided for evaluation purposes and are subject to the Azure Preview Supplemental Terms .

Availability is rolling out gradually across Azure regions. You may see this capability appear over time depending on your region and service deployment status. Azure SQL Database is the first SQL offering to receive this feature, with additional SQL platforms planned in the future.

Learn more

Conclusion

AES key support for customer-managed TDE gives Azure SQL Database customers a practical way to strengthen their encryption strategy while preparing for long-term cryptographic change, including post quantum cryptography. Because the setup experience remains familiar, teams can evaluate this preview without rethinking how TDE works operationally.

We want your feedback

If you’re exploring this preview, now is a good time to test it in your environment and share feedback with the product group before general availability.

Build 2026: New Azure Managed Redis Capabilities for AI-Ready Applications

Shruti_Pathak — Tue, 02 Jun 2026 19:15:00 GMT

As AI-driven applications continue to evolve, developers need a data platform that can keep up, delivering real time performance, intelligent context, and enterprise grade security at scale.

At Microsoft Build 2026, we’re excited to share the latest capabilities in Azure Managed Redis, designed to help you build faster, smarter, and more secure applications, especially in the era of AI agents and intelligent services. These releases bring together a set of foundational improvements across security, performance, developer experience, and AI integration, reflecting our ongoing investment in making Azure Managed Redis one of the top data platforms for modern, real-time workloads.

Powering the next generation of AI applications

Azure Managed Redis is increasingly being used as the memory and context layer for AI powered applications, including copilots, chatbots, and autonomous agents.

At Build 2026, we are highlighting enhanced capabilities to support these scenarios:

Vector search and semantic caching to improve response relevance while reducing latency and cost

Real-time memory and context management for agent workflows

Support for retrieval augmented generation, also known as RAG, and event driven architectures

These capabilities enable developers to build applications that retrieve the right information in milliseconds, delivering more responsive and context aware AI experiences.

New enterprise grade data access with Entra ID based RBAC

Security and governance are critical as Redis becomes a shared platform across teams and applications.

At Build, we are introducing Entra ID based role-based access control for data access, now available in public preview.

With this capability, you can:

Enforce fine grained access control over Redis data with ACL

Align permissions with your enterprise identity system

Replace shared keys with identity-based access

Improve auditability and compliance

This feature is built on Redis access-control lists and enables secure, multi team collaboration without increasing operational complexity.

Learn more.

Flash-Optimized SKUs Now Generally Available (Up to 1.5 TB)

We’re excited to announce the general availability of Flash-Optimized Azure Managed Redis (AMR) SKUs, now supporting capacities up to 1.5 TB. These new SKUs deliver a compelling balance of performance and cost-efficiency, enabling customers to run large-scale workloads with predictable latency and significantly lower memory costs. Learn more.

Enterprise readiness

In addition to new innovations, this release includes several important enhancements that improve enterprise readiness and feature completeness, based on customer feedback and real-world usage.

Key updates include:

Access control lists for controlling user permissions at a granular level

Keyspace notifications (in preview) to enable event driven application patterns

Larger SKUs, including 250 gigabyte and 350 gigabyte tiers, to support more demanding workloads

Dashboards with Grafana in Azure Managed Redis bring Azure Monitor's built-in Grafana experience directly into the Azure portal.

Expanded migration tooling for both Azure Cache for Redis and Redis Enterprise

These updates address critical customer needs and remove barriers to adoption, especially for large scale and regulated environments.

Simplified, AI-assisted migration

With the retirement of Azure Cache for Redis underway, migration is a top priority for many customers.

To support this transition, we are introducing:

AI assisted migration planning to help assess and map existing environments

A native migration workflow in the Azure portal for guided execution

Tooling for both Azure Cache for Redis and Redis Enterprise migrations

Together, these capabilities provide a more seamless and structured migration path, reducing risk while accelerating time to value.

Built for performance, scale, and reliability

Azure Managed Redis continues to deliver enterprise grade improvements, including:

High throughput, low latency in memory processing

Zone redundancy and geo replication for resilience

Ongoing investments in developer experience and operational tooling

These capabilities ensure you can scale confidently, whether you are supporting high traffic applications or real time AI systems.

Developer takeaways

At Build 2026, we are helping developers move from experimentation to production with technologies that are secure, scalable, and AI ready by design. These updates position Azure Managed Redis as a core building block for modern applications, including:

AI agents and copilots

Real-time personalization and recommendations

Cloud native microservices

High performance transactional systems

Learn more at Build

If you’re attending Build 2026 (in-person or online) you can find you Azure Managed Redis across sessions, demos, and the in-person expo experience.

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

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

Booth & expo presence

Visit us at the Azure Data / NoSQL booth in the main expo hall 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.

These experiences provide practical guidance, demos, and architectural patterns to help you apply these new Azure Managed Redis capabilities in your own applications.

See you there!

Announcing new security, maintenance and analytics features for PostgreSQL at Microsoft Build 2026

GuyBowerman — Tue, 02 Jun 2026 19:13:35 GMT

At Microsoft Build 2026, we’re announcing a major wave of PostgreSQL innovation across Azure. Alongside the public preview of Azure HorizonDB, we’re delivering a broad set of enhancements for our fully managed open-source PostgreSQL service: Azure Database for PostgreSQL flexible server. These updates span performance, analytics, security, operations, resilience and migration - helping you build faster, operate with more control, secure your workloads, and modernize with confidence.

Here’s a quick tour of the top flexible server announcements at Build 2026.

Feature Highlights

V6 SKU with local SSD storage (NVMe)
pg_duckdb Extension
pg_ivm Extension
Defender Security assessments
temporal_tables Extension
Cross-tenant CMK
Automatic Entra token refresh libraries
New Powershell module: Az.PostgreSQLFlexibleServer
More control over planned maintenance
Pre-Upgrade validation checks
New Built-in Grafana dashboards
Chaos Studio supports Azure Database for PostgreSQL
AI-assisted Oracle to PostgreSQL migration
Migration Service for Azure Database for PostgreSQL improvements (EDB, AlloyDB)

Performance, Scale & Analytics

V6 SKU with local SSD storage (NVMe) Generally Available by the end of June

V6 Compute SKUs are built to handle your largest workloads, delivering high performance, massive scale, and better price performance. Powered by 5th Gen Intel® Xeon® processor and AMD's fourth Generation EPYC™ 9004 processors you can scale up to 192 vCores and 1.8 TiB of memory. With NVMe-backed local SSD storage and support for high-performance storage options such as Premium SSD v2, you can achieve high IOPS and throughput for demanding, IO-intensive PostgreSQL workloads. The Intel & AMD v6 SKUs with local SSD (NVMe) will be Generally Available by the end of June. Learn more: Compute options in Azure Database for PostgreSQL.

pg_duckdb Extension Generally Available

The pg_duckdb extension enables you to accelerate high-performance analytics and data-intensive applications with DuckDB’s SQL engine running inside your Postgres server. We’re pleased to announce pg_duckdb is now generally available in Azure Database for PostgreSQL. The latest version builds on the preview with the latest DuckDB engine improvements and optimized performance. This version adds vectorized execution for faster analytical queries, delivering significant improvements in aggregation performance, along with new support for writing to Azure Blob Storage and querying Parquet data directly from PostgreSQL. These capabilities enable high-performance analytics on your external data and simplify data processing workflows. Learn more: pg_duckdb.

pg_ivm Extension Generally Available

Materialized views are a useful way to optimize performance for queries that run regularly, but if underlying data becomes stale the result set needs to be recomputed. With the pg_ivm extension you can automatically maintain materialized views as the underlying data changes. This is particularly valuable for large datasets with small incremental changes that need real-time freshness, like dashboards, catalog analytics and SaaS usage reporting. We are pleased to announce the pg_ivm extension is now generally available in Azure Database for PostgreSQL. Learn more: pg_ivm.

Security, Auditing & Identity

Defender security assessments Preview

Microsoft Defender Security Assessments for Azure Database for PostgreSQL enables continuous evaluation of your database security posture, helping identify vulnerabilities and misconfigurations across server and database configurations. Previously limited to reactive threat detection, in the latest preview release, Defender now provides proactive, risk-based insights through assessments tailored to PostgreSQL-specific best practices, delivering more relevant and actionable guidance. This helps you strengthen your security baseline, prioritize remediation, and align with best practices and compliance requirements. Learn more: https://aka.ms/Defender-Assessments-for-PG-Preview

temporal_tables Extension Generally Available

We’ve had many customer requests to support the temporal_tables extension, which provides built-in support for tracking and querying historical changes to data over time. Temporal tables are now generally available in Azure Database for PostgreSQL. With this extension enabled you can easily perform time-based queries, audit data changes, and maintain historical records without building custom tracking logic, simplifying application development and compliance scenarios. Learn more: temporal_tables

Cross-tenant CMK Preview

Azure Database for PostgreSQL now supports cross-tenant customer-managed keys (CMK) in public preview, allowing you to encrypt your data at rest using an Azure Key Vault key that resides in a separate Microsoft Entra tenant from the database service. This feature is designed for SaaS providers and enterprises that need to maintain strict separation of duties and ownership of encryption keys, enabling you to retain full control over key lifecycle management while PostgreSQL runs in a service provider’s tenant. Learn more: Data encryption at rest in Azure Database for PostgreSQL

Automatic Entra token refresh libraries Preview

We’re making it easier to use Entra ID authentication with Azure Database for PostgreSQL throughout the application stack by introducing new token refresh libraries for .NET, JavaScript, and Python.

With Entra ID, access tokens are short-lived which can make managing their lifecycle complex in real-world applications. Developers need to be aware of token refresh and build additional handling around token expiration, connection retry, and session continuity.

These new libraries remove that friction. By handling Entra token refresh seamlessly in the background, they allow applications to stay connected without interruption and with no custom logic required. The result is a simpler development experience and more resilient applications, especially for long-running or connection-heavy workloads.

Across languages, the libraries provide a consistent and streamlined way to adopt secure, passwordless authentication, helping teams focus more on building their applications and less on managing authentication. Learn more: .NET, JavaScript, and Python.

Operations, Maintenance & Monitoring

New Powershell module: Az.PostgreSQLFlexibleServer Generally Available

We’re excited to introduce the newly renamed Az.PostgreSQLFlexibleServer PowerShell module, delivering a streamlined experience for managing Azure Database for PostgreSQL with PowerShell. Building on the capabilities of the previous Az.PostgreSql module, the updated module aligns with the new features in the 2026-01-01 preview REST API. This module brings support for PostgreSQL 18, elastic clusters for scalable workloads and a range of enhancements designed to simplify management and improve performance. Whether you're provisioning new deployments or managing complex environments, this module ensures you can take full advantage of the latest platform capabilities directly from PowerShell.

To learn more, visit our official documentation on PowerShell: Az.PostgreSql Module | Microsoft Learn

More control over planned maintenance Generally Available

We’ve seen many requests to provide more control when a maintenance update is applied to Azure Database for PostgreSQL. Sometimes when a critical workload is running you want to apply the maintenance when you’re ready. Announcing general availability this week, we’re building on the existing System and Custom maintenance window options and adding new self-service maintenance capabilities to the Azure portal.

You can now reschedule upcoming maintenance updates for up to two weeks and apply maintenance on demand at a time that suits you. You can also view scheduled maintenance and review your server’s maintenance history after updates are complete.

These options help you better align maintenance with your business schedules, reduce disruption during critical workload periods, and minimize the need for support-driven deferral requests. CLI and API support are coming soon. Learn more: https://aka.ms/azure-postgres-reschedule-maintenance

Pre-Upgrade validation checks Preview

PVC detects an event trigger blocker before upgrade execution and keeps the upgrade action disabled until issues are resolved.

Major version upgrades are critical for staying current with PostgreSQL features, security updates, and performance improvements, but you often discover blockers only after starting the upgrade workflow. Pre-Upgrade Validation Checks lets you validate upgrade readiness before initiating the actual upgrade by running Azure-specific upgrade checks and PostgreSQL pg_upgrade --check validations independently.

The shift is simple: you can identify and fix upgrade blockers before the upgrade window begins. The feature surfaces actionable issues across configurations, extensions, dependencies, replication slots, event triggers, and other upgrade-sensitive objects. You can fix blockers, re-run validation until all checks pass, and proceed with the upgrade with greater predictability.

Learn more: https://aka.ms/pg-flex-upgrade-checks

New Built-in Grafana dashboards Generally Available

Monitor Azure PostgreSQL with built-in Grafana dashboards — no setup, no extra cost, and no separate service to manage.

Grafana dashboards are now built directly into the Azure portal for Azure Database for PostgreSQL - no setup, no extra cost, and no separate service to manage. You can open your PostgreSQL resource in the portal and immediately access prebuilt dashboards for key health and performance signals such as CPU, memory, storage, IOPS, connections, transactions, and availability.

The key value is metrics + logs in one place. You can quickly correlate performance spikes with PostgreSQL logs, understand what changed, and troubleshoot faster using the familiar Grafana experience. Dashboards can also be customized, saved to your subscription, and shared across teams for ongoing operations.

Learn more: https://aka.ms/azure-postgres-dashboards-grafana

Resilience & Business Continuity

Chaos Studio supports Azure Database for PostgreSQL Preview

No matter how much you prepare, you only really know how good your database disaster recovery plan is when something breaks. With Chaos Studio support for Azure Database for PostgreSQL, you can simulate zone-down scenarios on PostgreSQL HA-enabled instances and validate the resilience of your mission-critical workloads.

With Chaos Studio integration, you can proactively test failover behavior and gain confidence in how your applications respond to real-world zonal failures.

This feature is currently available through a gated private preview. To get started, submit your subscription details using the form. Once reviewed, our team will enable the feature for your subscription, with guidance to help you begin testing.

Getting started is simple:

Create a Chaos Studio workspace via the Chaos Studio portal and configure your subscription, resource group, and region.
Define the scope and assign the required managed identity and permissions.
Review and verify your workspace setup.
Browse available scenarios and select the PostgreSQL zone-down scenario.
Configure the test (name, duration), then run it from My Library to begin validating failover behavior.

With just a few steps, you’ll be able to simulate real-world failure conditions and gain confidence in your application’s resilience.

To get started, please submit your details using this link: Private Preview Support for Chaos Studio

Migration & Modernization

AI-assisted Oracle to PostgreSQL migration Generally Available

AI-assisted migration tooling has dramatically lowered the bar for moving between different databases and is changing the way people look at the return on investment for migration. The VS Code PostgreSQL extension comes with AI-Assisted migration tooling which converts Oracle schema and application code to Azure Database for PostgreSQL. This tooling uses GitHub Copilot, Microsoft Foundry, and custom Language Model tools to convert Oracle schema, database code and client applications into the PostgreSQL equivalents, and validates every change against a running flexible server instance. Learn more: Schema conversion, App conversion.

Migration Service for Azure Database for PostgreSQL improvements (EDB, AlloyDB) Generally Available

We’ve added AlloyDB and EDB Extended Server as new sources for migrating to PostgreSQL in the Azure Database for PostgreSQL Migration Service, with support for both online and offline migration support. Learn more: Migrate from AlloyDB, Migrate from EDB.

Looking ahead

That wraps up the Build 2026 announcements for Azure Database for PostgreSQL flexible server. There are also many great PostgreSQL technical sessions at Build this week, covering cloud-native app and AI development. To find out more, here's a link to the Build session catalog for PostgreSQL sessions: https://aka.ms/Postgres-on-Azure_Build-2026.

We'll continue to build out our roadmap over the coming months to deliver on your asks to improve the performance, security and stability of your PostgreSQL workloads. Check the Microsoft Blog for PostgreSQL for a regular monthly recap where we share the latest enhancements and product updates.

Azure HorizonDB: Enterprise-Ready Postgres, Engineered for the AI Era

charlesfeddersenMS — Tue, 02 Jun 2026 16:45:15 GMT

Affan Dar, Vice President of Engineering, PostgreSQL at Microsoft
Charles Feddersen, Partner Director of Program Management, PostgreSQL at Microsoft

Today at Microsoft Build, we’re pleased to announce the public preview of Azure HorizonDB, a new enterprise-ready Postgres-compatible database service designed to meet the needs of modern AI applications, alongside a set of enhancements to our PostgreSQL tooling in Visual Studio Code to further streamline the developer experience.

Postgres is rapidly solidifying its role as a foundational layer in modern data architectures, with accelerating adoption across industries. For developers, it has become the preferred platform for new application development, driven by its extensible architecture, mature extension ecosystem, and adherence to open standards and APIs. At the same time, enterprises are choosing Postgres to re-platform and modernize existing systems, taking advantage of its ability to support a broad range of operational workloads while enabling advanced capabilities such as vector-based data access all within a single, interoperable platform.

A Postgres Platform Grounded in Security, Resilience, Scale, and Performance

Azure HorizonDB is purpose-built to meet these demands, combining the flexibility developers expect from Postgres with the operational rigor enterprises require. It extends the core Postgres engine with cloud-native capabilities such as integrated identity, fine-grained network and security controls, and seamless lifecycle management, while preserving full compatibility with the open ecosystem of extensions and tools. At the same time, HorizonDB introduces advanced, natively integrated capabilities like vector data support and AI model management, enabling new classes of intelligent applications without sacrificing transactional integrity or developer productivity.

These capabilities are backed by a platform designed for enterprise performance and scale. HorizonDB supports databases up to 128 TB, scales out with up to 15 read replicas for high-throughput workloads, and delivers sub-millisecond commit latency across availability zones for low-latency transactions and high availability. This combination is critical for modern applications that require consistent performance under load, including high-concurrency transactional systems, real-time AI-driven interactions, and globally distributed services.

The result is a unified platform that scales from the first line of code to globally distributed, mission-critical systems. Enterprise adoption ultimately depends on trust in the platform itself. Azure HorizonDB delivers this with native integration into Microsoft Entra ID for centralized identity and access control, private endpoints for network isolation, and built-in encryption to protect data at rest and in transit. These capabilities are essential for meeting compliance requirements and enabling organizations to run mission-critical workloads with confidence, without added complexity.

This foundation is critical for any application, but it becomes indispensable for AI, where secure access to data and controlled model interaction underpin every intelligent experience. Building on this, HorizonDB introduces a set of integrated AI capabilities designed to bring intelligence directly into the database.

Run Fast, Memory-Efficient Vector Search with DiskANN

HorizonDB brings high-performance vector search directly into Postgres through DiskANN with spherical quantization. This enables efficient, low-latency similarity search at scale while significantly reducing memory and storage overhead. Spherical quantization works by normalizing vectors and encoding them into compact representations that preserve angular distance, allowing the system to compare vectors efficiently with minimal loss in accuracy. The result is the ability to index and query large embedding datasets within the transactional engine itself, making vector search a first-class capability rather than an external dependency.

"HorizonDB is compelling because it brings a PostgreSQL-compatible foundation, AI-native capabilities and enterprise-grade controls closer to the operational data layer."

Jennings Balavari, Founder, Opsen AI

Build Smarter Apps with Hybrid Search in Postgres

HorizonDB supports hybrid search by combining vector similarity through pgvector with full-text search enabled via the pg_textsearch extension, allowing applications to match both semantic meaning and precise keyword relevance in a single query. This enables more accurate, context-aware results, such as blending intent-driven retrieval with exact term matching for search, recommendations, or RAG scenarios. By unifying these capabilities within Postgres, HorizonDB improves result quality while simplifying application design without the need for external search systems.

Operationalize AI with Built-In AI Model Management

Working with vectors requires models to generate, interpret, and evolve embeddings, making model lifecycle a core part of the application stack. HorizonDB introduces integrated AI model management to simplify how models are registered, versioned, and governed alongside data, including built-in support for generative GPT models and ranking models. For example, GPT models can be used to generate summaries, responses, or structured outputs directly from application data, while ranking models enable relevance scoring for search results or recommendations over vector results. By managing these models alongside the data they operate on, HorizonDB ensures consistency, traceability, and control, creating a unified environment where models and data evolve together.

“As we build a multi-tenant, AI-driven commerce platform, HorizonDB has been particularly compelling in two areas: scale and how close AI capabilities are to the data itself. Running vector search, filtering, and model-driven workflows directly inside the database removes a lot of the complexity we’d normally manage across separate services."

James Frawley, CIAO, ReFiBuy

Bring AI into SQL with AI Functions

With models managed in place, AI Functions provide a direct way to invoke them from within SQL and application logic. These functions are implemented through the azure_ai extension, which brings model invocation directly into the Postgres engine. This allows developers to embed inference into queries and transactions, eliminating the need for external orchestration. By bringing model execution closer to the data, AI Functions reduce latency, simplify application design, and make intelligent behavior a natural extension of existing Postgres workloads.

"What stood out with HorizonDB is that it aligns closely with how we already think about the problem. Instead of stitching together multiple components, it brings transactional data, vector search, and AI capabilities into a single platform, which simplifies the architecture without forcing a complete rethink."

Mohsin Shafqat, Director Software Engineering, Nasdaq

Run Reliable, Event-Driven Workflows with AI Pipelines

Finally, AI Pipelines operationalize these capabilities through reliable, event-driven workflows for model execution and data processing. Pipelines execute on data changes, enabling real-time asynchronous reactions without external orchestration and ensuring consistent, repeatable behavior as data evolves. Combined with model management and AI Functions, they turn embedded intelligence into something that can be run, scaled, and trusted in production, while inheriting the database’s high availability and failover characteristics for resilience. Pipelines can also be visualized and observed in real time through the Visual Studio Code extension for PostgreSQL, giving developers and operators immediate visibility into execution flow, state, and outcomes

Modern Unified Experience for Data, AI, and Operations in VS Code

As intelligence becomes a core part of the data platform, the developer and operator experience becomes equally critical. HorizonDB extends seamlessly into Visual Studio Code with enhanced PostgreSQL tooling that works across any Postgres deployment, not just HorizonDB. Features like AI-assisted query plans and integrated monitoring enable faster debugging and optimization, helping teams understand both database performance and AI-driven behaviors.

At the same time, for Azure-based deployments, the experience is deeply integrated with platform capabilities, enabling management of networking configuration, server parameters, and server logs directly from the development environment, streamlining operations across application and infrastructure layers.

Azure HorizonDB brings together enterprise-grade security, deep Postgres compatibility, and a modern AI-native data platform, all engineered for developers. It scales efficiently across workloads, from transactional systems to intelligent applications, while delivering a world-class, Azure-integrated experience in Visual Studio Code for both developers and operators.

Ready to get started with Azure HorizonDB?

Azure HorizonDB is now available in public preview in Australia East, Central US, Sweden Central, West US 2, and West US 3 regions. Additionally, East US, Canada Central, Indonesia Central, Italy North, Japan East, Korea Central, and Poland Central will be available in the coming weeks.

You can get started today by creating a new HorizonDB instance using the Azure portal, API’s, or the Visual Studio Code extension for PostgreSQL to begin exploring these capabilities firsthand.

To learn more, dive deeper into our documentation and sign-up today to try AI model management in a limited preview.

Your PostgreSQL workflow just found its new home in Cursor

iemejia — Thu, 04 Jun 2026 18:59:42 GMT

TL; DR: Our Visual Studio Code extension for PostgreSQL is now available on the Open VSX registry: Cursor users get first-class database tooling without leaving the editor that already understands their code.

The context switch problem

If you use Cursor, you know the feeling. You’re deep in an agentic flow. Composer is scaffolding a feature across multiple files. Tab is anticipating your next move. Then you need to check a table's schema or run a quick query, so you switch to a different tool, and then you lose your flow state, and spend 30 seconds remembering which connection goes to which environment.

That context switch is expensive. Not in minutes, but in momentum.

Why we built for Cursor (and Open VSX)

Cursor is built on the VS Code ecosystem, which means it supports VS Code extensions natively. It uses the Open VSX registry: an open, vendor-neutral extension marketplace where database tooling options have been limited.

We saw an opportunity: bring a modern PostgreSQL extension directly to where developers do their most productive work. By publishing to Open VSX, we make sure that developers across the entire VS Code-compatible ecosystem, including Cursor, Windsurf, AWS Kiro, Theia, and Ona all have access without workarounds.

Where AI-powered editing meets database awareness

Here’s what gets interesting. Cursor indexes your entire codebase semantically. It knows your Drizzle schemas, your raw SQL files, and your migration directories. Our extension completes the picture by giving the editor a live connection to the actual database.

Here’s where they intersect:

Schema explorer in your sidebar: browse tables, columns, indexes, and functions without leaving the editor. When Cursor’s agent asks “what columns does the users table have?”, the answer is already visible.

Screenshot: Object Explorer sidebar showing tables, columns, and indexes expanded

Connection-aware IntelliSense: autocomplete table names, column names, and functions based on your live database schema. This pairs naturally with Cursor’s Tab completions: the AI writes the application logic, and IntelliSense validates the SQL.

Inline EXPLAIN diagnostics: catch performance issues before they ship. Write a query and see whether it uses an index or triggers a sequential scan, all without running a separate tool.

Zero-config connection discovery: we detect .env files, docker-compose.yml, and ORM connection strings in your project. Your database connection follows your workspace, not a global settings file buried three menus deep.

Result export and inline execution: select SQL, run it, and see results in a clean panel. Export to JSON or CSV when you need to share findings with your team.

Features that make Cursor + PostgreSQL even better

Beyond the basics, the extension includes capabilities that pair especially well with AI-powered workflows:

MCP server for AI assistants: the extension registers a Model Context Protocol (MCP) server, so Cursor’s agent can discover and interact with your PostgreSQL databases directly through a standardized tool interface. Ask your AI assistant to inspect a table, run a diagnostic query, or analyze a plan: it has the tools to do it.

Agent Mode database tools: dedicated DBAgent MCP tools give AI assistants richer database-analysis capabilities, from schema introspection to performance diagnostics and instruction management.

Query plan visualization: explore EXPLAIN output in four synchronized views: an interactive node graph, icicle chart, sortable table, and raw source. Color-coded severity groups expose bottlenecks at a glance, and AI-assisted analysis provides optimization suggestions.

Performance dashboard: investigate database performance with DB load charts, query activity, wait-event analysis, session health, and blocking chains. Use natural language to inspect trends, identify bottlenecks, and generate diagnostic SQL.

Object Explorer search: find database objects by name without expanding the tree. Search across connections, databases, and schemas. Filter by object type or schema name and navigate directly to any result.

Schema-aware “New Query”: right-click a schema in Object Explorer to open a new query with the appropriate search_path already set. No more manual SET search_path before writing queries.

Multi-source connection profiles: save connection profiles to your user settings, workspace, or folder. Check workspace profiles into source control so every team member gets the right database connections when they open the project.

SSH tunneling built in: connect to databases on private networks through SSH tunnels configured directly in the connection dialog, with ssh-agent support for private key authentication.

Built for how you actually work

Modern development means ephemeral environments, branch-specific databases, and containers everywhere. The extension is designed around this reality:

Automatic detection of PostgreSQL instances running in Docker

Project-scoped connections that travel with your workspace

Support for standard PostgreSQL connections

Integration with both local and cloud versions of PostgreSQL from multiple vendors, and first-class support for Azure Database for PostgreSQL and Azure HorizonDB, with provisioning, backup management, and network configuration: all without leaving the editor.

Status bar indicator showing your active database at a glance

Get started

Install from the Open VSX Registry: search for it in Cursor’s extension panel or install the .vsix directly. Your existing VS Code workflow carries over unchanged.

If you’re already using Cursor for its agentic capabilities, adding database awareness to the editor means fewer tabs, fewer context switches, and a tighter feedback loop between your application code and the data layer underneath it.

Available now on Open VSX. Works with Cursor, Antigravity, and all the VS Code compatible editors.

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, 02 Jun 2026 18:26:52 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

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

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