2026-10-01. Microsoft's Azure Updates lists it as "Launched," which the service defines as fully released and production-ready for all Azure customers. The Azure Updates page captured for this story rendered as a generic listing, so the title and date come from the update metadata. The details below come from Microsoft Learn's API release notes. That page says versions not listed there might be supported but will be retired soon.
What kind of release this is
This is a control-plane change, not a PostgreSQL engine release. The REST API is the Azure Resource Manager interface for creating and managing PostgreSQL flexible server resources. Those resources include servers, databases, firewall rules, network configuration and configurations. The version goes into requests as the api-version query parameter. A server GET, for example, targets management.azure.com under Microsoft.DBforPostgreSQL/flexibleServers/{serverName}, and the 2026-10-01 documentation shows api-version=2026-10-01 in that call.
Nothing happens to your databases automatically. The change matters if you call ARM directly, use ARM templates or Bicep, or use AzAPI in Terraform.
What 2026-10-01 adds
Microsoft's release notes describe the version as including everything from earlier stable versions, plus the following additions:
- Maintenance management: Rescheduling planned maintenance, applying updates on demand, viewing upcoming maintenance, and retrieving maintenance history.
- Networking: Migrating servers from virtual network (VNet) integration to public access and private endpoint-capable networking.
- FIPS: Creating servers with FIPS enabled, and enabling or disabling it on existing servers.
- Immutable backups: Creating servers with immutable backups enabled.
- Major version upgrades: Running pre-upgrade validation checks before a major version upgrade.
- Autonomous tuning:
vacuumTableas a supported option. - Cross-tenant customer-managed keys: Configuring cross-tenant encryption with customer-managed keys, with or without geo-redundant backups.
- Version flexibility: The PostgreSQL version enumeration constraint is removed. Server creation and major version upgrades can then accept newly released PostgreSQL versions without an API schema update.
Why it matters: preview features reach GA
Several of these features were already available in preview. The 2026-01-01-preview version introduced the VNet migration capability. The maintenance-event REST APIs started with 2026-04-01-preview, and Azure CLI 2.88.0 and later offers the same capabilities. The 2026-04-01-preview version also introduced the major-version-upgrade precheck API and the cross-tenant CMK properties.
Preview APIs can change or be removed. A stable version gives teams a version they can use in production templates and pipelines.
The version-flexibility change is arguably the quietest and most useful. Earlier stable versions listed PostgreSQL majors in an enumeration. The 2025-08-01 release, for instance, added PostgreSQL 17 support. Dropping the constraint should mean automation won't need a new API version each time a PostgreSQL major version ships. That is my reading of Microsoft's description. Whether a given Azure region offers a given PostgreSQL version is a separate question that the API schema doesn't answer.
Checking the new version
The server GET reference for 2026-10-01 shows the returned server schema. It covers areas such as authentication, high availability, networking, private endpoint connections, replication role, state and storage. It also shows the FIPS setting, which defaults to Disabled if you don't specify it at creation. That schema display doesn't tell you what is new, so use the release notes for the change list.
How to adopt it
- Identify where
api-versionis pinned: ARM templates, Bicep, scripts, REST clients or AzAPI resources. - Check the operation-specific documentation for each resource you automate before changing the version string.
- Test in a non-production subscription first.
- Keep the standard request requirements: a subscription ID, resource group and server name in the URL,
Content-Type: application/json, and anAuthorizationheader with a JSON Web Token from Microsoft Entra ID. - Move production automation once your tests pass.
If your tooling uses preview APIs only to reach the features above, such as maintenance control, you may be able to move to a stable version.
What isn't established
- SDKs and tooling: The Learn pages reviewed don't say when SDKs, the AzureRM Terraform provider or the portal will target
2026-10-01. The January 2026 SDKs for Go, Java, JavaScript, .NET and Python were built on the 2025-08-01 GA API. Check your specific library before assuming support. - Retirement dates: No retirement date for older stable versions was found. The general warning about unlisted versions is not a dated notice for
2025-08-01. - Documentation lag: Some Learn pages still show older examples. The REST API landing page gives
2025-08-01as its example stable version. The release notes in other locales also still list2026-04-01-previewas the newest entry. Rely on the version-specific reference and the English release notes with the2026-10-01row. - Preview-only items: The
2026-07-01-previewversion adds PostgreSQL 19 to the enumeration, the DBAgent resource, and Premium SSD v2 and storage autogrow properties. None of those are listed as part of the stable release.
Bottom line
For teams automating Azure PostgreSQL, 2026-10-01 is the stable ARM version that brings maintenance control, VNet migration, FIPS, immutable backups, upgrade prechecks and cross-tenant CMK into production-ready territory. Compatibility with your SDKs and infrastructure-as-code tooling is the main thing to verify before you migrate.