Announcing Fabric Mirroring integration for Azure Database for MySQL - Public Preview at FabCon 2026
At FabCon 2026, we’re excited to announce the Public Preview of Microsoft Fabric Mirroring integration for Azure Database for MySQL. This integration makes it easier than ever to analyze MySQL operational data using Fabric’s unified analytics platform, without building or maintaining ETL pipelines. This milestone brings near real-time data replication from Azure Database for MySQL into Microsoft Fabric OneLake, unlocking powerful analytics, reporting, and AI scenarios while keeping transactional workloads isolated and performant. Why Fabric integration for Azure Database for MySQL? MySQL is widely used to power business‑critical applications, but operational databases aren’t optimized for analytics. Traditionally, teams rely on complex ETL pipelines, custom connectors, or batch exports — adding cost, latency, and operational overhead. With Fabric integration, Azure Database for MySQL now connects directly to Microsoft Fabric, enabling: Zero‑ETL analytics on MySQL operational data Near real-time synchronization into OneLake Analytics‑ready open formats for BI, data engineering, and AI A unified experience across Power BI, Lakehouse, Warehousing, and notebooks All without impacting your production workloads. What’s new in the Public Preview? The Public Preview introduces a first‑class integration between Azure Database for MySQL and Microsoft Fabric, designed for simplicity and scale. It introduces a solid set of core operational and enterprise‑readiness capabilities, enabling end-users to confidently get started and scale their analytics scenarios. Core replication operations Start, monitor, and stop replication directly from the integrated experience Support for both initial data load and continuous change data capture (CDC) to keep data in sync with minimal latency. Network and security Firewall and gateway support, enabling replication from secured MySQL environments. Support for Azure Database for MySQL servers configured with customer‑managed keys (BYOK), aligning with enterprise security and compliance requirements. Broader data coverage and troubleshooting Ability to mirror tables containing previously unsupported data types, expanding schema compatibility and reducing onboarding friction. Support for up to 1,000 tables per server, enabling larger and more complex databases to participate in Fabric analytics. Basic error messaging and visibility to help identify replication issues and monitor progress during setup and ongoing operations. What scenarios does it unlock? With Fabric integration in place, you can now analyze data in Azure Database for MySQL without impacting production, combine it with other data in Fabric for richer reporting, and use Fabric’s built‑in analytics and AI tools to get insights faster. Learn more about exploring replicated data in Fabric in Explore data in your mirrored database using Microsoft Fabric. How does it work (high level)? Fabric integration for Azure Database for MySQL follows a simple but powerful pattern: Enable and Configure - Enable replication in the Azure portal, then use the Fabric portal to provide connection details and select MySQL tables to mirror. Initial snapshot - Fabric takes a bulk snapshot of the selected tables, converts the data to Parquet, and writes it to a Fabric landing zone. Continuous change capture - Ongoing inserts, updates, and deletes are captured from MySQL binlogs and continuously written as incremental Parquet files. Analytics‑ready in Fabric - The Fabric Replicator processes snapshot and change files and applies them to Delta tables in OneLake, keeping data in sync and ready for analytics. This design ensures low overhead on the source, while providing fresh data for analytics and AI workloads. Below is a more detailed workflow illustrating how this works: Getting started with the Public Preview To try Fabric integration for Azure Database for MySQL during Public Preview, you’ll need: An Azure Database for MySQL instance An active Microsoft Fabric capacity (trial or paid) Access to a Fabric workspace Once enabled, you can select the MySQL databases and tables you want to replicate and begin analyzing data in Fabric. For step-by-step tutorial, please refer to - https://learn.microsoft.com/azure/mysql/integration/fabric-mirroring-mysql The demo video below showcases how the mirroring integration works and walks through the end-to-end experience of mirroring MySQL data into Microsoft Fabric. Stay Connected We’re thrilled to share this milestone at FabCon 2026 and can’t wait to see how you use Fabric integration for Azure Database for MySQL to simplify analytics and unlock new insights. We welcome your feedback and invite you to share your experiences or suggestions at AskAzureDBforMySQL@service.microsoft.com Try the Public Preview, share your feedback, and help shape what’s next. Thank you for choosing Azure Database for MySQL!SQL Agent Jobs in an AlwaysOn / Mirroring Environment
Running SQL Agent Jobs in an AlwaysOn or Database Mirroring environment can be a challenge, as the database might be not accessible at the time when the job starts. This is especially the case for all SAP collector and backup jobs. On the other hand there might be jobs that should not run on primary server (e.g. DBCC Checks), but on a readable secondary or readonly standby database (Log Shipping). In the worst case either the jobs fail or run on the wrong server. To prevent this, SAP created a small stored procedure to control the run of these kind of jobs. To use the stored procedure, use this script use master; GO IF (OBJECT_ID(N'dbo.CheckAccess') IS NOT NULL ) DROP PROCEDURE [dbo].CheckAccess GO CREATE PROCEDURE dbo.CheckAccess @DBName AS NVARCHAR(128) = N'master', @RunOnPrimary AS TINYINT = 1, @RunOnSecondary AS TINYINT = 0, @RunOnReadonly AS TINYINT = 0, RC AS TINYINT = 0 OUTPUT AS BEGIN DECLARE @IsReadOnly TINYINT; DECLARE @State TINYINT; DECLARE @StandBy TINYINT; DECLARE @UserAccess TINYINT; DECLARE @AOState TINYINT; DECLARE @AORole TINYINT; DECLARE @Message NVARCHAR(50); SET RC = 0; SET @Message = N'Everything is OK.'; IF EXISTS(SELECT TOP 1 database_id FROM sys.databases WHERE database_id = DB_ID(@DBName)) BEGIN -- Check for the normal database state SELECT @IsReadOnly = is_read_only, @State = state, @StandBy = is_in_standby, @UserAccess = user_access FROM sys.databases WHERE name = @DBName; IF NOT ((@State + @UserAccess) = 0 AND (@IsReadOnly <= @RunOnReadonly) AND (@StandBy <= @RunOnReadonly)) BEGIN SET RC = 1; SET @Message = N'Database is NOT accessible.'; END; END ELSE BEGIN SET RC = 2; SET @Message = N'Database doesn''t exists.'; END -- Check if we are running in an AlwaysOn Configuration IF EXISTS(SELECT TOP 1 database_id FROM sys.dm_hadr_database_replica_states WHERE database_id = DB_ID(@DBName)) BEGIN SELECT @AOState = db.database_state, @AORole = rs.role FROM sys.dm_hadr_database_replica_states AS db INNER JOIN sys.dm_hadr_availability_replica_states AS rs ON db.group_id = rs.group_id WHERE db.is_local = 1 AND rs.is_local = 1 AND db.database_id = DB_ID(@DBName) IF NOT(@AOState = 0 AND ((@RunOnPrimary != 0 AND @RunOnPrimary = @AORole) OR (@RunOnSecondary != 0 AND @RunOnSecondary = @AORole - 1))) BEGIN SET RC = 3; SET @Message = N'The database is not in the required state for Always-ON access.'; END; END; PRINT @Message END; GO and run it on all nodes of the affected system (either AlwaysOn, Database Mirroring or Log Shipping). It will create a stored procedure CheckAccess in the master database. The procedure has 5 parameters: Parameter Data Type Default Value Description @DBName NVARCHAR(128) N'master' Database to check. @RunOnPrimary TINYINT 1 Should the job run on the primary database ? @RunOnSecondary TINYINT 0 Should the job run on the secondary database ? @RunOnReadonly TINYINT 0 Should the job run on the read only databases (Log Shipping) ? RC TINYINT 0 Return code (0 = Success, 1 = Failure) With the parameters @RunOnPrimary, @RunOnSecondary and @RunOnReadonly you can control in which state of the AlwaysOn database the Job should start. A combination of these parameters is possible, so the job can run on primary and secondary databases if you set both to 1. Even if you do not use AlwaysOn or readonly databases or if you set all the options to 0 the stored procedure will check for the availability of the database. It will return a failure (1) if the database is absent, offline, suspect, in recovery and all the other states that won't let you access the database. A valid call looks like this (Check the TST database if it is accessible and check if it is the primary database in an AlwaysOn configuration): exec dbo.CheckAccess N'TST',1,0,0,@RC OUTPUT To enable the CheckAccess stored procedure for jobs, we have to change the job a bit. In this example it is an SAP Collector Job (SAP_SCU_SAPMonitor_TST_MSSQL_COLLECTOR) for the TST SAP database. Open the properties for the job (right click -> Properties) Switch to the Steps branch on the left and edit the first step with the name DBCOLL. Change the database to master (as the stored procedure lives there) and change the script from EXECUTE sap_dbcoll to DECLARE @Msg NVARCHAR(128) DECLARE RC TINYINT exec dbo.CheckAccess N'TST',1,0,0,@RC OUTPUT IF RC = 0 exec( 'use [TST] EXECUTE sap_dbcoll' ) Ensure that you change the database accordingly (here TST) for your system. The step then should look like: On the advanced tab change the 'On failure action' field to 'Quit the job reporting failure' and save and exit the job definition. This will ensure that the DBCOLL part will only start when the database is accessible and is the primary database in the AlwaysOn Configuration. You can use this stored procedure for any job, when you follow this generic approach: DECLARE @Msg NVARCHAR(128) DECLARE RC TINYINT exec dbo.CheckAccess N'<Database in Question>',1,0,0,@RC OUTPUT IF RC = 0 exec( 'use [<Database in Question>] <Step definition>' ) Regards ClasGeneral Availability of Mirroring Azure Database for PostgreSQL in Microsoft Fabric Is Here!
Unlock Real-Time Analytics on Operational Data—Now Enterprise-Ready Few weeks ago at Microsoft Ignite 2025, we announced General Availability (GA) of Mirroring for Azure Database for PostgreSQL flexible server in Microsoft Fabric. This milestone marks a major leap forward in empowering organizations to seamlessly integrate their operational PostgreSQL data into the Microsoft Fabric analytics ecosystem—enabling near real-time analytics, machine learning, and business intelligence without the complexity of traditional ETL pipelines. Why Mirror Operational Databases in Microsoft Fabric? Accelerate Analytics Without ETL Fabric Mirroring eliminates the need for complex, custom ETL pipelines. Data from your operational PostgreSQL databases is continuously replicated into OneLake as Delta tables, making it instantly available for analytics, machine learning, and reporting. This means you can: Run advanced analytics and AI on live data without impacting production workloads. Empower data scientists to experiment and innovate with up-to-date data. Create real-time dashboards and cross-database queries for comprehensive business insights. Unify governance and security under OneLake, reducing risk and operational overhead. Enterprise-Grade Security and Compliance With support for Entra ID, VNETs, and Private Endpoints, organizations can enforce strict access controls and network isolation. Mirroring is designed to meet the needs of highly regulated industries, ensuring data privacy and compliance at every step. High Availability and Reliability The new HA support ensures that mirroring sessions remain resilient to failures, delivering uninterrupted analytics even during server failovers. This is essential for mission-critical applications where downtime is not an option. Cost Efficiency and Simplicity Mirroring is offered at no additional cost, dramatically reducing the total cost of ownership for analytics solutions. By removing ETL complexity, organizations can focus on extracting value from their data rather than managing infrastructure. What’s New in GA? Building on the momentum of our Public Preview, the GA release introduces several enterprise-grade enhancements: Microsoft Entra ID Authentication: Secure, centralized identity management for all mirroring operations. Entra ID authentication streamlines access control and compliance, making it easier for organizations to manage users and roles across their data estate. VNET and Private Endpoint Support: Mirroring now works with PostgreSQL Flexible Servers deployed behind Virtual Networks (VNETs) and Private Endpoints, ensuring secure, private connectivity with no public exposure. This is critical for regulated industries and enterprises with strict security requirements. High Availability (HA) Support: Mirroring is now compatible with HA-enabled servers, delivering business continuity and seamless failover for mission-critical workloads. For PostgreSQL 17+, replication slot failover ensures uninterrupted mirroring even during planned or unplanned outages. Performance and Reliability Enhancements: The replication engine has been optimized for smoother onboarding, improved error handling, and higher throughput—supporting initial snapshot rates up to ~1TB/hour and change data capture (CDC) with minimal latency (as low as 5 seconds under optimal conditions). For a full list of prerequisites and setup guidance, see the official documentation. Microsoft Entra ID Authentication Support for Entra ID database roles includes: Setting up initial replication Managing ongoing Fabric communications Enabling Entra ID authentication on Flexible Server Handling Entra ID roles within your databases Choosing your role type for Mirroring VNET and Private Endpoint Support This feature ensure secure and efficient connectivity for flexible servers within Microsoft Fabric. Connecting to a flexible server without public connectivity enhances security during both initial setup and ongoing operations. Establishing a Virtual Network Gateway on the target VNET facilitates encrypted traffic between networks, while subnet delegation allows specific resources within a subnet to be managed for specialized tasks. The system supports servers restricted by Virtual Network (VNET) and Private Endpoint configurations, enabling robust network isolation and protection from unauthorized access. High Availability (HA) Support Fabric Mirroring supports high availability by enabling seamless failover and enhanced fault tolerance for servers configured with HA. This feature requires PostgreSQL version 17 or later, as replication slot failover is only available in these versions. If you are using an earlier PostgreSQL version, you will need to manually reconfigure mirroring after each failover event to maintain replication. Beyond PostgreSQL: Interoperability Across Azure Databases Fabric Mirroring is not limited to PostgreSQL. The GA release also includes support for other databases like: SQL Server (2016–2025): Native mirroring for on-premises, Azure VMs, and non-Azure clouds, with secure connectivity and analytics-ready Delta tables. Snowflake: Mirroring for managed and Apache Iceberg tables, enabling high-performance analytics and open-format interoperability. Cosmos DB: Continuous change capture and mirroring for globally distributed NoSQL data, supporting real-time personalization, fraud detection, and IoT analytics. This interoperability allows organizations to consolidate data from diverse sources into OneLake, unlocking unified analytics and AI across their entire data estate. By leveraging shortcuts in Microsoft Fabric, customers can reference data stored in different mirrored databases and storage accounts as if it resided in a single location. This means users can build cross-database queries and analytics pipelines without physically moving or duplicating data, avoiding the need for complex ETL processes or data integration solutions. Shortcuts make it possible to seamlessly join, analyze, and visualize data from SQL Server, Snowflake, Cosmos DB, and more within OneLake, streamlining analytics workflows and accelerating time to insight while reducing storage costs and operational overhead. Getting Started Ready to experience the power of Mirroring for Azure Database for PostgreSQL Flexible Server in Microsoft Fabric? Step-by-step tutorial: https://learn.microsoft.com/azure/postgresql/flexible-server/concepts-fabric-mirroring#enable-fabric-mirroring-in-the-azure-portal Role-based access guidance: https://learn.microsoft.com/fabric/mirroring/azure-database-postgresql-tutorial#database-role-for-fabric-mirroring Monitor and troubleshoot: https://learn.microsoft.com/azure/postgresql/flexible-server/concepts-fabric-mirroring#troubleshooting Public documentation: Fabric Mirroring for Azure Database for PostgreSQL Future Enhancements Looking ahead to the next future, our focus will be on delivering a series of post-GA enhancements designed to make Mirroring for Azure Database for PostgreSQL Flexible Server even more robust, versatile, and user-friendly. Key advancements will be in the following areas: automatic replication for newly created database tables when operating in auto-mode, ensuring that your mirrored environments remain up to date with minimal manual intervention. enhanced support for advanced DDL operations, giving users greater flexibility and control when managing schema changes on mirrored databases. expanding compatibility with additional data types—such as JSON, arrays, ranges, and geometry—will open up new scenarios for analytics and data integration, accommodating a wider range of workloads and use cases. support for partitioned tables, TOAST tables, and views will allow organizations to mirror more complex database structures, further streamlining operational analytics. enable the ability to mirror databases hosted on Read Replicas, which will help organizations optimize their high-availability and scaling strategies without compromising data consistency. Collectively, these planned features underscore our commitment to continuous improvement and to meeting the evolving needs of our users as they harness the full power of Microsoft Fabric for unified data analytics and AI. Conclusion The General Availability of Mirroring for Azure Database for PostgreSQL Flexible Server in Microsoft Fabric represents a significant advancement for organizations seeking to unlock real-time analytics, AI, and BI on their operational data—securely, reliably, and without ETL complexity. With new enterprise features, proven customer success, and broad interoperability, now is the perfect time to bring your operational databases into the Microsoft Fabric analytics era. Learn more and get started today: Fabric Mirroring for Azure Database for PostgreSQLAnnouncing 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.July 2025 Recap: Azure Database for PostgreSQL
Hello Azure Community, July delivered a wave of exciting updates to Azure Database for PostgreSQL! From Fabric mirroring support for private networking to cascading read replicas, these new features are all about scaling smarter, performing faster, and building better. This blog covers what’s new, why it matters, and how to get started. Catch Up on POSETTE 2025 In case you missed POSETTE: An Event for Postgres 2025 or couldn't watch all of the sessions live, here's a playlist with the 11 talks all about Azure Database for PostgreSQL. And, if you'd like to dive even deeper, the Ultimate Guide will help you navigate the full catalog of 42 recorded talks published on YouTube. Feature Highlights Upsert and Script activity in ADF and Azure Synapse – Generally Available Power BI Entra authentication support – Generally Available New Regions: Malaysia West & Chile Central Latest Postgres minor versions: 17.5, 16.9, 15.13, 14.18 and 13.21 Cascading Read Replica – Public Preview Private Endpoint and VNet support for Fabric Mirroring - Public Preview Agentic Web with NLWeb and PostgreSQL PostgreSQL for VS Code extension enhancements Improved Maintenance Workflow for Stopped Instances Upsert and Script activity in ADF and Azure Synapse – Generally Available We’re excited to announce the general availability of Upsert method and Script activity in Azure Data Factory and Azure Synapse Analytics for Azure Database for PostgreSQL. These new capabilities bring greater flexibility and performance to your data pipelines: Upsert Method: Easily merge incoming data into existing PostgreSQL tables without writing complex logic reducing overhead and improving efficiency. Script Activity: Run custom SQL scripts as part of your workflows, enabling advanced transformations, procedural logic, and fine-grained control over data operations. Together, these features streamline ETL and ELT processes, making it easier to build scalable, declarative, and robust data integration solutions using PostgreSQL as either a source or sink. Visit our documentation guide for Upsert Method and script activity to know more. Power BI Entra authentication support – Generally Available You can now use Microsoft Entra ID authentication to connect to Azure Database for PostgreSQL from Power BI Desktop. This update simplifies access management, enhances security, and helps you support your organization’s broader Entra-based authentication strategy. To learn more, please refer to our documentation. New Regions: Malaysia West & Chile Central Azure Database for PostgreSQL has now launched in Malaysia West and Chile Central. This expanded regional presence brings lower latency, enhanced performance, and data residency support, making it easier to build fast, reliable, and compliant applications, right where your users are. This continues to be our mission to bring Azure Database for PostgreSQL closer to where you build and run your apps. For the full list of regions visit: Azure Database for PostgreSQL Regions. Latest Postgres minor versions: 17.5, 16.9, 15.13, 14.18 and 13.21 PostgreSQL latest minor versions 17.5, 16.9, 15.13, 14.18 and 13.21 are now supported by Azure Database for PostgreSQL flexible server. These minor version upgrades are automatically performed as part of the monthly planned maintenance in Azure Database for PostgreSQL. This upgrade automation ensures that your databases are always running on the most secure and optimized versions without requiring manual intervention. This release fixes two security vulnerabilities and over 40 bug fixes and improvements. To learn more, please refer PostgreSQL community announcement for more details about the release. Cascading Read Replica – Public Preview Azure Database for PostgreSQL supports cascading read replica in public preview capacity. This feature allows you to scale read-intensive workloads more effectively by creating replicas not only from the primary database but also from existing read replicas, enabling two-level replication chains. With cascading read replicas, you can: Improve performance for read-heavy applications. Distribute read traffic more efficiently. Support complex deployment topologies. Data replication is asynchronous, and each replica can serve as a source for additional replicas. This setup enhances scalability and flexibility for your PostgreSQL deployments. For more details read the cascading read replicas documentation. Private Endpoint and VNET Support for Fabric Mirroring - Public Preview Microsoft Fabric now supports mirroring for Azure Database for PostgreSQL flexible server instances deployed with Virtual Network (VNET) integration or Private Endpoints. This enhancement broadens the scope of Fabric’s real-time data replication capabilities, enabling secure and seamless analytics on transactional data, even within network-isolated environments. Previously, mirroring was only available for flexible server instances with public endpoint access. With this update, organizations can now replicate data from Azure Database for PostgreSQL hosted in secure, private networks, without compromising on data security, compliance, or performance. This is particularly valuable for enterprise customers who rely on VNETs and Private Endpoints for database connectivity from isolated networks. For more details visit fabric mirroring with private networking support blog. Agentic Web with NLWeb and PostgreSQL We’re excited to announce that NLWeb (Natural Language Web), Microsoft’s open project for natural language interfaces on websites now supports PostgreSQL. With this enhancement, developers can leverage PostgreSQL and NLWeb to transform any website into an AI-powered application or Model Context Protocol (MCP) server. This integration allows organizations to utilize a familiar, robust database as the foundation for conversational AI experiences, streamlining deployment and maximizing data security and scalability. For more details, read Agentic web with NLWeb and PostgreSQL blog. PostgreSQL for VS Code extension enhancements PostgreSQL for VS Code extension is rolling out new updates to improve your experience with this extension. We are introducing key connections, authentication, and usability improvements. Here’s what we improved: SSH connections - You can now set up SSH tunneling directly in the Advanced Connection options, making it easier to securely connect to private networks without leaving VS Code. Clearer authentication setup - A new “No Password” option eliminates guesswork when setting up connections that don’t require credentials. Entra ID fixes - Improved default username handling, token refresh, and clearer error feedback for failed connections. Array and character rendering - Unicode and PostgreSQL arrays now display more reliably and consistently. Azure Portal flow - Reuses existing connection profiles to avoid duplicates when launching from the portal. Don’t forget to update to the latest version in the Marketplace to take advantage of these enhancements and visit our GitHub to learn more about this month’s release. Improved Maintenance Workflow for Stopped Instances We’ve improved how scheduled maintenance is handled for stopped or disabled PostgreSQL servers. Maintenance is now applied only when the server is restarted - either manually or through the 7-day auto-restart rather than forcing a restart during the scheduled maintenance window. This change reduces unnecessary disruptions and gives you more control over when updates are applied. You may notice a slightly longer restart time (5–8 minutes) if maintenance is pending. For more information, refer Applying Maintenance on Stopped/Disabled Instances. Azure Postgres Learning Bytes 🎓 Set Up HA Health Status Monitoring Alerts This section will talk about setting up HA health status monitoring alerts using Azure Portal. These alerts can be used to effectively monitor the HA health states for your server. To monitor the health of your High Availability (HA) setup: Navigate to Azure portal and select your Azure Database for PostgreSQL flexible server instance. Create an Alert Rule Go to Monitoring > Alerts > Create Alert Rule Scope: Select your PostgreSQL Flexible Server Condition: Choose the signal from the drop down (CPU percentage, storage percentage etc.) Logic: Define when the alert should trigger Action Group: Specify where the alert should be sent (email, webhook, etc.) Add tags Click on “Review + Create” Verify the Alert Check the Alerts tab in Azure Monitor to confirm the alert has been triggered. For deeper insight into resource health: Go to Azure Portal > Search for Service Health > Select Resource Health. Choose Azure Database for PostgreSQL Flexible Server from the dropdown. Review the health status of your server. For more information, check out the HA Health status monitoring documentation guide. Conclusion That’s a wrap for our July 2025 feature updates! Thanks for being part of our journey to make Azure Database for PostgreSQL better with every release. We’re always working to improve, and your feedback helps us do that. 💬 Got ideas, questions, or suggestions? We’d love to hear from you: https://aka.ms/pgfeedback 📢 Want to stay on top of Azure Database for PostgreSQL updates? Follow us here for the latest announcements, feature releases, and best practices: Azure Database for PostgreSQL Blog Stay tuned for more updates in our next blog!
Copy of Sharepoint list
Hi, I tried to make a backup of a Sharepoint-List with Acces and i created accidentally a new list in Sharepoint with the same URL, same ID and all the same data from the another one. Now if i create or delete an item in one of the lists it will be also created/deleted in the another one. How can i delete the Mirror-list in Sharepoint? I need to delete one of them, because if not, i can not connect power BI with that list (Power BI show me the following error: The key matched more than one row in the table.) URL of both lists: i would be so thankful if someone can help me with that issue! Best Regards Sebastian
