Sign in Subscribe

Mirroring Azure Database for PostgreSQL Flexible Server in Microsoft Fabric

Sascha Corti

• 3 min read
Mirroring Azure Database for PostgreSQL Flexible Server in Microsoft Fabric

Zero‑ETL analytics for your operational data

1  Why another replication option?

Azure Database for PostgreSQL Flexible Server already gives you two native replication technologies:

Feature

Technology

What it’s good at

Key trade‑offs

Read replicas

Asynchronous physical replication

Off‑loading read‑heavy traffic; geo‑DR; up to five replicas

Requires a full secondary server (you pay for compute + storage), always lags the primary, cannot filter individual tables, still stores data in PostgreSQL format 

Logical replication / decoding

PostgreSQL publisher‑subscriber or pglogical

Fine‑grained table‑level replication; heterogeneous targets

Requires you to stand up and operate your own subscriber and ETL, no built‑in analytics surface 

Fabric Mirroring targets a very different pain point: turning the same operational data into analytics‑ready Delta tables inside OneLake without writing or maintaining an ETL pipeline. It is a zero‑ETL, near‑real‑time path built directly into Microsoft Fabric. 

2  How Fabric Mirroring works

  1. Initial snapshot – A background job takes a snapshot of the selected tables and lands them in OneLake as Parquet files.
  2. Change capture – The proprietary azure_cdc extension (installed automatically) streams WAL changes via logical replication. 
  3. Replicator engine – Inside Fabric, the replicator converts Parquet to Delta and keeps the tables in‑sync. 
  4. Fabric objects created – Each mirror produces
    • a Mirrored database item (Delta tables in OneLake)
    • an auto‑generated SQL analytics endpoint
    • a default semantic model for Power BI Direct Lake. 

Because the data lands in open Delta format you can query it side‑by‑side with other Fabric warehouses, lakehouses or shortcuts, and even cross‑join data from Cosmos DB, Snowflake, S3 or ADLS. 

3  Advantages over native replication

  • No extra PostgreSQL compute – You pay only for the Fabric capacity you already have; there is no secondary Postgres server to manage.
  • Analytics‑ready instantly – Direct Lake in Power BI, Spark notebooks, Lakehouse, KQL database and Copilot can read the mirrored Delta tables the moment replication starts. 
  • Zero‑ETL pipeline – Setup is a guided UI; no Debezium, Airflow or custom ELT code.
  • Fine‑grained selection – Choose to replicate the whole database or only certain tables/schemas (unlike read replicas). 
  • Unified security & lineage – Mirrored data stays inside OneLake so Fabric governance, lineage and Purview scanning apply automatically.
  • Future roadmap – VNet, Private Endpoint and read‑replica sources are already on the GA roadmap. 

4  Prerequisites

Requirement

Notes

Fabric capacity

Trial or paid, must be running. 

Flexible Server tier

General Purpose or Memory Optimized (Burstable not supported). 

Networking

Public network access with “Allow Azure services” enabled; VNet/private networking not yet supported. 

Server settings

wal_level = logical, azure_cdc extension allow‑listed & pre‑loaded, max_worker_processes += 3 per mirrored DB, System‑Assigned Managed Identity enabled. 

Database role

A basic Postgres role with LOGIN, REPLICATION, CREATEDB, CREATEROLE and azure_cdc_admin.

Role‑creation script

-- run on the source database
CREATE ROLE fabric_user
  CREATEDB CREATEROLE LOGIN REPLICATION
  PASSWORD '<STRONG_PASSWORD>';
GRANT azure_cdc_admin TO fabric_user;

5  Quick start – creating a mirror

  1. Open a Fabric workspace → Create → Mirrored Azure Database for PostgreSQL (preview).
  2. Connect – Provide server name, database, and fabric_user credentials (encrypted connection recommended). 
  3. Choose data – Mirror all tables or uncheck Mirror all data and pick specific objects.
  4. Mirror database – Fabric triggers the snapshot; expect 2–5 minutes before Monitor replication shows status = Running. 

6  Monitoring and troubleshooting

Use Manage → Mirroring Status on the mirrored database item.

Level

Status

Meaning

Database

Running

Snapshot and CDC are flowing.

Running with warning

Transient errors, replication still active.

Stopping / Stopped

Replication paused or disabled.

Error

Fatal issue – review operation logs.

Table

Same states per table.

Watch the WAL size on the primary during large snapshots or long transactions; excessive WAL growth can exhaust storage. 

7  Limitations to keep in mind

  • No support (yet) for VNet/private‑endpoint sources or mirroring from a read replica. 
  • Burstable compute tier not supported as a source. 
  • Entra ID authentication for the source connection is not available in preview (use basic Postgres auth). 
  • Granular security must be recreated on the mirrored database inside Fabric. 

8  Putting the mirror to work

-- Example query from the SQL analytics endpoint (read‑only)
SELECT product_id, SUM(quantity) AS total_sold
FROM sales_order_line
GROUP BY product_id
ORDER BY total_sold DESC
LIMIT 10;

Because the SQL endpoint overlays the Delta tables, any tool that speaks T‑SQL (SSMS, VS Code mssql, Fabric notebook) can run this query immediately, and Power BI can connect in Direct Lake mode without importing data. 

Summary

Mirroring for Azure Database for PostgreSQL Flexible Server brings operational data into Microsoft Fabric with zero ETL and near‑real‑time freshness. Compared with traditional replication it removes the need for extra Postgres servers, eliminates data movement pipelines, and lights up the full Fabric ecosystem—from Lakehouse engineering to Power BI Direct Lake and AI Copilot—using open Delta format in OneLake.

Give it a spin in your Fabric workspace and start querying your production data with analytic horsepower, seconds after it is written.