October 2025 Recap: Azure Database for PostgreSQL
Hello Azure Community, We are excited to bring October 2025 recap blog for Azure Database for PostgreSQL! This blog focuses on key announcements around the General Availability of the REST API for 2025, maintenance payload visibility and several new features aimed at improving performance and a guide on minimizing downtime for MVU operation with logical replication. Stay tuned as we dive deeper into each of these feature updates. Get Ready for Ignite 2025! Before we get into the feature breakdown, Ignite is just around the corner! It’s packed with major announcements for Azure Database for PostgreSQL. We’ve prepared a comprehensive guide to all the sessions we have lined up, don’t miss out! Follow this link to explore the Ignite session guide. Feature Highlights Stable REST API release for 2025 – Generally Available Maintenance payload visibility – Generally Available Achieving Zonal resiliency for High-Availability workloads - Preview Japan West now supports zone-redundant HA PgBouncer 1.23.1 version upgrade Perform Major Version upgrade (MVU) with logical replication PgConf EU 2025 – Key Takeaways and Sessions Stable REST API release for 2025 – Generally Available We’ve released the stable REST API version 2025-08-01! This update adds support for PostgreSQL 17 so you can adopt new versions without changing your automation patterns. We also introduced the ability to set the default database name for Elastic Clusters. To improve developer experience, we have renamed operation IDs for clearer navigation and corrected HTTP response codes so scripts and retries behave as expected. Security guidance gets a boost with a new CMK encryption example that demonstrates automatic key version updates. Finally, we have cleaned up the specification itself by renaming files for accuracy, reorganizing the structure for easier browsing and diffs, and enhancing local definition metadata, delivering a clearer, safer, and more capable API for your 2025 roadmaps. Learn how to call or use Azure Database for PostgreSQL REST APIs. Learn about the operations available in our latest GA REST API. Repository for all Released GA APIs. Maintenance payload visibility – Generally Available The Azure Database for PostgreSQL maintenance experience has been enhanced to increase transparency and control. With this update, customers will receive Azure Service Health notifications that include a direct link to the detailed maintenance payload for each patch. This means you’ll know exactly what’s changing – helping you plan ahead, reduce surprises, and maintain confidence in your operations. Additionally, all maintenance payloads are now published in the dedicated Maintenance Release Notes section of our documentation. This enhancement provides greater visibility into upcoming updates and empowers you with the information needed to align maintenance schedules with your business priorities. Achieving Zonal resiliency for High-Availability workloads - Preview High Availability is important to ensure that you have your primary and standby servers deployed with same-zone or zone-redundant HA option. Zonal resiliency helps you protect your workloads against zonal outage. With the latest update, Azure Portal introduces a Zonal Resiliency setting under the High Availability section. This setting can be toggled Enabled or Disabled: Enabled: The system attempts to create the standby server in a different availability zone, activating zone-redundant HA mode. If the selected region does not support zone-redundant HA, you can select the fallback checkbox (shown in the image) to use same-zone HA instead. If you don’t select the checkbox and zonal capacity is unavailable, HA enablement fails. This design enforces zone-redundant HA as the default while providing a controlled fallback to same-zone HA, ensuring workloads achieve resiliency even in regions without multi-zone capacity. The feature offers flexibility while maintaining strong high availability across supported regions. To know more about how to configure high availability follow our documentation link. Japan West now supports zone-redundant HA Azure Database for PostgreSQL now offers Availability Zone support in Japan West, enabling deployment of zone-redundant high availability (HA) configurations in this region. This enhancement empowers customers to achieve greater resiliency and business continuity through robust zone-redundant architecture. We’re committed to bringing Azure PostgreSQL closer to where you build and run your apps, while ensuring robust disaster recovery options. For the full list of regions visit: Azure Database for PostgreSQL Regions. PgBouncer 1.23.1 version upgrade PgBouncer 1.23.1 is now available in Azure Database for PostgreSQL. As a Built-In connection pooling feature, PgBouncer helps you scale thousands of connections with low overhead by efficiently managing idle and short-lived connections. With this update, you benefit from the latest community improvements, including enhanced protocol handling and important stability fixes, giving you a more reliable and resilient connection pooling experience. Because PgBouncer is integrated into Azure Postgres, you don’t need to install or maintain it separately - simply enable it on port 6432 and start reducing connection overhead in your applications. This release keeps your PostgreSQL servers aligned with the community while providing the reliability of a managed Azure service. Learn More - PgBouncer in Azure Database for PostgreSQL. Perform Major Version upgrade (MVU) with logical replication Our Major Version Upgrade feature ensures you always have access to the latest and most powerful capabilities included in each PostgreSQL release. We’ve published a new blog that explains how to minimize downtime during major version upgrades by leveraging logical replication and virtual endpoints. The blog highlights two approaches: Using logical replication and virtual endpoints on a Point-in-Time Restore (PITR) instance Using logical replication and virtual endpoints on a server running different PostgreSQL versions, restored via pg_dump and pg_restore Follow this guide to get started and make your upgrade process smoother: Upgrade Azure Database for PostgreSQL with Minimal Downtime Using Logical Replication PgConf EU 2025 – key takeaways and sessions The Azure Database for PostgreSQL team participated in PGConf EU 2025, delivering insightful sessions on key PostgreSQL advancements. If you missed the highlights, here are a few topics we covered: AIO in PG 18 and beyond, by Andres Freund of Microsoft [Link to slides] Improved Freezing in Postgres Vacuum: From Idea to Commit, by Melanie Plageman of Microsoft [Link to slides] Behind Postgres 18: The People, the Code, & the Invisible Work [Link to Slides] Read the PGConf EU summary blog here. Azure Postgres Learning Bytes 🎓 Handling “Cannot Execute in a Read-Only Transaction” after High Availability (HA) Failover After a High Availability (HA) failover, some applications may see this error: ERROR: cannot execute <command> in a read-only transaction This happens when the application continues connecting to the old primary instance, which becomes read-only after failover. The usual cause is connecting via a static-IP or a private DNS record that doesn’t refresh automatically. Resolution Steps Use FQDN - Always connect using FQDN i.e. “<servername>.postgres.database.azure.com” instead of a hardcoded IP. Validate DNS - Run “nslookup yourservername.postgres.database.azure.com” to confirm resolution to the current primary. Private DNS - Update or automate the A-record refresh after failover. Best Practices Always use FQDN for app database connectivity. Add retry logic for transient failovers. Periodically validate DNS resolution for HA-enabled servers. For more details, refer to this detailed blog post from CSS team. Conclusion 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. Follow us here for the latest announcements, feature releases, and best practices: Microsoft Blog for PostgreSQL.Lesson Learned #526: How to Identify the REST API Version Used by Your PowerShell Commands?
A few days ago, I wanted to understand which REST API version was being used behind each PowerShell command I was running to create Azure SQL Database servers. To investigate, I picked a simple command: Get-AzSqlServer -ResourceGroupName "ResourceGroupName" -ServerName "servername". Remember that Get-AzSqlServer cmdlet is a PowerShell wrapper over the Azure REST API for the Microsoft.Sql/servers resource. Internally, it makes a call to the ARM endpoint documented here, passing the required api-version. The actual version used depends on the installed Az.Sql module and may vary from one environment to another. I found that setting the variable $DebugPreference = "Continue" in my PowerShell Script , PowerShell prints detailed internal debug output, including the exact REST API call sent to Azure Resource Manager (ARM). Checking the output I've found the section called: Absolute Uri: https://management.azure.com/subscriptions/xxx-xxxx--613ccd2df306/resourceGroups/ResourceGroupName/providers/Microsoft.Sql/servers/servername?api-version=2023-02-01-preview So, it seems that running this command we could see this info. Even though you don’t explicitly define the api-version when using cmdlets like Get-AzSqlServer, the Azure platform requires it under the hood. The version used determines, which properties are available or supported, what operations behave differently across versions, whether the call will succeed once older versions are retired, etc.. For example, by using Azure CLI from the Portal, I was able to see the most recent API versions. It’s also important to note that, if your organization has .NET code managing Azure SQL Database environments, the underlying REST API calls might still be using an outdated preview version.
Sharepoint Rest API - issues GetFileByServerRelativeFilePath- File content retrieve issue Postman
Hi Team, I am using rest apis to get sharepoint file content. While trying to fetch the file content Iam facing issues using postman. The authentication etc is right using Azure AD application only authentication. Rest api below <org>details and api GetFileByServerRelativePath('relative path and file name Response Cannot deserialize data for type Microsoft SharePoint SPResourcePath Tried both Relative path and URL if I add Get File By Server Relative url then I get the below error Which is wrong The file File path doesnot exist
Get Display Names of User Properties in SharePoint API
I am doing a pnp Rest API to get All the user properties from SharePoint. But what I get is an array of objects. like [{"Key":"contoso" , Value: "something"}] But in the Key The API returns the "Name" of the property. What I am looking for is "Display Name". For example in the below picture you can see "Name" and that value is returned in the "Key" but I want to get "Display Name".Sharepoint REST API: How to retrieve all columns of all records via RenderListDataAsStream api
Hello, I have a sharepoint online list with 14k+ rows and 250+columns, 35+ of them being lookups. We have reached the maximum number of fields that can be indexed. It's a legacy list and it's used a source of data entry, not for documents/files. I am trying to retrieve via REST api all the rows (and all its columns), however, I am facing an issue while doing so. Here is all that I've tried: I used the Items endpoint, I get all columns but the lookup fields contain Id and not the actual LookUp value itself. I cannot use $expand because it crosses the threshold limit for number of lookups being expanded I used the RenderListDataAsStream api, and configured the body of the request with a ViewXML property to define the CAML query and omitted the "ViewFields" defintion while specifying pagination and RowLimit. This works like a charm except not all fields are returned, some lookup fields are left out. It also leaves out some of the Indexed lookup fields. I cannot specify all the columns in "ViewFIelds" because then it throws a threshold limit error I tried using Items/(ITEM_ID)/FieldValuesAsText and this works fine except the date fields have values that are not what we want/expect. I then tried using Items/(ITEM_ID)/Versions?$top=1 (AND) Items/(ITEM_ID)/Versions?$filter=IsCurrentVersion eq true and this seems to solve the problem but again, some date field values are confusing Most of the date fields are stored as DateOnly but when we retrieve via normal Items they return in UTC format which is fine. Can someone help/point me in the right direction please? Thanks
Update Group SharePoint Custom Field Collums after Fileupload with REST Graph API
Hi, I've made an upload with Graph with the following JS code: async function uploadSingleFileMetaToSharepoint(file, name, metaData, groupId, graphAccessToken) { //console.log(file, name, metaData, groupId); //TODO get Filepath from config of App let pathToFiles = 'General' let apiurl = msgraph + `/groups/${groupId}/drive/root:/${pathToFiles}/${name}:/content`; if (debug) { console.log("uploading File: ", file); console.log(`API-URL: ${apiurl}`); } let header = { 'Authorization': graphAccessToken, } let body = file; //TODO catch errors let result = await fetch(apiurl, { "method": 'PUT', "headers": header, "body": body }); if (!result.ok) { console.error("upload file to sharepoint failed"); return } let res = await result.json(); //console.log(res); if (res === undefined || res.id === undefined) {console.error("Die DAtei wurde nicht hochgeladen"); return;} /... } which is working fine. But now i'm struggling to fill the values of the collumns from sharepoint : Does anybody know how to approach this?
SharePoint follow documents Rest API not working
Hi Community, I have been using SharePoint online rest end point to get users followed documents. The end point is https://confizpk.sharepoint.com/sites/mySales/en-us/_api/social.following/my/followed(types=2) I was able to get follow docs in the response but from last couple of hours, this end point has stopped working and not receiving the docs in response. Is there any outage on Microsoft side ? Regards, Tayyab
