January 2026 Recap: Azure Database for PostgreSQL
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. Terraform Adds Support for PostgreSQL 18 – Generally Available Ansible module update - Generally Available Achieving Zonal Resiliency with Azure CLI - Generally Available SDKs Released : Go, Java, JavaScript, .NET and Python – Generally Available What’s New in Premium SSD v2 - Public Preview Latest PostgreSQL minor versions 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. For a complete list of features, improvements, and resolved issues, see the full release notes here. 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
joinUrl is null when fetching via /chats/
Hi we have a production app for Teams that has broken as a result of a seemingly random api change that we can't find any documentation for in the api change log or anywhere for that matter. We are sending the following request via our front end app: https://graph.microsoft.com/v1.0/chats/19:meeting_MDc0NmQ4OWYtNTNiOC00NjY2LWIzYWItZGQ3ZTQyMWFjNzk2@thread.v2 { "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#chats/$entity", "id": "19:meeting_MDc0NmQ4OWYtNTNiOC00NjY2LWIzYWItZGQ3ZTQyMWFjNzk2@thread.v2", "topic": "Besprechung mit <organiser_name>", "createdDateTime": "2025-08-21T10:41:11Z", "lastUpdatedDateTime": "2025-08-21T12:49:30.002Z", "chatType": "meeting", "webUrl": "https://teams.microsoft.com/l/chat/19%3Ameeting_MDc0NmQ4OWYtNTNiOC00NjY2LWIzYWItZGQ3ZTQyMWFjNzk2%40thread.v2/0?tenantId=<tenant_id>", "tenantId": "<tenant_id>", "isHiddenForAllMembers": false, "viewpoint": { "isHidden": false, "lastMessageReadDateTime": "2025-08-21T12:59:24.376Z" }, "onlineMeetingInfo": { "calendarEventId": null, "joinWebUrl": null, "organizer": { "id": null, "displayName": null, "userIdentityType": "aadUser" } } } In this request we would parse `onlineMeetingInfo` for the joinWebUrl however we now get `null` We've tried using the webUrl but this does not work since it doesn't contain the organisation Id which we later rely on. Our flow is the following: We make a graph api request to fetch the joinUrl We send the joinWebUrl to our backend That Url is passed to a Teams Bot we are hosting on Azure which parses the URL to send a bot join request to Microsoft. However the new webUrl does not have the organiser Id and as a result the bot fails to join. We've verified by hardcoding the organiser Id var meetingInfo = new OrganizerMeetingInfo { Organizer = new IdentitySet { User = new Identity { Id = <we_hard_coded_this> }, }, }; meetingInfo.Organizer.User.SetTenantId(tenantId) And we then use this as following: var tenantId = (meetingInfo as OrganizerMeetingInfo)?.Organizer .GetPrimaryIdentity() .GetTenantId(); var mediaSession = this.CreateLocalMediaSession(); var joinParams = new JoinMeetingParameters(chatInfo, meetingInfo, mediaSession) { TenantId = tenantId, }; if (!string.IsNullOrWhiteSpace(callParams.DisplayName)) { // Teams client does not allow changing of ones own display name. // If display name is specified, we join as anonymous (guest) user // with the specified display name. This will put bot into lobby // unless lobby bypass is disabled. joinParams.GuestIdentity = new Identity { Id = Guid.NewGuid().ToString(), DisplayName = callParams.DisplayName }; } if (!callParameters.TryAdd(chatInfo.GetMeetingId(), new() { AccessToken = callParams.AccessToken, AccountId = callParams.AccountId, BackendUrl = callParams.BackendUrl, JoinUrl = callParams.JoinUrl, Protocol = callParams.Protocol, Origin = callParams.Origin, InviterParticipantId = callParams.InviterParticipantId, SubscriptionId = callParams.SubscriptionId, })) { logger.Warning("Parameters for call already exist."); } var statefulCall = await this.Client.Calls() .AddAsync(joinParams) .ConfigureAwait(false); This is quite urgent as it's impacting our customers, could someone please have a look at provide us an update here? Thank you.Survey: Do you need long running or offline support for Cloud to Device commands with Azure IoT Hub?
In IoT, the "T" stands for Things, devices, and the "I" stands for Internet, connection. For the T, the I can sometimes be a challenge: how do you manage devices when they are not permanently connected and might not show up on the network very often? Does your current or planned IoT project require support for Cloud-To-Device long running or offline commands to devices when managed through Azure IoT Hub? Long running commands may need seconds or minutes before being executed. Offline commands are used when the device is offline: the method call is recorded by the service and sent to the device when it reconnects. Let us know in this short survey: https://aka.ms/LongCallSupportSurvey
