Microsoft Blog for PostgreSQL articles

Build a Knowledge Graph in Azure HorizonDB with AI Functions and Apache AGE

Aditi_Gupta — Thu, 11 Jun 2026 17:42:46 GMT

Knowledge graphs appear in every AI architecture diagram, every conference keynote and every AI strategy deck. Yet the most common question we hear from customers and engineers alike is: "What does a knowledge graph actually do for me?"

That is a fair question, and one worth answering clearly, because most teams already have a knowledge graph problem and do not realize it.

The connections your relational tables cannot surface

Picture this: five incident tickets land over a week. One says the auth service returned 503s after an API gateway update, which broke checkout. Another says the payment service lost connectivity to fraud detection through a DNS failure. A third says auth got rate-limited by that same API gateway after a config change.

Each ticket makes sense on its own. But no one in your postmortem can answer: "What upstream services most commonly trigger failures that reach checkout?" That question requires tracing relationships across tickets, teams, services, and root causes. Your relational tables store the facts. They do not store the connections between them. That is a knowledge graph problem.

What becomes queryable once you have a knowledge graph

Once you build a graph from those tickets, every node is an entity (a service, a team, an incident) and every edge is a relationship (CAUSED_FAILURE_IN, OPERATES_ON, INVOLVES). The graph does not just store data differently. It makes a new class of questions answerable:

What is the most common upstream cause of checkout failures?
Which team resolves the most cross-service incidents?
Show me every cascading failure chain that touched the payment service in the last 90 days.
What is the timeline of incidents involving the same shared service?

Each of these questions can be answered with a single Cypher query, without nested subqueries, recursive CTEs, or manually correlating data across spreadsheets.

Why graph-augmented RAG needs a knowledge graph first

Traditional RAG retrieves chunks of text by vector similarity. It works well when the answer lives in a single document. It falls apart when the answer requires connecting facts across multiple documents. Ask "does this contract conflict with existing obligations?" and vector search returns a relevant clause. But it cannot follow links across regions, obligation types, and counterparties to prove a real conflict.

Graph-augmented RAG combines vector search, semantic ranking, and graph traversal into one retrieval pipeline. The graph provides the structural context that vector search alone cannot: the actual chain of cause and effect, not just the five most similar paragraphs.

But here is the catch most people miss: you cannot run graph-augmented RAG without a knowledge graph. And building the graph has always been the hard part. That is exactly what the new tutorial solves.

Building a knowledge graph in five steps inside Azure HorizonDB

We published a hands-on tutorial on Microsoft Learn that takes you from raw incident tickets to a connected, queryable knowledge graph. No external NLP pipelines. No separate graph database. Just SQL.

Here is the pipeline:

Extract entities and relationships from unstructured text with azure_ai.extract(). The LLM parses services, teams, root causes, and relationship triples in one SQL call.
Deduplicate entities with azure_ai.generate() using structured JSON output. "API gateway," "api-gateway," and "the gateway service" collapse into one canonical node.
Load into an Apache AGE graph using Cypher MERGE in PL/pgSQL loops. The tutorial builds service nodes, team nodes, incident hub nodes, all six relationship types, and a timeline chain linking incidents chronologically.
Query with Cypher traversals. Variable-length path patterns like *1..3 trace cascading failure chains up to three hops deep.
Visualize results in the PostgreSQL extension for VS Code, which renders Cypher output as an interactive node-edge graph.

The tutorial walks through every SQL statement, explains the tricky parts (like why EXECUTE format() is needed for parameterized Cypher, and how CROSS JOIN LATERAL expands team-service pairs correctly), and shows the exact output at each step.

The same pipeline applied to any domain

The tutorial uses incident tickets to keep things concrete. But the pipeline applies to any domain:

Domain	Key Entities	Question It Answers
Contract intelligence	Parties, clauses, obligations	Does this new vendor contract conflict with existing obligations?
E-commerce product catalog	Products, categories, customers, orders	What do customers who bought X typically buy next?
Fraud detection	Accounts, transactions, devices, IP addresses	Which accounts are connected through shared devices and circular transfers?
Healthcare clinical data	Patients, medications, conditions, providers	Does this new prescription conflict with existing medications?
Codebase dependency analysis	Tables, functions, views, triggers	If I alter this table, which downstream views and functions break?
Supply chain	Suppliers, components, facilities	Which tier-2 suppliers are single points of failure?
Research knowledge base	Papers, authors, concepts	What evidence chain supports this treatment for condition X?
Data lineage and ETL	Sources, transformations, dashboards	If this source schema changes, which dashboards break?
Identity and access management	Users, groups, roles, resources	Which users have transitive access to production through nested groups?
Regulatory compliance	Regulations, controls, systems	If this regulation changes, which controls need updating?
Customer 360	Customers, interactions, campaigns	What sequence of touchpoints leads to churn for enterprise accounts?
Insurance claims	Claimants, policies, events, providers	Which claims share overlapping parties or event timelines?
M&A due diligence	Companies, IP assets, contracts, liabilities	What hidden liabilities are linked to this acquisition target?

In every case, the shape is the same: azure_ai.extract() discovers the entities, azure_ai.generate() deduplicates them, and AGE stores and traverses the graph.

Get started

Tutorial: Build a knowledge graph from unstructured text using AI Functions and Apache AGE
Knowledge graph enhanced search: Graph-augmented RAG patterns for Azure HorizonDB
Solution accelerators: GraphRAG Legal Research Copilot, GraphRAG with Docker and AI Agents

We would love to hear what you build. Share your feedback on the PostgreSQL Hub developer forum.

Thank you!

Last Call: Join Live the PostgreSQL Community at POSETTE: An Event for Postgres 2026 (T‑1 week)

scoriani — Thu, 11 Jun 2026 09:09:00 GMT

In just one week, the PostgreSQL community gathers again for one of the most anticipated global moments of the year: POSETTE: An Event for Postgres 2026. From June 16–18, this free and fully virtual event brings together PostgreSQL contributors, engineers, architects, and practitioners across 4 livestreams, 44 talks, and 50 speakers.

But you might be wondering, why should I participate in POSETTE during the livestreams? Why join it live?

Explore the schedule and choose your livestreams on the official site:
Join POSETTE: An Event for Postgres 2026

Why joining live makes all the difference

Yes, every talk will be available afterward. But the real value of POSETTE: An Event for Postgres 2026 happens while it is unfolding live.

Be part of the virtual hallway track

Participating live gives you access to the #posetteconf Discord channel, where attendees and speakers interact in real time, asking questions, sharing perspectives, and comparing approaches.

This is where conversations extend beyond the talks and where ideas are challenged and refined collectively.

Learn and validate your thinking in real time

POSETTE is not just about listening. It is about sharpening how you think about PostgreSQL:

Are you partitioning effectively?

Are you approaching replication with the right mental model?

Are your performance strategies aligned with how PostgreSQL actually behaves?

Joining live means you can test those ideas immediately with people who build and run PostgreSQL systems at scale.

Connect with practitioners solving the same problems

A recurring insight from POSETTE participants is how often they discover others facing the same challenges, whether around scaling, performance, or operability.

That shared experience often leads to the most valuable takeaways: not just what works, but why.

What makes this year’s speakers worth your time

POSETTE: An Event for Postgres 2026 brings together a diverse set of voices:

PostgreSQL core contributors

Engineers and architects working on production systems

Specialists in performance, replication, and security

Developers shaping how PostgreSQL is used in modern applications

Azure Database for PostgreSQL and Azure HorizonDB engineers and experts

These are practitioners who have built, debugged, and scaled real systems, and who are ready to share what they learned.

Learn directly from the POSETTE speakers who are shaping PostgreSQL

Bruce Momjian: understanding PostgreSQL from the inside out

Read Bruce Momjian’s interview

Bruce Momjian, a co-founder and core member of the PostgreSQL Global Development Group, has spent decades helping people understand how PostgreSQL really works. His session on the write-ahead log (WAL) reflects that same focus: taking something fundamental but often misunderstood and making it approachable.

If you want to move beyond “using” PostgreSQL and start truly understanding its internals, how durability, recovery, and replication actually function, this is a rare opportunity to learn directly from someone who has helped build the system.

Chris Ellis: making PostgreSQL practical for developers

Read Chris Ellis’s interview

Chris Ellis focuses on how to turn PostgreSQL’s extensive feature set into practical design choices. His session on design patterns highlights a reality many developers face: PostgreSQL offers powerful primitives, but knowing how to combine them effectively is what makes the difference.

His work consistently centers on simplifying application architecture by using the database well, rather than pushing complexity into application code.

Chun Lin Goh: understanding performance in real environments

Read Chun Lin Goh’s interview

Chun Lin Goh brings a cloud architecture and observability perspective to PostgreSQL performance. His session on performance degradation in burstable environments shows how the database behaves under real-world infrastructure constraints.

This is especially relevant if you run PostgreSQL in cloud environments, where system behaviour, not just query design,can have a major impact.

Derk van Veen: lessons from real-world partitioning

Read Derk van Veen’s interview

Derk van Veen’s work is grounded in hands-on experience operating PostgreSQL at scale. His partitioning session focuses not just on how to do things right, but also on what can go wrong,and why.

Partitioning decisions often look simple early on but have long-term consequences. Learning from real mistakes and trade-offs is what makes these sessions so valuable.

Hari Kiran: thinking deeply about replication

Read Hari Kiran’s interview

Hari Kiran’s session explores logical decoding and replication, two foundational aspects of how PostgreSQL systems scale and integrate with other systems.

If your work involves distributed systems, data pipelines, or event-driven architectures, understanding these mechanics is essential.

Jimmy Angelakos: uncovering subtle behavior

Read Jimmy Angelakos’s interview

Jimmy Angelakos focuses on practical, often overlooked aspects of PostgreSQL behavior. His session on NOTIFY highlights how features that seem simple on the surface can introduce complexity in real systems.

These are exactly the kinds of nuances that can save hours or days of debugging in production.

Sakshi Nasha: securing PostgreSQL for production

Read Sakshi Nasha’s interview

Sakshi Nasha’s work emphasizes security and production readiness. Her session on securing PostgreSQL reflects a broader shift: as PostgreSQL becomes central to more systems, security needs to be built in from the start.

Her perspective is especially relevant for teams moving from development environments into production systems.

Taiob Ali: connecting community and real-world usage

Read Taiob Ali’s interview

Taiob Ali brings a strong community-driven perspective to PostgreSQL, shaped by experience as both a practitioner and an advocate.

Sessions like his often help bridge the gap between concepts and how PostgreSQL is actually used across different teams and environments.

Xuneng Zhou: an independent perspective from the ecosystem

Read Xuneng Zhou’s interview

As an independent PostgreSQL hacker, Xuneng Zhou represents a perspective deeply rooted in the open source ecosystem itself.

That viewpoint often brings a focus on fundamentals, experimentation, and how PostgreSQL evolves over time, valuable context for anyone who wants to understand not just where PostgreSQL is today, but where it is heading.

This is more than a conference

POSETTE: An Event for Postgres 2026 is a shared moment for the PostgreSQL community.

It is an opportunity to:

Learn from practitioners and contributors

Challenge assumptions and refine your thinking

Understand where PostgreSQL is heading next

Stepping into the livestream is not just about attending talks, it is about participating in that moment.

Your next step: join live

If PostgreSQL is part of your work, or becoming central to it, the best way to experience POSETTE: An Event for Postgres 2026 is live.

Pick the sessions that matter to you.
Add the livestreams to your calendar.
Join the discussion as it happens.

Start here:
Check out the POSETTE schedule to figure out which livestreams & which talks are for you.

For any other answer you may still have, don't forget to take a look at the Ultimate Guide to POSETTE: An Event for Postgres 2026

See you live at POSETTE

Whether you are exploring PostgreSQL internals, building modern applications, or scaling production systems, POSETTE: An Event for Postgres 2026 is where those conversations come together.

See you at POSETTE on 16-18 June 2026.

What's new with Postgres at Microsoft, 2026 edition

clairegiordano — Thu, 11 Jun 2026 08:29:30 GMT

A lot has happened with Postgres at Microsoft over the past year. This is the 2026 edition of our annual “what’s new” blog post, with highlights from the past 12–13 months—across both our managed services on Azure and our work in the upstream open source project.

The infographic below pulls it all together—feature updates, new capabilities, and ongoing investments across our Postgres workstreams. You might notice it looks a bit different compared to last year: we redesigned the infographic to make space for two new sections—Azure HorizonDB (Preview) and Developer Tools.

The table of contents follows the structure of the hand-made infographic, with each bullet linking to that section. Jump to what you care about, or settle in ☕️ and read the whole thing.

Azure Database for PostgreSQL flexible server
Azure HorizonDB
Developer Tools
PostgreSQL core
Citus open source
Postgres Community

Figure 1: This infographic maps out the major workstreams across Microsoft’s Postgres efforts as of June 2026—from the managed database services on Azure, to VS Code and Cursor, to upstream contributions to the Postgres open source project. For much of the open source work, our contributions to PostgreSQL involve collaboration with people across the global PostgreSQL community, both inside and outside Microsoft.

Azure Database for PostgreSQL flexible server

Azure Database for PostgreSQL flexible server is a managed database service on Azure that meets the needs of large enterprises, small to medium-sized businesses, and early-stage startups. Flexible Server continues to grow in capability month over month, as evident in the monthly “feature recap” blog posts on Microsoft Tech Community (props to Gauri Kasar for publishing these) in June 2025, July, August, September, October, November, January 2026, February, March, April.

TIP ON NAMING: Throughout this post, we sometimes use the full name—Azure Database for PostgreSQL flexible server—and sometimes we just say “Flexible Server” for short. They mean the same thing. You might notice we use the two names interchangeably, so am flagging it here to avoid any confusion.

Performance & Scalability

Premium SSDv2 storage: With the general availability of Premium SSDv2 storage, significant performance and cost-efficiency improvements are now available for IO-intensive workloads. With SSDv2, storage and performance can be scaled independently so you only pay for what you use. Premium SSDv2 adds flexible server storage scaling up to 64TB, with up to 80,000 IOPS and 1,200 MiB/s throughput. (link to docs)
Elastic Clusters support for Terraform, Bicep, & Ansible: With the general availability of Elastic clusters, flexible server added built-in support for row-level and schema-level sharding of data across a cluster of servers. Built-on Citus open-source technology, elastic clusters provides horizontal scaling of workloads with all the enterprise features of flexible server. We’ve added infra-as-code support to deploy elastic clusters from Terraform, Bicep, and Ansible. (link to docs)
Cascading read replicas: With the general availability of cascading read replicas, you can not only create read replicas from the primary, but from other replicas too—enabling up to 30 replicas, more efficient distribution of read traffic, and more flexibility for complex deployment topologies. (link to docs)
Intel & AMD v6 series SKUs: The Intel & AMD v6 General Purpose and Memory Optimized SKUs deliver 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. Using the NVMe protocol for data disk access you can leverage the maximum IOPS and throughput from high performance IO options like SSDv2. (link to docs)
New Azure Advisor performance recommendations: Azure Advisor provides proactive performance, resiliency, and security recommendations for your workloads. We added Index scan insights to improve query efficiency, audit logging review to identify excessive logging, statistics monitoring with alerts on statistics resets, storage optimization recommendations, and connection management guidance. (link to docs)
PgBouncer upgrades: PgBouncer is the built-in connection pooling feature for flexible server, providing the ability to scale to thousands of connections. Upgrading to 1.25.1 added enhanced protocol handling and important stability and security fixes. (link to docs)
pg_duckdb extension (Preview): The pg_duckdb extension combines PostgreSQL’s transactional performance and reliability with DuckDB’s analytical speed for large datasets. This makes a great combination for hybrid OLTP and OLAP environments where you need to run analytical queries directly in PostgreSQL without compromising on performance. (link to demo video)

pg_ivm extension: The pg_ivm extension implements Incremental View Maintenance (IVM), allowing materialized views to by updated more efficiently by only applying incremental changes when the underlying data changes—resulting in improved performance for large datasets where only a small subset of the data is modified. (link to repo)

Manageability

Built-in Grafana monitoring dashboard: Grafana dashboards for your flexible server instances are now readily available from the Azure Portal in your Azure Database for PostgreSQL view. You can now visualize metrics and logs, correlate events by timestamp, and rapidly gain insights into performance, query behavior, and availability with built-in dashboards. (link to blog)
Maintenance payload visibility: Maintenance updates to flexible server can include PostgreSQL minor version updates, security fixes, bug fixes and new functionality. It’s important to know what’s changing so you know what to expect, what improvements you can take advantage of, and whether to flag any concerns. You can now access the release notes for maintenance updates. (link to docs)
Defer maintenance & Maintenance on demand: Using Custom Maintenance Windows (CMW) and System-managed Maintenance Windows (SMW) gives you control over when to apply flexible server maintenance updates. We’ve expanded that control with the ability to defer an upcoming maintenance update by up to 2 weeks, or to apply one on demand. These new options are available in the Azure Portal, with CLI and API support coming soon. (link to docs)
PostgreSQL 18 (w/MVU & Terraform support): PostgreSQL 18 was made available on Azure on the same day as the community release, with a host of performance and security improvements . PG18 general availability added support for all Azure public regions, Major Version Upgrade, Entra ID authentication, and Terraform support. (link to blog)
5 new regions added: Austria East, Denmark East, Indonesia Central, Malaysia West, Chile Central: New Azure regions for flexible server are continually being added in response to customer demand. You can check out the region availability list to stay up to date with supported regions. (link to docs)
HA expansion: Japan West: Existing regions are also being retrofitted to add availability zones which support zone-redundant High Availability. In this timeframe, we’ve added support for multi-zone deployment in Japan West. (link to docs)

Resiliency

Zonal resiliency HA setting: Zone-redundant high Availability (HA) is the recommended and default HA configuration for maximum resiliency. The Azure Portal now includes a Zonal Resiliency setting that lets you select same-zone HA if a region doesn’t support zone-redundant HA—with automatic migration once capacity becomes available. (link to docs)
Near-zero downtime scaling for HA-enabled servers: This feature minimizes downtime when you modify the storage and compute tiers. Scaling operations such as vCore or Compute tier operations can now HA failovers to maintain the connection string, reducing downtime to typically under 30 seconds. You don’t need to take any action to use this feature. (link to docs)
Long term backups: Backups with Long Term Retention (LTR) enable you to keep backups for up to 10 years, enabling you to meet regulatory and audit-driven requirements for long-term data retention. (link to docs)
Logical replication slot synchronization metric: A new metric called logical_replication_slot_sync_status provides a binary signal to indicate whether logical replication slots are synchronized across High Availability (HA) primary and standby nodes. This adds a clear signal for failover readiness to help with scenarios where data continuity during failover is critical. (link to docs)

Security and networking

Azure Confidential Computing: PostgreSQL flexible server instances can now run on Confidential Virtual Machines (CVMs) inside a Trusted Execution Environment (TEE)—a secure, isolated enclave with encrypted memory, enabling end-to-end security and enhanced privacy to meet the strictest security standards for regulated workloads. (link to docs)
Entra ID group login using user credentials: You can authenticate to Azure Database for PostgreSQL with your Entra ID as a member of a Microsoft Entra group by creating a group principal. Managed identities and service principals are also supported as group members. (link to docs)
Entra ID token refresh libraries for .NET, Python, Java: Using Entra ID for authentication throughout your application supports an identity-based security perimeter, simplifying how applications authenticate with Azure Database for PostgreSQL, but it also means your application needs to handle additional complexities like Entra token refresh. These libraries take care of the token refresh logic, making it easy to add token refresh support to your applications with minimal code changes. (link to libraries .NET, JavaScript, and Python)
Credcheck, anon, ip4r extensions: We onboarded several extensions over the last year that help with compliance and regulatory requirements, including:
- anon: GA of the upgraded anon extension, adding support for dynamic and static masking, anonymized exports, randonmization, and other advanced masking techniques.
- credcheck: The credcheck extension adds credential checks for usernames and password complexity.
- ip4r: The ip4r extension provides a set of data types for Ipv4 and Ipv6 network addresses which are useful for auditing, compliance, and intrusion detection. (link to docs: anon, credcheck, IP4R)
Priority connectivity for azure_pg_admin users: The azure_pg_admin role provides a way to perform privileged administrator operations without access to the superuser role, reducing the risk of privilege escalation. This role was updated to work with PG16’s stricter role hierarchy, allowing management of objects owned by any non-restricted role. It also ensures that at least one database connection is always available to admin users—even when the client connection pool is full—helping prevent lockout situations and making troubleshooting easier. (link to docs)
Defender security assessments (Preview): Two new Microsoft Defender for Cloud CSPM security recommendations for flexible server are now availability:
- Geo-redundant backups should be enabled for PostgreSQL Servers, and
- require_secure_transport should be set to "on" for PostgreSQL Servers
These assessments evaluate database configuration settings against recommended security practices, helping you manage risk and align with internal and industry standards. Additional security assessments will be added over time. (link to new recommendations)
VNET to Private Link migration (Preview): Previously, it wasn’t possible to migrate servers deployed inside a VNET to an updated secure network configuration based on Private Endpoint connectivity, which is simpler and more scalable. With the VNET to Private endpoint migration preview, you can use the Azure CLI, API or SDK to migrate your server without needing to recreate it. (link to docs)
Extended CVE support for PG11, 12, 13: If you’re running a PostgreSQL version in flexible server that is no longer community supported like PG11, 12, or 13, it will continue to be patched with high priority CVEs for 3 years after the community retirement data as part of Azure Database for PostgreSQL extended support. (link to docs)

Integration

Mirroring data to Microsoft Fabric: The general availability of Fabric mirroring in flexible server opens up near real-time replication of data from Azure Database for PostgreSQL to Microsoft Fabric—enabling the advanced analytics and reporting capabilities of Fabric without the need for extensive ETL. It also means your PostgreSQL server is free to run mission-critical transactional workloads without being affected by spikes in analytical reporting. (link to docs)
Ansible module update: A new version of the Ansible collection for flexible server was released, adding support for support for Elastic clusters, PG18, virtual endpoints, on-demand backups, system-assigned identity, storage auto-grow, read replica switchover and more. (link to docs)
Updated Go, Java, JavaScript, .NET & Python SDKs: The udpated SDKs for performance flexible server operations add PG18 support, improved Elastic cluster features and improved response codes. (link to SDKs: .NET, Go, Java, Javascript, Python)
Upsert and Script activity in ADF and Azure Synapse: New capabilities were provided to make merging data into existing tables easier with the Upsert method, and to run custom SQL scripts as part of workflows enabled more streamlined ETL processes with Azure Data Factory and Azure Synapse. (link to Upsert Methodand script activity docs)
Stable REST API release for 2025: The 2025-08-01 stable REST API release for Azure Database for PostgreSQL added support for the latest PostgreSQL major versions, Elastic Cluster and CMK enhancements. (link to released APIs)
Azure Storage extension Parquet support: Parquet is a popular columnar storage format that is widely used in big data and analytics environments. With Parquet support in azure_storage, you can now perform direct SQL-based reads and writes to Parquet files in azure_storage, making it easy to import and export data to and from PostgreSQL without needing external tools or scripts. (link to docs)

Migration service in Azure Database for PostgreSQL

AI-assisted Oracle to PostgreSQL migration tool: Migration from one database type to another has traditionally been a complex, time-consuming and costly project. The emergence of AI-assisted migration tooling has dramatically reduced this cost. The AI-assisted migration tooling available with the VS Code PostgreSQL extension converts Oracle schema and application code to Azure Database for PostgreSQL flexible server. This tooling leverages GitHub Copilot, Microsoft Foundry, and custom Language Model tools to convert Oracle schema, database code and client applications into PostgreSQL-compatible formats and validates every change against a running flexible server instance. (Link to schema conversion docs, link to app conversion docs)
Azure Migrate discovery & assessment: The first step in a database migration process is Discovery: understanding what you’re running and the state of migration readiness. Azure Migrate now provides PostgreSQL discovery and assessment to report on your on-prem PostgreSQL landscape, identify potential migration blockers, and learn tailored SKU and cost insights with a streamlined migration assessment. (link to docs)
Migration with pgoutput plugin: Online migration to flexible server became generally available last June and we’ve continued to improve it. You can now leverage pgoutput (used by PostgreSQL’s logical replication framework) for online migration with improved reliability and performance. The update provides improved compatibility with modern PostgreSQL deployments and reduces dependency on legacy decoding mechanisms, enabling functionality like fine-grained filtering using Publications, allowing migration of specific tables and filtering by operations. (link to docs)
AlloyDB & EDB migration sources: You can now migrate directly from AlloyDB and EDB Extended Server to PostgreSQL using the Azure Database for PostgreSQL Migration Service, with both online and offline migration support. (link to docs: AlloyDB, EDB)

AI capabilities in Flexible Server

AI Functions (Preview): AI Functions add extraction, generation, classification, and re-ranking directly into SQL through the azure_ai extension using an Azure OpenAI or Microsoft Foundry model. It replaces hundreds of lines of Python glue with a one-line SQL call. (link to docs)
pgvector 0.8.2 support: pgvector 0.8.2, focuses on stabilizing parallel HNSW index builds, fixing correctness issues and improving reliability, all important steps toward production-grade vector search. (link to docs)
Microsoft Foundry integration (Preview): We've shipped a PostgreSQL connector for Microsoft Foundry built on the Model Context Protocol (MCP). Foundry agents can now explore your Postgres schema, retrieve records, run analytical queries, and perform vector similarity searches in natural language, secured by Microsoft Entra ID (link to docs)
LangGraph/LangChain connector: The new native Azure Database for PostgreSQL connector for both frameworks gives agents first-class vector retrieval, checkpointing, and conversational memory backed by your Postgres instance with Entra ID authentication and production-grade reliability out of the box. (link to blog)
Apache AGE extension support: Apache AGE is now supported on Azure Database for PostgreSQL, bringing graph queries to the same database that already holds your relational tables, JSON, vectors, and full-text indexes. (link to blog)

Try it out: Quickstart for Azure Database for PostgreSQL

The Quickstart: Create an Azure Database for PostgreSQL flexible server docs page walks you through how to get started deploying your own flexible server instance, including a link to a free Azure trial account.

Our Postgres team is hiring!

If you’re a deep Postgres expert—or a strong Linux systems engineer—this might be your moment. We’re continuing to grow the Postgres team at Microsoft. (link to Principal Software Engineer role; and link to Software Engineer II role)

As Affan Dar, the VP of Engineering for Postgres at Microsoft says all the time:

“We are always looking for strong Linux systems engineers and PostgreSQL experts to help us build the future of Postgres at Microsoft.”

Azure HorizonDB (Preview)

Azure HorizonDB launched in private preview last November, and at Microsoft Build in May 2026 we announced the public preview. If you want a quick overview, the excerpt below from the announcement blog post is a good place to start—or you can dive straight into some of the key HorizonDB features further down.

"Azure HorizonDB is built to meet the demands of security, resilience, scale, and performance—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.

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."

—Excerpted from "Azure HorizonDB: Enterprise-Ready Postgres, Engineered for the AI Era" announcement blog post

Low latency commits: The architecture of Azure HorizonDB (Preview) separates compute and storage, so storage is shared by all compute nodes. This shared storage architecture enables low-latency, millisecond commits within region providing critical support for tier-1, performance-sensitive workloads. (link to docs)
Scale up to 192 Cores: Azure HorizonDB supports compute scaling up to 192 cores for both primary and replica instances, enabling the capacity needed to handle workload spikes. (link to docs)
Read scale-out with 15 replicas: Support for up to 15 read replicas, with read connections automatically load-balanced across them to efficiently scale out read workloads. (link to docs)
Autoscaling storage up to 128 TB: Support for storage auto-scaling up to 128 TB, eliminating the need to pre-provision storage size. Storage automatically shrinks as your data footprint decreases. (link to docs)
Zone resilient storage: Azure HorizonDB leverages Azure Blob Storage, which is zone-resilient by default, to ensure zero data loss. (link to docs)
Entra ID Authentication: Azure HorizonDB provides native integration with Microsoft Entra ID, enabling centralized identity and access management for PostgreSQL workloads. This integration supports secure, token-based authentication while allowing organizations to enforce enterprise security policies such as multi-factor authentication and conditional access.
Private Endpoints : Azure HorizonDB supports Azure Private Endpoints, ensuring that database connectivity remains entirely within a customer’s private Azure VNET boundary. This capability minimizes exposure to the public internet and helps organizations satisfy stringent security, compliance, and regulatory requirements.
Mirroring to Microsoft Fabric: Azure HorizonDB includes native mirroring to Microsoft Fabric, enabling near real-time replication of operational PostgreSQL data into analytics-ready OneLake storage. This capability simplifies modern analytics architectures by reducing dependency on complex ETL pipelines while supporting scalable BI, AI, and data engineering workloads.
~75 popular Postgres extensions: Azure HorizonDB is fully PostgreSQL-compatible and supports approximately ~75 popular extensions such as pg_stat_statements, auto_explain, pg_duckdb, pg_diskann. It will continue to expand support for additional extensions, including both PostgreSQL and Azure-specific offerings such as AI extensions. (link to docs)
Full-text search with BM25 ranking (pg_textsearch): pg_textsearch brings BM25 the same relevance algorithm behind every major search engine directly into HorizonDB as a native extension. BM25 offers better relevance than PostgreSQL's built-in ts_rank, and you can combine it with vector search in one SQL query for true hybrid retrieval. (link to docs)
DiskANN Advanced filtering: DiskANN Advanced Filtering offers lower latency on filtered vector search compared to traditional approaches, so a query like "find the most similar products under $50 in the Electronics category" runs at full DiskANN speed. (link to docs)
AI model management: AI Model Management in Azure HorizonDB simplifies how you bring AI into your database. With a single step, it provisions fully managed AI models for embeddings, semantic ranking, and generation through Microsoft Foundry—and installs and configures the azure_ai extension to enable AI functions like generate(), extract(), create_embeddings(), and rank() for immediate use directly in SQL. This removes the need for manual setup and context switching, with model provisioning, management, monitoring, and billing handled seamlessly within HorizonDB. (link to docs)
AI pipelines: AI Pipelines let you describe an AI workflow (chunking, embedding, extraction, generation, ranking, human approval) declaratively in SQL, and run it as a fault-tolerant pipeline that lives inside the database built on pg_durable. (link to docs)
Durable functions (pg_durable): pg_durable is an open source extension that lets you describe long-running workflows such as sequential steps, parallel fan-out, scheduled jobs, human-in-the-loop, and retries declaratively in SQL. And then you can run them as fault-tolerant durable functions that live inside the database. (link to GitHub Repo)

BACKSTORY: Beyond features, if you want to learn more about the story behind Azure HorizonDB, listen to the Talking Postgres podcast episode with guest Adam Prout, one of the founding architects of Azure HorizonDB.

Developer Tools

We launched a new IDE for PostgreSQL in VS Code in May 2025—and the response was strong, including a day at the top of Hacker News and over 170K views of the original blog post. One year later, the extension has more than 560K+ installs, we’ve kept building and adding more capabilities. Below are some of the highlights. We also recently added support for Cursor, available via the Open VSX Registry.

VS Code extension to connect to any Postgres, anywhere: You can connect to any PostgreSQL database directly from the VS Code extension for PostgreSQL—whether it’s running locally, in a container, on-prem, or in any cloud. Connection profiles let you switch between environments without leaving the editor. (link to docs)
One-click Dockerized Postgres + integrated psql: Local development is streamlined through the PostgreSQL extension in VS Code, including quick setup of a PostgreSQL environment and support for familiar tools like psql. This reduces the amount of manual setup needed to start querying. (link to docs)
Object Explorer with cross-database search: Within VS Code, the PostgreSQL extension provides an Object Explorer for browsing tables, views, and functions across databases. You can also search across schemas and databases without manually navigating the full tree. (link to docs)
Schema visualization: Schema visualization is built into the VS Code extension for PostgreSQL, making it easier to understand relationships between tables. This can be especially useful when working with unfamiliar or complex data models (link to docs)
Intellisense query editor with CSV/JSON: The VS Code extension for PostgreSQL includes a query editor with IntelliSense that is schema aware. Query results are returned in a grid and can be exported to formats like CSV or JSON for further analysis. (link to docs)
Query plan visualizer & Copilot analysis: Query plans can be visualized directly in VS Code using the PostgreSQL extension, helping surface bottlenecks and execution details. With GitHub Copilot, you can also get explanations and suggestions for improving query performance. (link to docs)
Apache AGE Cypher graph visualization: Support for Apache AGE allows graph queries to be run and visualized as node-edge diagrams directly in VS Code. This enables exploration of graph data without requiring a separate visualization tool. (link to docs)
Copilot Agent Mode tools (run SQL, design schemas, import CSV): When used with the VS Code extension for PostgreSQL, GitHub Copilot can operate in agent mode to assist with multi-step workflows such as running queries, designing schemas, or importing data. These actions are suggested in natural language while still requiring user confirmation. (link to docs)
Copilot metrics intelligence in Server dashboard: The VS Code extension for PostgreSQL includes server dashboards that surface database performance metrics. GitHub Copilot can help interpret these signals and guide troubleshooting or optimization efforts. (link to docs)
Entra authentication for Azure Database for PostgreSQL: Connections from the VS Code extension for PostgreSQL to Azure Database for PostgreSQL support Microsoft Entra ID authentication. This enables secure, passwordless access directly from the editor. (link to docs)
Azure server browse, create, & manage in-IDE: Azure Database for PostgreSQL resources can be discovered, created, and managed directly within VS Code through the PostgreSQL extension. This reduces the need to switch to the Azure portal for common workflows. (link to docs)
Cursor extension for PostgreSQL: An extension for PostgreSQL is also available in Cursor and other Open VSX-compatible editors, bringing the same database tooling into those environments. In Cursor, these workflows integrate with Cursor’s native AI experience while preserving the core Postgres capabilities. (link to blog post)

Contributing to PostgreSQL core

Microsoft continues to invest in our open-source PostgreSQL contributors team and reaffirms its commitment to open source. The team continues to drive large and ambitious projects in upstream PostgreSQL and make all those features available to all Postgres users.

The team has a broad range of expertise, and our contributions to Postgres span almost all areas in Postgres, including the Query Planner, Executor, Storage/IO subsystems, Security, Operational and Manageability improvements, new SQL features and much more.

Our commitment to supporting Postgres development hasn’t changed since Claire Giordano first wrote this back in August 2023:

In order to thrive, an open source ecosystem needs commercial support as well as volunteer efforts. Even open source developers need to eat! For the Postgres open source ecosystem to flourish, companies like Microsoft need to support the project by funding development in the Postgres core. Which we do.

PostgreSQL is a complex piece of software that runs mission-critical workloads across the globe. To provide the best possible experience on Azure, it follows that we need to thoroughly understand how it works. By having PostgreSQL committers and contributors on our team, they can share knowledge internally across different orgs, or directly answer internal questions regarding incidents or extension development.

Because today's cloud operates at a scale most on-prem solutions never encountered, unique cloud data center problems, often relating to performance, now require special attention. Our in-house team of deep Postgres experts are focused on tackling these cloud-scale issues upstream, in the Postgres core. Another benefit: our team's Postgres expertise gives Azure customers confidence in our cloud database services, too.

Commercial funding of PostgreSQL developers has another benefit: it gives developers the long-term stability to pursue the big things, the groundbreaking changes that are super important to the future. In particular, the Postgres contributor team at Microsoft is focused on some big architectural changes (example: Asynchronous IO) that you wouldn’t be able to do without the funding for a full-time, multi-year effort.

Highlights of our team’s Postgres 19 code contributions (so far!)

Big news: Postgres 19 Beta 1 just released, and PG 19 is expected to GA later this year, likely in September 2026.

Below are highlights from ~440 commits our Microsoft team authored or co-authored (so far) in Postgres 19.

And because attribution matters in open source, it must be said: the Postgres 19 work you’ll see below was done in collaboration with Postgres developers and contributors from around the world—including many outside Microsoft. That’s how the Postgres open source project works. We’re grateful to be part of it.

Figure 2: Team members at Microsoft that contribute to the upstream Postgres open source project.

Performance

Faster Tuple Deformation: This work accelerates scans of tables with many fixed-width columns. The patches add a dedicated fast loop for columns at pre-calculated offsets and a smaller Attribute struct for reduced memory footprint. (link to optimize tuple deformation commit; link to CompactAttribute commit)
Fast path for Foreign Key checks: A committed patch series that adds a faster path for foreign key checks. It avoids SPI by probing the referenced index directly, reuses execution state across trigger batches, and uses array-based index probes to reduce setup overhead. In the common case of bulk inserts into single-column, non-partitioned primary-key tables, it delivers about a 2.9x speedup. (link to commit series)
Faster COPY using SIMD for delimiter matching: The COPY FROM text/CSV parsing was optimized by using SIMD instructions to process input data a chunk at a time, quickly skipping over bytes that don't contain special characters (delimiters, newlines, escapes) rather than checking byte-by-byte in the state machine. The performance speedups can be up to 60% in certain cases, with no regressions. (link to commit)
Parallel TID range scan: The change allows for queries that filter on ctid ranges to be executed by multiple parallel workers. This is particularly useful for logical replication initializers, data migration, and custom ETL scripts. (link to commit)
Improved TS counter for low-overhead EXPLAIN: The commit reduces the overhead of EXPLAIN ANALYZE timing by using the x86 RDTSC instruction directly. This reduces pipeline stalls which dominated the timing cost and makes EXPLAIN ANALYZE much faster. (link to commit)
On-access Visibility Map updates: The change allows us to mark pages all-visible during SELECT queries. This leads to more index-only scans, which previously had to wait for a Vacuum to run, and additionally also results in less I/O needed by Vacuum. (link to commit)
Reduce Vacuum WAL generation: A series of changes to reduce WAL generation by Vacuum and COPY FREEZE. After these commits, we no longer emit separate heap visible WAL records and instead include that information in other existing WAL records, halving the number of WAL records emitted per heap block for both heap vacuuming and COPY FREEZE. This makes vacuum and COPY FREEZE faster and decreases disk space usage. (links to commits: d96f87332b3, add323da40a, 1252a4ee286)

New SQL Features:

SQL/PGQ: SQL Property Graph Queries is Part 16 of the SQL:2023 ISO standard which lets you define graph structures on top of your existing relational tables and query them with a dedicated pattern matching syntax. This is a major new feature, led by Peter Eisentraut along with Ashutosh Bapat from our team. In practical terms, for PostgreSQL, this means you can now express things like social network traversals, dependency graphs, fraud detection paths, or supply chain analysis using concise graph syntax without leaving Postgres, without extensions, and without duplicating your data into a separate graph store. (link to commit)

Operational Improvements:

Automated resizing of AIO workers: The patch automatically adjusts the I/O worker pool size for PostgreSQL's async I/O subsystem, replacing the old fixed io_workers setting with dynamic scaling that grows the pool under load and shrinks it back down after an idle timeout—so you no longer have to guess the right static worker count. (link to commit)
New EXPLAIN (IO) for better IO visibility: The change introduces a new IO option to EXPLAIN, which adds per-scan-node I/O instrumentation to EXPLAIN ANALYZE output. These apply to nodes backed by the ReadStream API’s and reports prefetch queue metrics (average and maximum distance, capacity) and I/O request stats. This gives you direct visibility into how the ReadStream/AIO layer is performing underneath each scan, instead of having to guess from BUFFERS alone. (link to commit)

Security and Reliability:

CVE-2026-2006: The change modified an internal string length function to report ERROR if the input string ends in an incomplete multibyte character. The general philosophy was to raise encoding errors on a just-in-time basis—that is, the low-level multibyte string length functions now actively detect and reject truncated/incomplete characters rather than silently ignoring them. This hardens PostgreSQL's multibyte encoding handling, Incomplete characters in stored data are a sign of corruption or encoding bugs and surfacing them as errors is safer than silently computing wrong character counts. (link to commit)
Online checksum enablement: Enabling checksums to detect data corruption was only available during initdb, or having to shut down the entire cluster and calculating the checksums on all the files. For larger production databases, that downtime is often unacceptable. This change allows you to enable this in a running cluster, and the checksums are calculated in the background. (link to commit)
Server Side SNI support: PostgreSQL 19 adds server-side support for SNI, with a new configuration file $datadir/pg_hosts.conf that specifies the hostname/certificate/key pairs. The server inspects the hostname TLS extension in the SSL handshake and selects the right SSL certificate, key, and CA certificate to use for that connection. This means a single PostgreSQL instance can present different certificates depending on which hostname the client is connecting to. (link to commit)

Groundwork/Futures:

Buffer Mgr Locking improvements: Andres Freund has been working on several improvements in the way buffer management and locking has been done, paving the way to use AIO for writes. The change also now performs buffer page un-lock and un-pin in a single atomic operation, showing some pgbench runs to see up to 25% improvement.
Index Pre-fetching groundwork: Index pre-fetching did not make it for PG19, but a lot of the groundwork has been done in this cycle, including all the major design pieces, preliminary improvements in the AIO infrastructure and mitigation of any performance regressions. The feature is in good shape to land in PG19.
Shared Buffer Elasticity groundwork: Ashutosh and Heikki have worked on improving shared memory management in PG 19. This would help support changing shared-buffers without server restart in a future release. In PG19, extensions using small shared memory structures can be created/loaded after startup without going through shared_preload_libraries and without restarting the server. (link to commit)

The features above capture some highlights of the work done by the team at Microsoft for open-source PostgreSQL, but it’s not a comprehensive list—and certainly doesn’t reflect all the engineering work to review patches and mentor contributors across the project. Let’s look at some numbers:

Microsoft’s code contributions to Postgres 19 (to date) as of 31st May 2026

Code contributions in Postgres 19	440 Commits with Microsoft authors or co-authors	3,088 total commits to PG19 to date (from everyone)	14.2% of commits have code authors from Microsoft
Patch Reviews in Postgres 19	907 Commits with reviews from the Microsoft Team	5,603 total commits to PG18 to date (from everyone)	16.2% of commits had reviews from team @ Microsoft

To interpret the numbers, here are 3 things to keep in mind:

Not all commits are created equal. Some commits are small; others are complex and high-impact. So while commits are a useful signal, they’re not a perfect measure of effort or impact. Still, it’s a metric many people care about, so we’re sharing it.
Many commits have multiple authors (and reviewers): The 440 commits with Microsoft authors in Postgres 19 (as of May 31 2026) were authored by 19 different people on our team. But those commits were often co-authored by other contributors—both inside and outside Microsoft. That’s one of the things I love about the Postgres community: developers collaborating across companies, countries, and continents.
Code is just one part of the story: Code and review contributions are essential to the Postgres project—but they’re not the whole picture. As you’ll see later in this post, our team also contributes in other ways: to extensions like Citus, and to the Postgres Community.

Citus Open Source

The Citus open source extension to Postgres is a good fit for data-intensive applications that need more compute, memory, or scale than a single Postgres node can handle.

With over 12.5K stars on GitHub, Citus is a popular extension that gives Postgres the superpower of distributed tables. You can download Citus open source, or you can use Citus on Azure via the Elastic Clusters feature in Azure Database for PostgreSQL.

New Citus open source features in last 13 months

The Citus open source extension scales out Postgres horizontally, using either row-based sharding or schema-based sharding, or both.

The Release Notes pages for Citus are online—and for Citus major releases you can often find a dedicated blog post as well:

Mehmet Yilmaz’s release blog post titled, Distribute PostgreSQL 18 with Citus 14
Check out the Citus 14.0 release notes that added PG18 support

Here are highlights of new Citus open source capabilities added in the last 13 months:

Citus 13.2, 14.0, and 14.1 releases: You can find the release notes online for Citus 13.2, Citus 14.0, and for the latest release which is actually two paired minor releases, Citus 14.1/13.3.
Postgres 18 support in Citus 14: Citus 14 primarily about PG18 compatibility, with upstream benefits like faster scans and maintenance via AIO; better index usage with skip-scan; uuidv7() for time-ordered UUIDs; OAuth authentication support; and temporal constraints flowing through once compatibility lands. (link to Citus 14.0 release notes)
Snapshot-based node split / faster scale-out: From the release notes, “the snapshot based node-addition feature enables faster scale-out operations by adding a new worker node using a clone of an existing worker node. This significantly reduces rebalance times when adding new nodes to the cluster.” Why? Because the cloned work already contains a copy of the data. (link to release notes)
Faster parallel shard rebalancing: Citus 13.2 explicitly improved rebalancer performance by parallelizing moves and removing logical-replication bottlenecks. (link to release notes)
New Citus observability views/stats: Citus added new observability views and user-defined functions (UDFs) for distributed clusters. Citus 13.1 introduced citus_stat_counters to expose Citus-specific counters collected when citus.enable_stat_counters is enabled; and 13.1 also introduced citus_nodes to show node name, port, role, and active status, as well as supporting UDFs to query/reset counters and identify whether the current node is primary.

Citus 13.2 added citus_stats(), which retrieves distributed pg_stats for a Citus table, giving users more cluster-level visibility into statistics and node state. (link to citus stat counters in release notes; link to citus nodes view in release notes; link to citus_stats view in release notes)
Expanded DDL/role propagation: Citus 13.1 adds support for propagating more DDLS from the coordinator to ease role and database management in a Citus cluster, including support for: GRANT/REVOKE rights on table columns; REASSIGN OWNED BY commands; CREATE/DROP database commands; SECURITY LABEL on tables and columns; ALTER USER RENAME commands; ALTER DATABASE .. SET .. commands; and role management from worker nodes. (link to Citus 13.1 release notes)
Planner/query performance improvements: Citus 13.2 includes outer join pushdown and local fast-path query optimization. (link to outer join pushdown in release notes; link to fast-path query optimization in release notes)

Postgres Community work

Given my role as head of Postgres open source community initiatives at Microsoft, it’s not a surprise: contributing to Postgres is something I care deeply about.

Last year, I gave a talk at PGConf EU that shared an analysis of contributions to Postgres v18, based on research I did with Daniel Gustafsson. And if you’ve ever raced sailboats, you know: every role matters.

One thing I’m quite proud of are the different ways the team at Microsoft contributes to the Postgres ecosystem. This Postgres Contributions infographic—inspired by a hand-drawn sketch by Cornelia Biacsics—shines a light on the ways we’re contributing to this ecosystem.

Figure 3: Infographic of the 8 different ways the team at Microsoft contributes to the Postgres ecosystem, from our Azure managed services to Postgres open-source community contributions.

Highlights from the Postgres community work done by our team at Microsoft

Serve on organizing & talk selection teams for multiple Postgres events: The in-person Postgres community conferences are a great way to learn, share your expertise, and connect with other Postgres people. And if you lean into the “hallway track”, you might be surprised by the doors it can open.

Over the past 13 months, members of our Postgres team at Microsoft have served on the organizing committees or talk selection teams for these 9 Postgres community conferences, in time-order (oldest to most recent):
- PGConf.dev 2025 (Melanie Plageman)
- PGConf NYC 2025 (Daniel Gustafsson)
- PostgreSQL Down Under (PGDU) 2025 (Thomas Munro)
- Prague PostgreSQL Developers Day (P2D2) 2026 (Tomas Vondra)
- FOSSASIA PGDay 2026 (Amit Langote)
- PGConf India 2026 (Thomas Munro)
- Nordic PGDay 2026 (Daniel Gustafsson)
- PostgreSQL Conference Germany 2026 (Cornelia Biacsics)
- PGConf.dev 2026 (Melanie Plageman, Claire Giordano)

Co-organize PGConf.dev annual PostgreSQL development conference: Special shout-out to Melanie Plageman, who is part of the team that organizes PGconf.dev, which in the last 3 years has become a “go to” event. This annual gathering (the successor to PGCon) is unique in how it brings together current and future PostgreSQL hackers from around the world to collaborate in person. (link to PGConfdev 2026 schedule)
Sponsor 16 Postgres conferences around the world: Postgres community conferences don’t just happen—they rely on financial support to bring people together. Over the past 13 months, our team at Microsoft has sponsored these 16 in-person Postgres events:
- PGConf.dev 2025 – Gold
  Hyderabad PG Days 2025 – Sponsor
- PGDay Austria 2025 - Silver
- PGDay UK 2025 – Benefactor
- PGDay Lowlands 2025 – Supporter
- PGDay Napoli 2025 – Supporter
- PGConf NYC 2025 – Platinum
- PGConf EU 2025 in Riga – Gold
- PG Down Under 2025 – Silver
- Prague PostgreSQL Developers Day (P2D2) 2026 – Bronze
- FOSSASIA PGDay 2026 - Silver
- PGConf India 2026 – Diamond
- Nordic PGDay 2026 – Supporter
- PostgreSQL Conference Germany 2026 – Silver
- PGConf.dev 2026 – Gold
- PG DATA 2026 (formerly PGDay Chicago) – Gold
- PGDay Boston 2026 – Silver

Figure 4: Logos of the PostgreSQL community conferences our Microsoft team is proud to have sponsored over the last 12 months—along with thanks and gratitude to the conference organizers for making these events happen.

POSETTE: An Event for Postgres: POSETTE is a free & virtual developer conference organized by our Postgres team at Microsoft. Now in its 5^th year, and aided by the fact that it’s virtual, it’s safe to say POSETTE is the largest Postgres event in the world—bringing together developers, users, contributors, and experts from across the globe to share their knowledge. (link to PosetteConf.com)

Last year’s event in June 2025 was a hit—and you can still watch all of last year’s talks on the POSETTE 2025 playlist on YouTube.

Special thanks to my teammates on the 2026 talk selection team—Daniel Gustafsson, Divya Bhargov, and Melanie Plageman—for reviewing all 238 of this year’s talk proposals. And of course POSETTE 2026 would not be happening without the full organizing team behind POSETTE 2026, nor without the partnership and financial support from AMD.

Looking ahead, POSETTE 2026 is coming up soon: 16-18 Jun, online. With 4 livestreams, 2 keynotes, 44 talks, and 50 speakers, there’s something for everyone.
- Check out the schedule on the PosetteConf website.
- Register: To make sure you don’t get doublebooked, register for the POSETTE 2026 livestream(s) that works for you:
  - Livestream 1 / Livestream 2 / Livestream 3 / Livestream 4
- If you attend live, the benefit is: you’ll be able to ask the speakers questions in the text chat on Discord while the talks are being livestreamed—and be part of the conversation. It’s a good way to connect with the speakers and the community.
- Can’t make it live? No problem, you can always catch the 2026 talks later on YouTube.

Figure 5: POSETTE: An Event for Postgres 2026 is a free and virtual developer event, organized by our Postgres team at Microsoft and now in its 5^th year. This graphic gives you a map of the 44 talks in POSETTE 2026, from the keynotes to the Postgres core talks, Postgres ecosystem talks, and Azure Database talks too.

Talking Postgres podcast: Hard to believe, but our monthly podcast is now over 3 years old—with 39 episodes published as of the date of writing. Focused on the human side of Postgres, the conversations dig into why people who work with Postgres do what they do—and how they got to where they are. (link to podcast)

In the past year alone, I’ve had the chance to talk with these amazing people: Adam Prout, Andres Freund, Boriss Mejías, Charles Feddersen, Gwen Shapira, Melanie Plageman, Rob Emanuele, Shireesh Thota, Simon Willison, Tomas Vondra, Luigi Nardi, Peter Cooper, and Peter Farkas.

You can find all episodes at Talking Postgres.com, on the YouTube playlist, or wherever you get your podcasts. Bonus: we record episodes live on the Microsoft Open Source Discord, where you can join the parallel live text chat during the show. It’s a fun way to connect with the community in real time.
Deliver 63 conference talks at Postgres events: Both in-person and virtually, our Postgres teams have been sharing their expertise with the user and developer community on the conference circuit—delivering 63 talks in the last 13 months.
Organize Postgres user groups & meetups: User groups and meetups are a great way to learn and meet other Postgres users and contributors—but it takes work to make it all happen: to find locations, line up speakers, organize food and drink, and get the word out.

+1 to those on our team at Microsoft—and to everyone—who volunteer their time and partner with others in the Postgres community to help organize local Postgres user groups, including:
- Malmö PostgreSQL User Group (M-PUG): Daniel Gustafsson (link to meetup)
- Prague PostgreSQL Meetup: Tomas Vondra (link to meetup)
- PostgreSQL User Group Vienna: Cornelia Biacsics (link to meetup)
Hosting local meetups at Microsoft: Shout-out to the people involved in making Microsoft offices available as venues for local Postgres meetups, including:
- Postgres Bangalore (PGBLR) Meetup: hosted at the Microsoft office in Feb 2026 (post by Nitin Jadhav about the meetup)
- Barcelona (+Valencia) PostgreSQL User Group: hosted at the Microsoft office in Oct 2025 (link to meeting #4 at Microsoft)
Serve on Postgres core team, project committees, & PGCA Board of Directors: Every open source project needs governance, and there are many teams and efforts that comprise the project beyond code. Shout-out to:
- Andres Freund from Microsoft serves on the PostgreSQL Core Team.
- Melanie Plageman serves on the PostgreSQL Contributors committee.
- Noah Misch and Andres Freund serve on the PostgreSQL Security team.
- Claire Giordano serves on the board of directors for the PostgreSQL Community Association (PGCA) non-profit, an organization that stewards the PostgreSQL brand assets including trademarks and domain names. (link to PostgreSQL governance / link to PGCA non-profit)
Benefactor sponsor of PostgreSQL Community Association (PGCA) non-profit: As of May 2026, Microsoft is a Benefactor sponsor of the PGCA non-profit and the PostgreSQL project, providing financial support to protect the PostgreSQL project’s trademarks and brand assets. (link to PGCA non-profit website)
PostgreSQL developer meetings: Twice a year the developer community hosts invitation-only summits—typically coinciding with FOSDEM PGDay and PGConf.dev—to discuss “wicked problems”, technical issues, or development processes that are not easily addressed over email. Members of our Postgres contributor team have a seat at this table.
Blogging: The blog platform where our Postgres team has been publishing the most in the last year—with 99 new posts—is on Microsoft Tech Community. Blogging continues to be a super useful way to share information—and when I’m researching something at 2AM, I’m definitely appreciative of all the Postgres people who take time to share information via blog! (link to the Microsoft Blog for PostgreSQL)
Contribute to Patroni 4.0.x and 4.1.x: Patroni is a popular High Availability (HA) solution for Postgres. It helps you deploy, manage, and monitor HA clusters using streaming replication—and it’s open source. Alexander Kukushkin from our team is the technical lead and collaborates with engineers from different companies on Patroni.

In the last 13 months, Patroni added Postgres 18 support as well as support for patronictl demote-cluster and patronictl promote-cluster which automate switching of a Patroni cluster between primary and standby cluster roles.

I started to include individual release notes links for the last 13 months but there were too many to list: 5 minor releases and 1 new major release. (link to Patroni release notes)

Microsoft ❤️ Postgres

For the 4^th year in a row, this blog post is a snapshot of the work our Postgres team at Microsoft has done over the last year. There are too many contributors to name—but without their efforts, this post would not exist.

As I wrap-up, I’m struck by just how many ways the team at Microsoft shows up for Postgres. We run a managed Postgres service on Azure—and in the past year, we’ve launched a new Postgres extension for VS Code as well as a new Postgres database service called Azure HorizonDB (in Preview). We contribute upstream to the PostgreSQL project with code, architecture, reviews, testing, extensions, volunteering in the community, organizing user groups, and more. We maintain open source projects like Citus and Patroni. To share expertise, we write blog posts and give talks. We sponsor and help organize conferences—including POSETTE, the world’s largest virtual event for Postgres. And yes, we even produce a monthly podcast.

And the infographic that pulls it all together? I think it's a work of art.

********************

Acknowledgements

In addition to significant contributions by this blog post’s co-authors Guy Bowerman (Azure Database for PostgreSQL chapter) and Sumedh Pathak (PostgreSQL core chapter), many thanks to people who contributed to this year’s blog post: Abe Omorogbe, Brian Holt, Denzil Ribeiro, Dingding Lu, Isaac Alves, My Nguyen, Shreya Aithal, and Silvano Coriani. I could not have pulled this together alone: thank you!

Introducing Durable Functions in PostgreSQL

abeomor-msft — Tue, 09 Jun 2026 17:28:31 GMT

By Abe Omorogbe, Senior PM | Pino De Candia, Principal Software Engineer | TJ Green, Principal Software Engineer

Postgres will happily store your data, run your queries, and scale with you for years. But the moment you need to do more with that data, such as running multi-step transformation, scheduling nightly rollups, generating embeddings or waiting on an approval, you hit a wall. Postgres has no built-in way to run long-lived, fault-tolerant work.

That's why we built pg_durable, a new open-source PostgreSQL extension that brings durable execution directly into the database. With pg_durable, Postgres doesn’t just store your data, it runs long-lived, fault-tolerant workflows on it, with built-in retries, parallelism, scheduling, and recovery. Instead of stitching together PL/pgSQL functions or building external orchestration systems, you can now define and run resilient workflows entirely in your database, backed by Postgres' durability and high availability.

And on Azure HorizonDB, pg_durable also powers AI pipelines, enabling production-ready data and AI workflows, end-to-end, right inside the database.

In this post, we'll cover:

The hidden trap: blocking background work
What pg_durable is and the DSL that drives it
How this engine powers AI pipelines on HorizonDB
Sample patterns worth exploring
Getting started on HorizonDB, on your laptop, and in VS Code

🚀 Want to try it out? pg_durable ships in Azure HorizonDB, Microsoft's new PostgreSQL cloud service. The HorizonDB Preview is the fastest way to try pg_durable and AI pipelines together. Get started in HorizonDB →

Figure 1: pg_durable visualization

The hidden trap: blocking background work

Most Postgres teams eventually reach a point where they need to run critical tasks on their data: transformations, nightly aggregations, database maintenance workflows, embedding jobs, or multi-step business processes. So, they do the natural thing and try to keep that work inside Postgres.

They end up on a journey of increasing complexity and maintenance burden.

First, just run the task as a function in your database
You cram the whole workflow into one PL/pgSQL function: loop, transform, call APIs, write results, return. It looks simple until you have to run it in production. One connection stays tied up the whole time. Everything runs inside one big transaction, with long locks and no visibility into partial progress. If the connection drops or the database restarts, the whole run is gone. No per-step retries. No parallelism. No scheduling. No clean way to pause for human input.

When it fails, you move it outside
You push the workflow into an external service: a job queue, polling workers, state tables, step coordination, retry logic, crash-recovery sweeps, and cleanup jobs. What started as a few background tasks turns into a full distributed system. Before you’ve even touched the business logic, you’re building and operating infrastructure just to coordinate work that’s still fundamentally tied to your data.

Both paths are workarounds for the same missing primitive: durable, asynchronous background work that lives where your data lives. That's the gap pg_durable fills.

What pg_durable actually is

pg_durable is a Postgres extension that consists of a DSL (Domain specific language) and the duroxide runtime hosted in a Postgres background worker. You describe a workflow as a small SQL expression, call df.start(...), and get an instance ID back immediately. The work runs off to the side in a background worker, so it never blocks your connection or transaction, and you can check progress later with df.status() and df.result(). The execution state lives in Postgres, which means it benefits from the database’s durability, HA, backups, and recovery. Additionally, the workflow definition does not have to live in the database: your application can send it to df.start(...) over a regular Postgres connection.

Figure 2: pg_durable orchestration of worker and schema

Because execution is asynchronous, pg_durable automatically breaks a workflow into discrete steps. Each step runs in its own session and transaction, commits its progress, and hands off to the next instead of keeping one giant transaction open. Steps are checkpointed in Postgres and recovered by deterministic replay, so workflows survive crashes, restarts, and failovers and resume where they left off. If a step fails, only that step retries.

The whole thing is expressed through a tiny DSL of composable operators:

Operator	Meaning
~>	Sequential. run this, then that
&	Parallel. fan out, wait for all
\|	Race. fan out, take the first to finish
?> / !>	Conditional. if / else
@>	Loop. repeat durably, survive restarts
\|=>	Capture a step's result into a variable (reuse with $)
Advanced Functions
df.if()	Conditional branch
df.loop()	Repeat statements
df.join()	Execute in parallel, wait for all
df.http()	To call an allowlisted endpoint
df.wait_for_schedule()	For cron-style timing
df.wait_for_signal()	Pause for an external event

Read more about all operators and functions in pg_durable
Without pg_durable vs. with pg_durable

The hand-rolled version of "run three aggregations in parallel, then refresh a dashboard with retries and crash recovery" usually means 300+ lines of queue tables, polling workers, state-machine rows, per-step retry logic, crash-recovery sweeps, and cleanup jobs. Plus, the runbook to operate it.

The pg_durable version:

SELECT df.start( 'SELECT count(*) FROM users' & 'SELECT count(*) FROM orders' & 'SELECT sum(amount) FROM orders' ~> 'REFRESH MATERIALIZED VIEW metrics', 'refresh-dashboard' );

You write the SQL. pg_durable owns the queue, the state, the coordination, the retries, and the crash recovery.

Two ways to use pg_durable

1: Use pg_durable directly (works on Azure HorizonDB or any Postgres 17)

Enable it and start orchestrating:

CREATE EXTENSION pg_durable; SELECT df.start($$ SELECT 'Hello, durable world!' AS message $$); -- returns an instance ID immediately; the worker runs it asynchronously

From there you compose: sequential pipelines, conditional branches, races for timeout-or-result, variable passing between steps, human-in-the-loop approvals, scheduled maintenance all in SQL, close to the data, with no new infrastructure. This is the "just use Postgres" answer to a problem teams usually solve by leaving Postgres.

Because it's open source under the permissive PostgreSQL License, you can clone the repo and run it on your laptop, your server, or any cloud.

2: AI pipelines (HorizonDB capability)

On HorizonDB, pg_durable becomes the foundation for something even more approachable: a managed, declarative AI pipeline surface in the azure_ai extension. pg_durable gives you the durable execution engine, while the ai.* API gives you an AI-shaped model of sources, steps, sinks, and triggers that compile into a durable graph.

Traditional app-tier embedding pipelines fail in predictable ways: a transient API error mid-batch with no shared checkpoint, a worker that crashes after writing chunks but before marking the parent row processed, no clean way to re-embed just the rows that changed.

Move that logic into HorizonDB and the source, the steps, the sink, and the run history are all SQL, protected by the same transactions, backups, and PITR (point-in-time recovery) your data already has.

A complete chunk → embed AI pipeline is one definition:

SELECT ai.create_pipeline( name => 'ai_pipeline', source => ai.table_source(table_name => 'documents_ai_pipeline'), steps => ARRAY[ ai.chunk(input => 'content'), ai.embed(model => 'default-embedding', input => 'chunk_text', dimensions => 1536) ], trigger => 'on_change', sink => ai.table_sink('documents_ai_pipeline_output') ); SELECT ai.run('ai_pipeline');

Each AI step becomes a durable node, so if ai.embed() fails, ai.chunk() doesn’t run again. And with trigger => 'on_change', the pipeline runs automatically as rows change, embedding only what’s new.

Add a DiskANN index on the resulting table, and you have production-ready vector search end to end, entirely inside the database.

Where pg_durable fits and where it doesn't

If you've used external orchestrators such as Temporal or Airflow, your first reaction is probably: why would I put control flow in my database? Fair question. pg_durable isn't trying to be a universal orchestrator.

Reach for pg_durable when the workflow is tightly coupled to Postgres state. The rows it reads and writes live in the same database, it benefits from the database's own durability, backups, and PITR, and you'd rather not stand up a separate system to coordinate work that never leaves the data tier. Think: embedding pipelines, ETL jobs, scheduled maintenance, and queue-style background jobs.

Reach for a dedicated orchestrator when the workflow's center of gravity is outside Postgres, fanning across heterogeneous services, or running arbitrary application logic that does not map cleanly to SQL steps, branching, loops, or HTTP calls.

Get started
On Azure HorizonDB

CREATE EXTENSION IF NOT EXISTS pg_durable; -- Execute a simple SQL query as a durable function SELECT df.start($$ SELECT 'Hello, durable world!' AS message $$); -- Returns: a1b2c3d4 (8-character instance ID) -- Get result of a specific instance SELECT df.result(<ID>); That's it: submit, walk away, inspect.

Read the documentation for more details.
In VS Code, with the PostgreSQL extension

A dense one-liner of ~>, &, and |=> is precise once it clicks, but the learning curve is real so flatten it with tooling. Install the PostgreSQL extension for VS Code from the Marketplace:

Figure 3: AI pipelines and pg_durable in VSCode extension

Connect to HorizonDB or your local Postgres directly from the extension
Let Copilot write the SQL. The pg-durable-sql skill turns a plain-English description ("every night, archive orders older than 90 days") into correct pg_durable syntax.
Run it and watch it. The extension renders pg_durable workflows and azure_ai pipelines as live graphs, definition and each run, so you can see every step, its timing, and exactly where a failure happened.

Authoring, execution, run visualization, and inspection in one window and the same tooling works against any Postgres, not just HorizonDB.

On your laptop

Prefer to run it yourself? Clone microsoft/pg_durable, use the Codespace prebuild or VS Code Dev Container, and add the extension on any Postgres 17.

Sample patterns worth exploring

The scenario guide has a full catalog of scenarios; however, these are the three I would start with.

ETL Pipeline: a multi-step data transformation where each step must be completed before the next begins. Failures should stop the pipeline.

SELECT df.start( 'DELETE FROM target WHERE loaded_at < now() - interval ''7 days''' -- Step 1: Cleanup old ~> 'UPDATE staging SET processed_at = now() WHERE processed_at IS NULL' -- Step 2: Mark staging ~> 'INSERT INTO target (data, source_id) SELECT data, source_id FROM staging WHERE processed_at IS NOT NULL', -- Step 3: Load 'etl-pipeline' -- Label for easy identification );

If the database restarts mid-backfill, it picks up from the last checkpointed batch, not row zero. See full example

Scheduled Data Sync: poll an external API or run a job on a schedule (hourly, daily, every 30 minutes). The job should run forever and survive restarts. (See full example):

-- Scheduled sync: fetch data every 30 minutes (runs forever) SELECT df.start( @> ( -- @> creates an eternal loop -- Fetch from external API (df.http( 'https://httpbingo.org/json', 'GET' ) |=> 'response') -- Store the response ~> 'INSERT INTO external_data_sync (data) VALUES ($response::jsonb)' -- Wait for next scheduled run ~> df.wait_for_schedule('*/30 * * * *') -- Cron: every 30 minutes ), 'scheduled-data-sync' );

Human-in-the-loop approval: auto-apply routine changes, pause the risky ones until a person signals approval (See full example):

SELECT df.start( 'SELECT amount > 10000 AS needs_review FROM invoices WHERE id = 42' |=> 'risky' ?> ( df.wait_for_signal('invoice-42') ~> 'UPDATE invoices SET status = ''paid'' WHERE id = 42' ) !> 'UPDATE invoices SET status = ''paid'' WHERE id = 42', 'invoice-approval' );

The workflow simply waits minutes or days until a reviewer releases it with the matching signal, then resumes.

The community is already running with it

pg_durable launched as open source and the community is already kicking the tires. The project was a top article on Hacker News on launch day and 1.7K stars on GitHub within its first few days of initial launch. Also Franck Pachot (PostgreSQL community veteran) published an independent walkthrough, Getting Started with pg_durable: durable workflows inside PostgreSQL within days of release.

The repo is actively developed, and the maintainers are reading every issue and PR. If you want improvements in our DSL ergonomics, say so. If you want an operator that doesn't exist yet, open an issue. If you've got a scenario we haven't covered, send a PR. The syntax, the docs, and the rough edges all get better when people who run Postgres in production push back.

So, clone it, and build something real. If you find rough edges, open an issue or send a PR at microsoft/pg_durable. We think you'll be surprised by how much it can take.

Learn more

Make upgrades predictable with Pre-Upgrade Validation Checks

varun-dhawan — Thu, 11 Jun 2026 14:31:16 GMT

Major version upgrades are an important part of keeping PostgreSQL environments current with the latest features, security updates, and performance improvements. But for production workloads, the hardest part is often not the upgrade itself - it is knowing whether the server is ready before the upgrade window begins.

Today, we’re announcing the Public Preview of Pre-Upgrade Validation Checks for Azure Database for PostgreSQL. This new capability lets you validate upgrade readiness before starting the actual major version upgrade, helping you identify and resolve blockers early.

With Pre-Upgrade Validation Checks, you can run upgrade checks independently, review actionable results, fix issues, and re-run validation until your server is ready. This shifts upgrade troubleshooting from the upgrade window to a proactive pre-flight step.

Why this matters

Azure Database for PostgreSQL flexible server already supports in-place major version upgrades using PostgreSQL pg_upgrade. The service preserves the server name and connection settings, runs upgrade prechecks, takes an implicit backup when checks pass, and then performs the engine upgrade.

Pre-Upgrade Validation Checks extend this model by decoupling validation from upgrade execution.

Instead of: Upgrade → Discover issue → Troubleshoot → Retry

You can now follow: Validate → Fix → Re-Validate → Upgrade

This helps reduce failed upgrade attempts, improves planning, and gives teams more confidence before entering a production change window.

What Pre-Upgrade Validation Checks validate

Pre-Upgrade Validation Checks evaluate both Azure-specific upgrade requirements and PostgreSQL compatibility checks, including pg_upgrade --check.

At a high level, the validation covers:

Configuration and platform prerequisites, such as server state, target version support, storage headroom, and upgrade readiness.
Extension compatibility, including unsupported or version-sensitive extensions.
Database dependencies and objects, such as read replicas, logical replication slots, event triggers, PostGIS search_path, and upgrade-sensitive objects.
Engine compatibility, using PostgreSQL pg_upgrade --check.

If a blocking issue is found, the result includes details to help you understand what needs to be fixed before retrying validation or starting the upgrade.

How to run Pre-Upgrade Validation Checks from the Azure portal

You can run Pre-Upgrade Validation Checks directly from the existing Upgrade experience in the Azure portal.

Step 1: Select `Validate only`

From your Azure Database for PostgreSQL flexible server, select Upgrade. Choose the target PostgreSQL version, then select Validate only as the action. This runs validation checks without starting the actual upgrade.

Figure 1: Select Validate only before starting upgrade

Step 2: Review successful validation results

If all validation checks pass, the result shows a successful status. At this point, the server is ready to proceed with the major version upgrade.

Figure 2: Successful validation results

In this example, all pre-upgrade validation checks completed successfully, and no blocking issues were detected for the selected target PostgreSQL version.

Step 3: Review and fix validation errors

If validation detects issues, the results page shows failed checks with details and remediation guidance. You can fix the reported issues and run validation again.

Figure 3: Failed validation with remediation details

In this example, validation found an event trigger issue before the upgrade was started. The upgrade action remains blocked until the issue is resolved and validation passes.

Step 4: Download validation results

You can also download the validation results as a CSV file. This makes it easier to share findings with DBA, application, platform, or support teams before the actual upgrade window.

Figure 4: Download validation results as CSV

The CSV output is useful for offline review, internal tracking, and support collaboration.

Recommended workflow

Use Pre-Upgrade Validation Checks as part of your upgrade planning process: run validation early, review the results, fix any reported blockers, re-run validation until all checks pass, and then proceed with the major version upgrade.

What happens after validation passes?

Once validation succeeds, you can proceed with the major version upgrade using the existing Azure PostgreSQL upgrade workflow. The actual upgrade remains a separate operation and still includes the managed backup and pg_upgrade execution steps.

Pre-Upgrade Validation Checks do not remove the upgrade downtime window. Instead, they help ensure that known blockers are resolved before that window begins.

Frequently asked questions

Does Validate only perform the upgrade?

No. The Validate only option runs readiness checks without upgrading the server. The actual major version upgrade remains a separate action.

Does this remove downtime?

No. Major version upgrades still require an execution window. The benefit is that compatibility issues can be discovered and resolved before downtime begins.

Can I re-run validation?

Yes. Validation is designed to be repeatable. You can fix reported issues and re-run checks until all validations pass.

What types of blockers can be detected?

Common examples include unsupported extensions, logical replication slots, event triggers, insufficient storage headroom, configuration issues, and PostgreSQL compatibility findings from pg_upgrade --check.

Get started

Pre-Upgrade Validation Checks are now available in Public Preview for Azure Database for PostgreSQL flexible server.

To try it, open your flexible server in the Azure portal, go to Upgrade, select your target PostgreSQL version, and choose Validate only.

Learn more

To learn more about major version upgrades and related Azure PostgreSQL capabilities, see:

Validate early. Fix with confidence. Upgrade when ready.

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.

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.

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.

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.

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

April 2026 Recap: Azure Database for PostgreSQL

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

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

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

POSETTE 2026

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

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

Features

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

Learning Bytes: Preventing accidental server deletion

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

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

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

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

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

Migrating from VNet to Private Endpoint

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

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

New enhancements in the PostgreSQL VS Code Extension

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

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

Improving Query Performance and Modeling in PostgreSQL

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

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

Scaling PostgreSQL for Real-World Application Workloads

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

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

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

Azure Postgres Learning Bytes 🎓

Preventing accidental server deletion

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

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

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

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

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

End-to-end workload observability with Query Store for primary and replicas

nachoalonsoportillo — Fri, 08 May 2026 13:54:46 GMT

Query performance doesn’t stop at the primary

Most PostgreSQL architectures don’t run on a single node anymore. Reads get offloaded. Replica chains grow. And when performance issues hit, the hardest part is often simple: where did the queries actually run?
With the latest query store capabilities in Azure Database for PostgreSQL flexible server, you can now capture workload executed not just on the primary, but also on read replicas—including cascading read replicas—and export the captured runtime stats, wait stats, and query text into Azure Monitor Logs (Log Analytics workspace / LAWS).

See the real hotspot: isolate which node (primary vs replica) is slow.
Know why: break down time by waits (CPU, I/O, locks) per query.
Connect the dots: correlate query IDs to query text, and inspect sampled parameters locally in azure_sys on the primary when you need input context (parameters aren’t exported to LAWS).
Centralize analysis: query everything with KQL in LAWS, across servers.

What you’ll build

This post walks through a reproducible demo that provisions a primary server, a read replica, and a cascading read replica, then runs a TPC-H–based workload across all three to generate query store data you can analyze locally and in Log Analytics.

Enable query store capture (including query text) and parameter sampling for parameterized queries.
Enable wait sampling so query store can record wait statistics.
Export runtime stats, wait stats, and SQL text to LAWS using resource-specific tables.
Validate capture on read replicas and cascading read replicas (not just the primary).

Prerequisites

Azure CLI logged in (az login) and permission to create a resource group, Log Analytics workspace, and PostgreSQL flexible servers.
psql and curl available on your machine.
PostgreSQL flexible server on General Purpose or Memory Optimized tier (query store and replicas aren’t supported on Burstable).
PostgreSQL 14+ to test out cascading replicas.
Networking: the script opens firewall access broadly for demos—tighten for production.

Architecture (primary + replica chain + LAWS)

You’ll deploy four resources:

Primary server: read/write node.
Read replica (level 1): read-only node created from the primary.
Cascading read replica (level 2): read-only node created from replica level 1.
Log Analytics workspace (LAWS): central place to query Query Store telemetry across all nodes.

If Diagnostic Settings is properly configured, each server streams query store telemetry to LAWS—but how it’s kept locally differs by role. On the primary, query store data is recorded in-memory, then persisted locally in the azure_sys database, and then exported to LAWS. On read replicas (including cascading replicas), query store data is recorded in-memory only and then exported to LAWS. Bottom line: use LAWS for fleet-wide visibility, and use the primary’s azure_sys when you need deep local inspection (like parameter samples).

Deploy the demo environment

The fastest way to reproduce the scenario is to run the end-to-end bash script which you can download from https://raw.githubusercontent.com/Azure-Samples/azure-postgresql-query-store/refs/heads/main/may2026/script/query_store_demo.sh

Save the file to a local directory in your Linux shell, and name the file query_store_demo.sh.

To invoke the script, at minimum, you must assign a string password for the administrator login of the instances of the flexible servers it creates, and invoke the script like this:

ADMIN_PASSWORD=<Your_Strong_Password> ./query_store_demo.sh

Optionally, you can also override default values for other environment variables used by the script:

Variable	Purpose	Default
SUBSCRIPTION_ID	Azure subscription ID to use	(current default subscription)
BASE_NAME	Base name for all resources (used in naming servers, resource groups, etc.)	pgqswait{YYYYMMDDHHMMSS}
RESOURCE_GROUP	Azure resource group name	rg-{BASE_NAME}
LOCATION	Azure region for resources	southeastasia
PRIMARY_SERVER	Name of primary PostgreSQL server	{BASE_NAME}-primary
REPLICA_1	Name of first-level read replica	{BASE_NAME}-readreplica
REPLICA_2	Name of second-level cascading read replica	{BASE_NAME}-cascadereadreplica
LOG_ANALYTICS_WORKSPACE	Log Analytics workspace name	law-{BASE_NAME}
LOG_ANALYTICS_LOCATION	Azure region for Log Analytics workspace	southeastasia
ADMIN_USER	PostgreSQL admin username	pgadmin
ADMIN_PASSWORD	PostgreSQL admin password	(REQUIRED)
SKU_NAME	PostgreSQL server SKU (compute tier)	Standard_D4ds_v5
TIER	PostgreSQL pricing tier	GeneralPurpose
STORAGE_SIZE	Storage size in GB	64
VERSION	PostgreSQL version (minimum 14 for cascading replicas)	17
PRIMARY_DATABASE	Initial database name	postgres
SQL_BASE_URL	Base URL for downloading SQL scripts	https://raw.githubusercontent.com/Azure-Samples/azure-postgresql-query-store/refs/heads/main/may2026/script/query_store_demo.sh
TPCH_DDL_URL	URL for TPC-H schema DDL file	{SQL_BASE_URL}/schema/tpch_ddl.sql
WORKLOAD_REPETITIONS	Number of times to execute each workload query (minimum 5)	10
AUTO_APPROVE	Skip confirmation prompt and proceed automatically	false

If, for example, you want to not only pass the ADMIN_PASSWORD but also override the LOCATION, you could do it like this:

ADMIN_PASSWORD=<Your_Strong_Password> LOCATION=canadacentral ./query_store_demo.sh

In a bit over 1 hour, the script will do the following steps:

Step 1 — Provision first part of the infrastructure

The infrastructure provisioned in this phase consists of:

A resource group in which all resources are deployed.
An instance of Log Analytics workspace, where all flexible server instances will send their query store related logs.
A primary (read-write) flexible server.

Step 2 — Configure primary server

Now it's time to configure one new server parameters on your primary server so that query store emits query text to LAWS, so that we can correlate quey IDs to something recognizable.

Query IDs are great for aggregation—but you still need the SQL. Turn on query text emission so you can correlate runtime and waits back to the actual statement text. Do this by setting pg_qs.emit_query_text to on.

Refer to our documentation to learn how to set the value of a server parameter.

Step 3 — Provision second part of the infrastructure

The infrastructure provisioned in this phase consists of:

A read replica (read-only) whose source is the primary server.
A cascade read replica (read-only), whose source is the previously created read replica.

Notice that when read replicas are created, they inherit the server parameter values from their source server. Because we have configured query store related settings on the primary server already, the intermediate read replica inherits its server parameters from that primary, and the cascade read replica inherits them from the intermediate replica.

Step 4 — Export query store to Log Analytics (LAWS)

Now for the payoff, we want to stream the data to Log Analytics so you can query across nodes, build dashboards, and alert.

The script configures diagnostic settings on the primary and both replicas to send logs to a Log Analytics workspace using resource-specific tables. This is the key to cross-node visibility: each server exports its own captured telemetry, and you can slice by resource in a single KQL query.

Query store runtime stats: execution counts, elapsed time, and other performance counters.
Query store wait stats: wait breakdown attributed to queries.
Query store SQL text: query text to decode query IDs.

Note: Query store parameter samples are not included in the Log Analytics export. Parameters are stored locally per server in azure_sys, and on read replicas azure_sys is read-only—so don’t depend on replicas for parameter inspection. LAWS receives runtime stats, wait stats, and query text.

Diagnostics settings for an instance of flexible server can be configured via portal. In the resource menu, under Monitoring, select Diagnostic settings. Add a new diagnostic setting, select a destination Log Analytics workspace, and the individual log catergories which you want to stream to that LAWS, and save the changes.

For Destination table it's highly recommended to use Resource specific (one table per signal with proper schema) over Azure diagnostics (legacy one table for everything).

With Azure diagnostics, all logs from all resource types land into a single table (AzureDiagnostics). It's a wide table with many columns. New columns get added as services emit new fields. If the 500 column limit is hit, extra fields go into the AdditionalFields column (a dynamic JSON). Querying on attributes stored in that column might have huge performance and query cost impact. The schema is inconsistent and difficult to discover. You must always filter events in that table by ResourceType and Category.

On the other hand, with Resource specific, logs are written to separate tables per resource type and category. Therefore, each table has a well-defined schema and columns are strongly typed. Tables are smaller and faster to query. Queries on these tables are simpler don't need filtering by ResourceType and Category. Performance-wise, they also support faster ingestion and faster querying. They also support selecting different table plans and retention settings for each table. And, more importantly, role-based access control (RBAC) permissions can be applied at table level, allowing you to control access to telemetry in a more granular way.

Note: If you want to see any of the images in this article in better quality, click on them to see them in their original size.

This can also be configured using Azure CLI command az monitor diagnostic-settings create. Make sure that the --export-to-resource-specific parameter is set to true, which is the equivalent of selecting Resource specific for Destination table in portal UI. Setting this parameter to false, would mean that you want to use AzureDiagnostics as the destination table, which we don't recommend using.

Step 5 — Run some workload

In this phase the script loads a TPC-H schema and executes workload SQL across different nodes so that you can prove replica capture.

Query it in Log Analytics

Once the workload completed and data was streamed to Log Analytics, you can open your Log Analytics workspace, and start querying the relevant tables. If you don't know how to start issuing queries in a Log Analytics workspace, refer to Get started with log queries in Azure Monitor Logs.

In your Log Analytics workspace, when you select Logs in the resource menu, you can access the Queries hub. By default, it should open automatically unless you have configured it to not show, in which case you can open by selecting Queries hub on the top right corner of the Logs home screen.

If you add a filter in the queries hub for Resource type equals Azure Database for PostgreSQL Flexible Server, you'll be able to access multiple examples of queries which might help you get started querying the log categories we support for our service.

You can run any of them by selecting Run on the summarization card that describes the query or, if you hover the mouse over the card, you can select Load to editor so that the query is copied over to the active query window, and you can run it or modified it further.

Following, there are a few more query examples which can be useful to analyze the workload executed in this experiment.

Top queries by total time (across all nodes)

To get the list of 10 queries with higher duration from the ones that ran on any of the three nodes.

KQL

PGSQLQueryStoreRuntime | summarize total_time_ms = sum(TotalExecDurationMs) by QueryId, LogicalServerName | top 10 by total_time_ms desc

Results