Hello Azure Community,

We’re kicking off the year with important updates for Azure Database for PostgreSQL. From Premium SSD v2 features now available in public preview to REST API feature updates across developer tools, this blog highlights what’s new and what’s coming.

1. Terraform Adds Support for PostgreSQL 18 – Generally Available
2. Ansible module update - Generally Available
3. Achieving Zonal Resiliency with Azure CLI - Generally Available
4. SDKs Released : Go, Java, JavaScript, .NET and Python – Generally Available
5. What’s New in Premium SSD v2 - Public Preview
6. Latest PostgreSQL minor versions
7. January 2026 Maintenance Release Notes

Terraform Adds Support for PostgreSQL 18

Azure Database for PostgreSQL now provides support for PostgreSQL 18 which allows customers to create new servers with PostgreSQL 18 version and upgrade existing ones using Terraform. This update makes it easier to adopt PostgreSQL 18 on Azure while managing both provisioning and upgrades through consistent Terraform workflows.

Learn more about using the new terraform resource

Ansible Module Update

A new Ansible module is now available with support for the latest GA REST API features, enabling customers to automate provisioning and management of Azure Database for PostgreSQL resources. This includes support for Elastic Clusters provisioning, deployment of PostgreSQL instances with PostgreSQL 18, and broader adoption of newly released Azure Database for PostgreSQL capabilities through Ansible.

Learn more about using Ansible module with latest REST API features

Achieve zonal resiliency with Azure CLI

We have released updates to the Azure CLI that allow users to enable zone‑redundant high availability (HA) by default using a new --zonal-resiliency parameter. This parameter can be set to enabled or disabled.

When --zonal-resiliency is enabled, the service provisions a standby server in a different availability zone than the primary, providing protection against zonal failures. If zonal capacity is not available in the selected region, you can use the --allow-same-zone flag to provision the standby in the same zone as the primary.

Azure CLI commands:

az postgres flexible-server update --resource-group <resource_group> --name <server> --zonal-resiliency enabled --allow-same-zone</server></resource_group>

az postgres flexible-server update --resource-group <resource_group> --name <server> --zonal-resiliency Disabled</server></resource_group>

az postgres flexible-server create --resource-group <resource_group> --name <server> --zonal-resiliency enabled --allow-same-zone</server></resource_group>

Learn more about how to configure high availability on Azure Database for PostgreSQL.

SDKs Released : Go, Java, JavaScript, .NET and Python

We have released updated SDKs for Go, Java, JavaScript, .NET, and Python, built on the latest GA REST API (2025‑08‑01). These SDKs enable developers to programmatically provision, configure, and manage Azure Database for PostgreSQL resources using stable, production‑ready APIs. It also adds the ability to set a default database name for Elastic Clusters, simplifying cluster provisioning workflows, support for PostgreSQL 18. To improve developer experience and reliability, operation IDs have been renamed for clearer navigation, and HTTP response codes have been corrected so automation scripts and retries behave as expected.

Learn More about .NET SDK

Learn more about Go SDK

Learn more about Java SDK

Learn more about Javascript SDK

Learn more about Python SDK

What’s New in Premium SSD v2: Public Preview

Azure Database for PostgreSQL Flexible Server now supports a broader set of resiliency and lifecycle management capabilities on Premium SSD v2, enabling production‑grade PostgreSQL deployments with improved durability, availability, and operational flexibility. In this preview, customers can use High Availability (same‑zone and zone‑redundant), geo‑redundant backups, in‑region and geo read replicas, geo‑disaster recovery (Geo‑DR), and Major Version Upgrades on SSDv2‑backed servers, providing both zonal and regional resiliency options for mission‑critical PostgreSQL workloads. These capabilities help protect data across availability zones and regions, support compliance and disaster‑recovery requirements, and simplify database lifecycle operations.    

Premium SSD v2 enhances these resiliency workflows with higher and independently scalable IOPS and throughput, predictable low latency, and decoupled scaling of performance and capacity. Customers can provision and adjust storage performance without over‑allocating disk size, enabling more efficient capacity planning while sustaining high‑throughput, low‑latency workloads. When combined with zone‑resilient HA and cross‑region data protection, SSDv2 provides a consistent storage foundation for PostgreSQL upgrades, failover, backup, and recovery scenarios. These capabilities are being expanded incrementally across regions as the service progresses toward general availability

For more details, see Premium SSDv2

Latest Postgres minor versions: 18.1, 17.7, 16.11, 15.15, 14.20, 13.23

Azure Database for PostgreSQL now supports the latest PostgreSQL minor versions: 18.1, 17.7, 16.11, 15.15, 14.20, and 13.23. These updates are applied automatically during planned maintenance windows, ensuring your databases stay up to date with critical security fixes and reliability improvements no manual action required.

This release includes two security fixes and over 50 bug fixes across indexing, replication, partitioning, memory handling, and more. PostgreSQL 13.23 is the final community release for version 13, which has now reached end-of-life (EOL). Customers still using PostgreSQL 13 on Azure should review their upgrade options and refer to Azure’s Extended Support policy for more details.

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

January 2026 Maintenance Release Notes

We’re excited to announce the January 2026 version of Azure Database for PostgreSQL maintenance updates. This new version delivers major engine updates, new extensions, Elastic clusters enhancements, performance improvements, and critical reliability fixes. This release introduces expands migration and Fabric mirroring support, and adds powerful analytics, security, and observability capabilities across the service. Customers also benefit from improved Query Store performance, new WAL metrics, enhanced networking flexibility, and multiple Elastic clusters enhancements. All new servers are automatically onboarded beginning January 20, 2026, with existing servers upgraded during their next scheduled maintenance. 

Azure Postgres Learning Bytes

Managing Replication Lag with Debezium

Change Data Capture (CDC) enables real‑time integrations by streaming row‑level changes from OLTP systems like PostgreSQL into event streams, data lakes, caches, and microservices. In a typical CDC pipeline, Debezium captures changes from PostgreSQL and streams them into Kafka with minimal latency.

However, during large bulk updates that affect millions of rows, replication lag can spike significantly, impacting replication lag. This learning byte walks through how to detect and mitigate replication lag in Azure Database for PostgreSQL when using Debezium.

• Detect Replication Lag: Start by identifying where lag is building up in the system.
  • Monitor replication slots and lag: Use the following query to inspect active replication slots and measure how far behind they are relative to the current WAL position:

SELECT 
  slot_name, 
  active_pid, 
  confirmed_flush_lsn, 
  restart_lsn, 
  pg_current_wal_lsn(), 
  pg_size_pretty(
    (
      pg_current_wal_lsn() - confirmed_flush_lsn
    )
  ) AS lsn_distance 
FROM 
  pg_replication_slots;

• • Check WAL sender backend status: Verify whether WAL sender processes are stalled due to decoding or I/O waits:

SELECT 
  pid, 
  backend_type, 
  application_name, 
  wait_event 
FROM 
  pg_stat_activity 
WHERE 
  backend_type = 'walsender' 
ORDER BY 
  backend_start;

• • Inspect spill activity : High spill activity indicates memory pressure during logical decoding and may contribute to lag. Large values for spill_bytes or spill_count suggest the need to increase logical_decoding_work_mem, reduce transaction sizes, or tune Debezium connector throughput.

SELECT 
  slot_name, 
  spill_txns, 
  spill_count, 
  pg_size_pretty(spill_bytes) AS spill_bytes, 
  total_txns, 
  pg_size_pretty(total_bytes) AS total_bytes, 
  stats_reset 
FROM 
  pg_stat_replication_slots;

• Fix Replication Lag:
  • Database and infrastructure tuning
    Reduce unnecessary overhead and ensure compute, memory, and storage resources are appropriately scaled to handle peak workloads.

  • Connector level tuning

    Adjust Debezium configuration to keep pace with PostgreSQL WAL generation and Kafka throughput. This includes tuning batch sizes, poll intervals, and throughput settings to balance latency and stability.

To learn more about diagnosing and resolving CDC performance issues, read the full blog: Performance Tuning for CDC: Managing Replication Lag in Azure Database for PostgreSQL with Debezium