Premium SSD v2 is now generally available for Azure Database for PostgreSQL Flexible Server, delivering significant performance and cost-efficiency improvements for I/O‑intensive workloads. It offers up to 4× higher IOPS, lower latency, and improved price‑performance.

With independent scaling of storage and performance, you only pay for what you need. Premium SSD v2 supports storage scaling up to 64 TiB, with performance reaching 80,000 IOPS and 1,200 MiB/s throughput, without tying performance to disk size. IOPS and throughput can be adjusted instantly, with no downtime.

Additionally, built‑in baseline performance at no additional cost ensures consistent performance even for smaller deployments, making Premium SSD v2 a strong choice for modern, high‑demand PostgreSQL applications.

For details about the Premium SSD v2 release, see the GA Announcement Blog and documentation

Cascading read replica – Generally available

Cascading read replicas are now generally available, giving customers greater flexibility to create read replicas from existing read replicas. This capability supports up to two levels of replication and up to 30 read replicas in total, with each read replica able to host up to five cascading replicas.

With cascading read replicas, you can more effectively distribute read traffic across multiple replicas, deploy regional or hierarchical read replicas closer to end users, reduce read latency, and improve overall query performance for read‑heavy workloads. In addition, we’ve rolled out switchover support for both intermediate and cascading read replicas, making it easier to manage replica topologies. Learn more about cascading read replicas through our documentation and a detailed blog walkthrough.

Online migration using PgOutput plugin – Generally Available

The new addition of the PgOutput plugin helps make your Online migration to Azure more robust and seamless. The native “Out-of-the-Box” support that PgOutout offers is more suited for Online Production migrations compared to other logical decoding plugins. PgOutput offers higher throughput and superior performance compared to other logical decoding plugins ensuring your Online migration has very limited downtime. PgOutput also offers fine-grained filtering using Publications where you can migrate specific tables and filter by specific operations.

For more details about this update, see the documentation.

Google AlloyDB as a migration source – Generally Available

Google AlloyDB is now supported as a source in Azure Database for PostgreSQL Migration Service. You can use this capability to migrate your AlloyDB workloads directly to Azure Database for PostgreSQL, using either offline or online migration options. This support helps you move your PostgreSQL databases to Azure with confidence, while taking advantage of Azure’s flexibility and scalability.

To know more about this feature, visit our documentation.

EDB Extended Server as a migration source – Generally Available

Azure Database for PostgreSQL Migration Service now supports EDB Extended Server as a migration source. This enables you to migrate EDB Extended Server workloads to Azure Database for PostgreSQL using both offline and online migration methods. With this addition, you can transition PostgreSQL databases to Azure smoothly and benefit from the scale and flexibility of the Azure platform.

For more details about this update, see the documentation.

Logical replication slot sync status metric – Preview

You can now monitor whether your logical replication slots are failover‑ready using the new logical_replication_slot_sync_status metric, now in preview. This metric provides a simple binary signal indicating whether logical replication slots are synchronized across High availability (HA) primary and standby nodes. It helps you quickly assess failover readiness without digging into replication internals especially valuable for CDC pipelines such as Debezium and Kafka, where data continuity during failover is critical.

Learn more about logical replication metrics in the documentation.

Defender Security Assessments – Preview

In March, we introduced two new Microsoft Defender for Cloud CSPM security recommendations for Azure Database for PostgreSQL Flexible Server, now available in public preview:

Geo-redundant backups should be enabled for PostgreSQL Servers

require_secure_transport should be set to “on” for PostgreSQL Servers

These integrated assessments continuously evaluate database configuration settings against security best practices, helping customers proactively identify and manage security posture risks for their Azure PostgreSQL servers while maintaining alignment with internal and industry standards.

Additional security posture assessments for Azure PostgreSQL will be introduced as they become available.

To learn more, refer to the reference table for all data security recommendations in Microsoft Defender for Cloud.

New enhancements in the PostgreSQL VS Code Extension

The March release (v1.20) of the PostgreSQL VS Code extension delivers new server management capabilities, enhanced query plan analysis, visual improvements, and a batch of bug fixes.

Clone Server: You can now clone an Azure PostgreSQL Flexible Server directly from within the extension. The clone operation is available from the server management UI, allowing you to duplicate a server configuration including region, SKU, and settings without leaving VS Code.

Entra ID Authentication for AI-Powered Schema Conversion: The Oracle-to-PostgreSQL migration experience now supports Microsoft Entra ID authentication for Azure OpenAI connectivity, replacing API key–based authentication. This enables enterprise-grade identity management and access control for AI-powered schema conversion workflows.

Query Plan Visualization Improvements: The Copilot-powered “Analyze with Copilot” feature for query plans has been improved with more relevant optimization recommendations and smoother SQL attachment handling during plan analysis.

Apache AGE Graph Visualizer Enhancements: The graph visualizer received a visual refresh with modernized edge rendering, a color-coded legend, and a new properties pane for exploring element details.

Object Explorer Deep Refresh: The Object Explorer now supports refreshing expanded nodes in place, so newly created tables and objects appear immediately without needing to disconnect and reconnect.

Settings Management: The extension now supports both global user settings and local .vscode/settings.json, providing more robust connection settings management across configuration sources.

Bug Fixes: This release includes numerous bug fixes across script generation (DDL for triggers, materialized views, and functions), IntelliSense (foreign table support), JSON data export, query execution, and server connectivity.

Latest PostgreSQL minor versions: 18.3, 17.9, 16.13, 15.17, 14.22

Azure PostgreSQL now supports the latest PostgreSQL minor versions: 18.3, 17.9, 16.13, 15.17, and 14.22. These updates are applied automatically during planned maintenance windows, ensuring your databases stay up to date with critical fixes and reliability improvements, with no manual action required. This is an out-of-cycle release that addresses regressions identified in the previous update. The release includes fixes across replication, JSON functions, query correctness, indexing, and extensions like pg_trgm, improving overall stability and correctness of database operations.

For details about the minor release, see the PostgreSQL announcement.

New extension support for PostgreSQL 18 on Azure Database for PostgreSQL

Azure Database for PostgreSQL running PostgreSQL 18 now supports extensions that enable graph querying, in‑database AI integration, external storage access, and scalable vector similarity search, expanding the types of workloads that can be handled directly within PostgreSQL.

Newly supported extensions include:

AGE (Apache AGE v1.7.0): Adds native graph data modeling and querying capabilities to PostgreSQL using openCypher, enabling hybrid relational–graph workloads within the same database.

azure_ai: Enables direct invocation of Microsoft Foundry models from PostgreSQL using SQL, allowing AI inference and embedding generation to be integrated into database workflows.

azure_storage: Provides native integration with Azure Blob Storage, enabling PostgreSQL to read from and write to external storage for data ingestion, export, and hybrid data architectures.

pg_diskann: Introduces disk‑based approximate nearest neighbor (ANN) indexing for high-performance vector similarity search at scale, optimized for large vector datasets with constrained memory.

Together, these extensions allow PostgreSQL on Azure to support multi-model, AI‑assisted, and data‑intensive workloads while preserving compatibility with the open‑source PostgreSQL ecosystem.

Guide on PostgreSQL buffer cache analysis, query rewriting

We have rolled out two new blogs on PostgreSQL buffer cache analysis and PostgreSQL query rewriting and subqueries. These blogs help you better understand how PostgreSQL behaves under the hood and how to apply practical performance optimizations whether you’re diagnosing memory usage, reducing unnecessary disk I/O, or reshaping queries to get more efficient execution plans as your workloads scale.

PostgreSQL Buffer Cache Analysis

This blog focuses on understanding PostgreSQL memory behavior through shared_buffers, the database’s primary buffer cache. Using native statistics and the pg_buffercache extension, it provides a data‑driven approach to evaluate cache efficiency, identify when critical tables and indexes are served from memory, and detect cases where disk I/O may be limiting performance. The guide offers a repeatable methodology to support informed tuning decisions as workloads scale.

PostgreSQL Query Rewriting and Subqueries

This blog explores how query structure directly impacts PostgreSQL execution plans and performance. It walks through common anti‑patterns and practical rewrites such as replacing correlated subqueries with set‑based joins, using semi‑joins, and pre‑aggregating large tables to reduce unnecessary work and enable more efficient execution paths. Each scenario includes clear explanations, example rewrites, and self‑contained test scripts you can run.

Azure Postgres Learning Bytes 🎓

How to create and store vector embeddings in Azure Database for PostgreSQL

Vector embeddings sit at the core of many modern AI applications from semantic search and recommendations to RAG‑based experiences. But once you generate embeddings, an important question follows: how do you generate and store them in your existing database server?

With Azure Database for PostgreSQL, you can generate and store vector embeddings directly alongside your application data. By using the `azure_ai` extension, PostgreSQL can seamlessly integrate with Azure OpenAI to create embeddings and store them in your database. This learning byte walks you through a step‑by‑step guide to generating and storing vector embeddings in Azure Database for PostgreSQL.

Step 1: Enable the Azure AI extension

Azure Database for PostgreSQL supports the azure_ai extension, which allows you to call Azure OpenAI service.

Connect to your database and run:

CREATE EXTENSION IF NOT EXISTS azure_ai;

Step 2: Create (or use existing) Azure OpenAI resource

You need an Azure OpenAI resource in your subscription with an embedding model deployed.

In the Azure portal, create an Azure OpenAI resource.

Deploy an embedding model (for example, text-embedding-3-small).

Azure OpenAI provides the endpoint URL and API key

Step 3: Get endpoint and API key

Go to your Azure OpenAI resource in the Azure portal.

Select Keys and Endpoint.

Copy:
- Endpoint
- API Key (Key 1 or Key 2)

Step 4: Configure Azure AI extension with OpenAI details

Store the endpoint and key securely inside PostgreSQL

SELECT
azure_ai.set_setting(
‘azure_openai.endpoint’, ‘https://.openai.azure.com’
);
SELECT
azure_ai.set_setting(
‘azure_openai.subscription_key’,
”
);

Step 5: Generate an embedding

SELECT
LEFT(
azure_openai.create_embeddings(
‘text-embedding-3-small’, ‘Sample text for PostgreSQL Lab’
):: text,
100
) AS vector_preview;

Step 6: Add a vector column

Add a vector column to store embeddings (example uses 1536‑dimensional vectors):

ALTER TABLE

ADD
COLUMN embedding VECTOR(1536);

Step 7: Store the embedding

Update your table with the generated embedding:

UPDATE

SET
embedding = azure_openai.create_embeddings(
‘text-embedding-3-small’, content
);

Conclusion

That’s a wrap for our March 2026 recap. This month brought a set of meaningful updates focused on making Azure Database for PostgreSQL more performant, reliable, and scalable whether you’re modernizing workloads, scaling globally, or strengthening your security posture.

We’ll be back soon with more exciting announcements and key feature enhancements for Azure Database for PostgreSQL, so stay tuned! Your feedback is important to us, have suggestions, ideas, or questions? We’d love to hear from you: https://aka.ms/pgfeedback.

When the shield becomes the sword: How misconfigured PAM bridges the tiering model

Enforce Cost Limits on KQL Queries and Notebooks in the Microsoft Sentinel Data Lake