# Zero-ETL Patterns with Microsoft Fabric

**Last updated:** 2026-02
**Status:** GA (Database Mirroring), Preview (Open Mirroring for some sources)
**Category:** Data Engineering for AI

---

## Introduksjon

Zero-ETL i Microsoft Fabric representerer et paradigmeskifte i hvordan organisasjoner integrerer og konsoliderer data. I stedet for komplekse Extract-Transform-Load (ETL) pipelines, tilbyr Fabric **Mirroring** — en nær-sanntids, kontinuerlig replikeringsløsning som speilser operasjonelle data direkte inn i OneLake som Delta Lake-tabeller.

### Hva er Mirroring i Fabric?

Mirroring er en **zero-ETL, SaaS-basert løsning** som:
- Kontinuerlig replikerer data fra operasjonelle systemer til OneLake
- Konverterer data automatisk til Delta Lake format (åpen standard)
- Holder data synkronisert i nær-sanntid (ned til 15 sekunders latens)
- Eliminerer behov for kompleks dataintegrasjon og pipeline-vedlikehold
- Ikke påvirker ytelsen til kildesystemet (spesielt Azure Cosmos DB — ingen RU consumption)

**Confidence marker:** [HIGH] — GA-funksjonalitet for de fleste støttede kilder, dokumentert i offisiell Microsoft-dokumentasjon (februar 2026).

---

## Kjernekomponenter

### 1. Database Mirroring

Database mirroring replikerer **hele databaser og tabeller** til OneLake. Dette er den primære zero-ETL-tilnærmingen for de fleste kilder.

**Støttede kilder (februar 2026):**

| Kilde | Status | Type | Latens |
|-------|--------|------|--------|
| Azure SQL Database | GA | Database mirroring | Nær-sanntid |
| Azure SQL Managed Instance | GA | Database mirroring | Nær-sanntid |
| Azure Database for PostgreSQL | GA | Database mirroring | Nær-sanntid |
| SQL Server (on-prem/VM) | GA | Database mirroring | Nær-sanntid |
| Azure Cosmos DB (NoSQL) | GA | Database mirroring | Nær-sanntid (ingen RU-påvirkning) |
| Snowflake | GA | Database mirroring | Nær-sanntid |
| Azure Databricks | GA | Metadata mirroring | Nær-sanntid |
| Oracle | Preview | Database mirroring | Nær-sanntid |
| SAP | Preview | Database mirroring | Nær-sanntid |
| Google BigQuery | Preview | Database mirroring | Nær-sanntid |

**Confidence marker:** [HIGH] — Offisiell dokumentasjon oppdatert januar 2026, bekreftet med `microsoft_docs_search`.

### 2. Metadata Mirroring

Metadata mirroring replikerer **kun metadata** (katalog, schema, tabeller) uten å fysisk flytte data. Data aksesseres via **OneLake shortcuts** fra kildesystemet.

**Eksempel:** Azure Databricks Unity Catalog
- Fabric speiler kataloghierarkiet fra Databricks
- Underliggende data forblir i Databricks
- Tilgang via shortcuts sikrer sanntidssynkronisering uten datakopiering

**Fordeler:**
- Minimerer lagringskostnader
- Eliminerer dataduplisering
- Sanntidstilgang til kildedata
- Ideell for kilder med stor datamengde eller høy endringsfrekvens

**Confidence marker:** [HIGH] — Azure Databricks-integrasjon dokumentert i offisielle Microsoft Learn-ressurser.

### 3. Open Mirroring

Open mirroring lar **egenutviklede applikasjoner eller tredjepartsløsninger** skrive endringer direkte til en mirrored database i Fabric. Basert på **åpen Delta Lake-standard**.

**Bruksområder:**
- Custom CDC-implementasjoner
- Tredjeparts datareplikasjonsverktøy
- Legacy-systemer uten nativ Fabric-støtte
- Event-drevet dataintegrasjon

**Prosess:**
1. Opprett en open mirrored database via Fabric Portal eller REST API
2. Hent landing zone URL i OneLake
3. Skriv change data til landing zone i spesifisert format (Delta Lake CDC)
4. Fabric replicator engine håndterer automatisk merge (INSERT, UPDATE, DELETE)

**Confidence marker:** [MEDIUM] — Open mirroring er GA, men økosystemet av tredjeparts-integrasjoner er fortsatt voksende (per februar 2026).

---

## Arkitekturmønstre

### Mønster 1: Operasjonell-til-Analytisk (HTAP)

**Scenario:** Organisasjonen har en Azure Cosmos DB for transaksjonell OLTP og ønsker sanntids BI/AI uten å påvirke produksjonsytelse.

**Løsning:**
```
Azure Cosmos DB (OLTP)
    │
    └─► Fabric Mirroring (ingen RU-kostnad)
            │
            ├─► OneLake (Delta Lake)
            │       │
            │       ├─► Power BI Direct Lake
            │       ├─► Eventstream (real-time alerting)
            │       ├─► Notebook (data science)
            │       └─► SQL Analytics Endpoint
            │
            └─► Near real-time (15 sek latens)
```

**Fordeler:**
- Null RU consumption for analytiske queries
- Near real-time insights (ikke batch-basert)
- Full HTAP-isolasjon (transaksjon/analytikk)
- Åpen Delta Lake for multi-tool tilgang

**Confidence marker:** [HIGH] — Azure Cosmos DB mirroring er eksplisitt designet for HTAP-scenarier.

### Mønster 2: Multi-Source Konsolidering (Data Mesh)

**Scenario:** Organisasjonen har data spredt på Azure SQL, PostgreSQL, Snowflake, og Cosmos DB. Ønsker én felles analytisk platform.

**Løsning:**
```
Azure SQL Database ────┐
PostgreSQL ────────────┤
Snowflake ─────────────┼─► Fabric Mirroring ─► OneLake (unified lakehouse)
Cosmos DB ─────────────┤                             │
Oracle (on-prem) ──────┘                             ├─► Cross-database queries (T-SQL)
                                                       ├─► Power BI semantic models
                                                       └─► Machine learning (MLflow, Spark)
```

**Fordeler:**
- Single source of truth for analytikk
- Cross-database queries via T-SQL (3-part naming)
- Felles governance og security (RLS, OLS, Purview)
- Ingen ETL-vedlikehold

**Eksempel T-SQL cross-database query:**
```sql
SELECT
    sql.CustomerName,
    cosmos.OrderTotal,
    pg.ProductName
FROM
    AzureSQLMirror.dbo.Customers AS sql
INNER JOIN
    CosmosMirror.dbo.Orders AS cosmos ON sql.CustomerID = cosmos.CustomerID
INNER JOIN
    PostgreSQLMirror.public.Products AS pg ON cosmos.ProductID = pg.ProductID
WHERE
    cosmos.OrderDate >= '2026-01-01';
```

**Confidence marker:** [HIGH] — Cross-database queries er dokumentert i offisiell Fabric-dokumentasjon.

### Mønster 3: Medallion Architecture med Mirroring

**Scenario:** Organisasjonen ønsker å implementere Bronze-Silver-Gold lakehouse, men vil unngå komplekse ingestion-pipelines.

**Løsning:**
```
Operational Sources (SQL, Cosmos, PostgreSQL)
    │
    └─► Fabric Mirroring ─► Bronze Layer (OneLake, raw Delta Lake)
                                │
                                └─► Materialized Lake Views ─► Silver Layer (cleansed, joined)
                                                                    │
                                                                    └─► Gold Layer (aggregated, BI-ready)
```

**Implementasjon med Materialized Lake Views:**
```sql
-- Bronze: Mirrored raw data (automatically managed)

-- Silver: Cleansed and joined
CREATE MATERIALIZED VIEW SilverCustomers AS
SELECT
    CustomerID,
    UPPER(TRIM(CustomerName)) AS CustomerName,
    CAST(RegistrationDate AS DATE) AS RegistrationDate
FROM Bronze.RawCustomers
WHERE CustomerID IS NOT NULL;

-- Gold: Aggregated for BI
CREATE MATERIALIZED VIEW GoldCustomerSummary AS
SELECT
    c.CustomerName,
    COUNT(o.OrderID) AS TotalOrders,
    SUM(o.OrderTotal) AS TotalRevenue
FROM SilverCustomers c
LEFT JOIN Bronze.RawOrders o ON c.CustomerID = o.CustomerID
GROUP BY c.CustomerName;
```

**Fordeler:**
- Deklarative pipelines (SQL, ikke kompleks orchestration)
- Automatisk dependency management (Fabric håndterer refresh-rekkefølge)
- Built-in data quality constraints
- Optimal refresh (incremental/full/none basert på analyse)

**Confidence marker:** [HIGH] — Materialized Lake Views er dokumentert som anbefalt tilnærming for medallion architecture i Fabric.

### Mønster 4: Legacy System Integration (Open Mirroring)

**Scenario:** Organisasjonen har et legacy ERP-system (ikke-støttet kilde) og ønsker å integrere data i Fabric.

**Løsning:**
```
Legacy ERP System
    │
    └─► Custom CDC Application (Python/Node.js)
            │
            └─► Open Mirroring Landing Zone (OneLake)
                    │
                    └─► Fabric Replicator Engine ─► Delta Lake tables
                                                        │
                                                        └─► Analytics (Power BI, Spark, SQL)
```

**Eksempel Python CDC writer:**
```python
from azure.storage.filedatalake import DataLakeServiceClient
import json
import pandas as pd

# Get landing zone URL from Fabric (after creating open mirrored database)
landing_zone_url = "https://onelake.dfs.fabric.microsoft.com/<workspace>/<item>/LandingZone"

# Authenticate with bearer token (Entra ID)
credential = DefaultAzureCredential()
service_client = DataLakeServiceClient(account_url=landing_zone_url, credential=credential)

# Write CDC data in required format (Delta Lake CDC schema)
cdc_data = {
    "op": "INSERT",  # INSERT, UPDATE, DELETE
    "ts_ms": 1709280000000,
    "before": None,
    "after": {
        "CustomerID": 12345,
        "CustomerName": "Acme Corp",
        "Country": "Norway"
    }
}

file_client = service_client.get_file_client(file_system="LandingZone", file_path="customers/batch_001.parquet")
file_client.upload_data(cdc_data, overwrite=True)
```

**Confidence marker:** [MEDIUM] — Open mirroring-spesifikasjonen er offentlig tilgjengelig, men kodeeksemplene over er forenklet (faktisk format er mer komplekst).

---

## Beslutningsveiledning

### Når bruke Mirroring vs. tradisjonell ETL?

| Faktor | Bruk Mirroring | Bruk ETL (Pipelines/Dataflows) |
|--------|----------------|--------------------------------|
| Datakilde | Støttet kilde (SQL, Cosmos, Snowflake, etc.) | Ustrukturert data (loggfiler, JSON, XML) |
| Latens-krav | Near real-time (< 1 minutt) | Batch (timesvis/daglig oppdatering) |
| Kompleksitet | Enkel 1:1 replikering | Kompleks transformasjonslogikk (aggregering, pivots) |
| Vedlikehold | Minimal (SaaS-managed) | Manuell pipeline-vedlikehold |
| Datavolumet | Stort (TB/PB) | Lite til medium (GB-nivå) |
| Kildepåvirkning | Minimal/ingen | Avhengig av query load |

**Anbefaling:**
Start med Mirroring for operasjonelle databaser, bruk ETL for edge cases (unstructured, komplekse transformations).

### Mirroring Type Decision Tree

```
Har du en støttet kilde (SQL, Cosmos, Snowflake)?
│
├─► JA → Er kilden Azure Databricks Unity Catalog?
│        │
│        ├─► JA → Bruk Metadata Mirroring (shortcuts)
│        │
│        └─► NEI → Bruk Database Mirroring
│
└─► NEI → Finnes det en tredjeparts connector?
         │
         ├─► JA → Bruk Open Mirroring + partner solution
         │
         └─► NEI → Utvikle custom CDC → Open Mirroring
```

**Confidence marker:** [HIGH] — Basert på offisiell Fabric-dokumentasjon for beslutningsdiagrammer.

---

## Integrasjon med Microsoft-stakken

### 1. Azure AI Foundry

**Scenario:** RAG-basert chatbot som trenger sanntidstilgang til produktkatalog i Azure SQL.

```
Azure SQL Database (product catalog)
    │
    └─► Fabric Mirroring ─► OneLake Delta Lake
                                │
                                └─► Azure AI Search (indexing)
                                        │
                                        └─► Azure AI Foundry (RAG)
                                                │
                                                └─► Chatbot (GPT-4o)
```

**Fordeler:**
- Ingen manuell synkronisering av search index
- Incremental updates (kun endrede produkter re-indexes)
- Åpent Delta Lake format kan brukes av andre AI-verktøy

### 2. Power BI Direct Lake

Mirrored databases i Fabric er **automatisk tilgjengelig i Direct Lake mode** for Power BI:

```
Mirrored Database (OneLake Delta Lake)
    │
    └─► Power BI Direct Lake Mode (ingen import, ingen DirectQuery overhead)
            │
            ├─► Semantic model (auto-generated)
            └─► Real-time reports (< 1 min latens)
```

**Fallback:** Hvis en query ikke støttes av Direct Lake, faller systemet automatisk tilbake til DirectQuery.

**Confidence marker:** [HIGH] — Direct Lake for mirrored databases er GA-funksjonalitet.

### 3. Real-Time Intelligence (Eventstream)

Kombiner Mirroring med Eventstream for **hybrid batch + streaming**:

```
Azure SQL Database (orders)
    │
    ├─► Fabric Mirroring ─► OneLake (batch, historical orders)
    │
    └─► Eventstream (CDC connector) ─► KQL Database (real-time orders, last 24h)
                                            │
                                            └─► Fabric Activator (alerts)
```

**Når bruke denne kombinasjonen:**
- Du trenger historisk analyse (batch) OG real-time alerting (streaming)
- Eksempel: Fraud detection (historisk modell, real-time scoring)

---

## Offentlig sektor (Norge)

### Compliance og Datahåndtering

**GDPR Article 17 (Right to Erasure):**
Mirroring støtter **soft delete** og **hard delete**:
- Soft delete: Rad markeres som slettet i Delta Lake (_change_type = 'delete')
- Hard delete: VACUUM-kommando fjerner gamle versjoner

**Eksempel:**
```sql
-- Check retention policy (default 1 day for new mirrors, 7 days for legacy)
-- Adjust in Fabric Portal: Mirrored Database → Settings → Maintenance → Retention

-- Manual vacuum (remove deleted rows older than 7 days)
VACUUM table_name RETAIN 168 HOURS;
```

**NSM Grunnprinsipper:**
- **Tilgangskontroll:** Row-level security (RLS) og Object-level security (OLS) støttes i SQL Analytics Endpoint
- **Logging:** Fabric Audit Logs sporer all datahåndtering (inkl. queries og deletes)
- **Kryptering:** Data-at-rest (OneLake) og data-in-transit (TLS 1.2+)

**Confidence marker:** [HIGH] — Security features dokumentert i offisiell Fabric-dokumentasjon.

### Kostnadsfordeling (Offentlig Sektor)

Mirroring har **særegne kostnadsfortrinn** for offentlige virksomheter:

| Kostnadselement | Tradisjonell ETL | Mirroring |
|------------------|------------------|-----------|
| Compute (replication) | Betalt (pipeline runs) | **GRATIS** (inkludert i Fabric capacity) |
| Storage (replicated data) | Standard OneLake-pris | **1 TB gratis per CU** (F64 = 64 TB gratis) |
| Pipeline-vedlikehold | DevOps-timekostnad | Minimal (SaaS-managed) |

**Eksempel:** F64 capacity (64 CU)
- Gratis mirroring-lagring: 64 TB
- Hvis du replikerer 50 TB data: Ingen ekstra lagringskostnad
- Hvis du replikerer 80 TB: Betaler kun for 16 TB (over grensen)

**Confidence marker:** [HIGH] — Prising bekreftet i Azure Pricing Calculator og Microsoft Fabric-dokumentasjon.

---

## Kostnad og Lisensiering

### Fabric Capacity-krav

| Scenario | Minimum Capacity | Anbefalt Capacity |
|----------|------------------|-------------------|
| POC (< 10 GB, 1 database) | F2 (2 CU) | F8 (8 CU) |
| Produksjon (< 100 GB, 5 databases) | F16 (16 CU) | F32 (32 CU) |
| Enterprise (> 1 TB, 20+ databases) | F64 (64 CU) | F128+ (128+ CU) |

**Trial:** Fabric Trial inkluderer gratis mirroring (60 dager, begrenset lagring).

### Kostnadselementer

1. **Replication compute:** GRATIS (inkludert i capacity)
2. **Storage:**
   - Første 1 TB per CU: GRATIS
   - Over grensen: Standard OneLake-pris (~$0.023/GB/måned, Norge-region)
3. **Query compute:**
   - SQL queries: Standard Fabric compute (CU consumption)
   - Power BI Direct Lake: Standard Power BI-prising
   - Spark queries: Standard Spark compute (CU consumption)

**Viktig:** Capacity må kjøre kun for **initial setup** av Mirroring. Etter oppsett kan du pause capacity, men da konsumeres lagring (ikke lenger gratis).

**Confidence marker:** [HIGH] — Prising bekreftet i offisiell Microsoft Fabric Pricing-dokumentasjon (januar 2026).

### Kostnadsoptimalisering

**Tips:**
1. **Selektiv replikering:** Speilvend kun tabeller du trenger (ikke hele databasen)
2. **Retention tuning:** Senk retention fra 7 dager til 1 dag (reduserer lagring)
3. **Cross-database queries:** Unngå datakopiering mellom mirrors (bruk T-SQL joins)
4. **Direct Lake:** Bruk Direct Lake i Power BI (ikke import mode) for å unngå duplikatlagring

---

## For arkitekten (Cosmo)

### Key Decision Points

1. **Kildetype:**
   - Operasjonell database (OLTP) → Database Mirroring
   - Data lakehouse (Databricks) → Metadata Mirroring
   - Legacy/custom → Open Mirroring

2. **Latenskrav:**
   - < 1 minutt → Mirroring (near real-time)
   - Timesvis/daglig → Vurder ETL (billigere for lave frekvenser)

3. **Transformasjonskompleksitet:**
   - 1:1 replikering → Mirroring
   - Komplekse joins/pivots → Mirroring + Materialized Lake Views eller ETL

4. **Governance:**
   - Trenger RLS/OLS? → Mirroring + SQL Analytics Endpoint (støtter RLS/OLS)
   - Trenger audit log? → Fabric Audit Logs (integrert)

### Performance Tuning (PostgreSQL eksempel)

Hvis du speilvenner Azure Database for PostgreSQL:

```sql
-- Check replication lag
SELECT * FROM azure_cdc.tracked_publications;

-- Check which batches are uploaded
SELECT * FROM azure_cdc.tracked_batches;

-- Tune batch frequency (reduce latency)
ALTER SERVER PARAMETER azure_cdc.change_batch_export_timeout = 15; -- default 30 sekunder

-- Increase parallel snapshot workers (faster initial load)
ALTER SERVER PARAMETER azure_cdc.max_snapshot_workers = 5; -- default 3
```

**Confidence marker:** [HIGH] — PostgreSQL mirroring server parameters dokumentert i offisiell Azure-dokumentasjon.

### When NOT to Use Mirroring

1. **Kompleks business logic:** Hvis transformasjonen krever komplekse Python/C#-scripts, bruk Fabric Pipelines eller Dataflows.
2. **Unstructured data:** Mirroring er for strukturerte databaser. Bruk Eventstream for IoT/logs.
3. **On-prem kilder uten nettverkstilgang:** Mirroring krever nettverkstilgang til OneLake (bruk On-Premises Data Gateway eller VPN).

---

## Tekniske Detaljer

### Change Data Capture (CDC) Mekanismer

| Kilde | CDC-mekanisme | Latens |
|-------|---------------|--------|
| SQL Server | Change Feed (transaction log scanning) | 15+ sekunder |
| PostgreSQL | Logical replication (azure_cdc extension) | 15+ sekunder |
| Azure Cosmos DB | Change Feed API (ingen RU consumption) | 15+ sekunder |
| Snowflake | Streams (Snowflake Streams API) | 30+ sekunder |

**Hvordan virker det (PostgreSQL eksempel):**

```
1. Initial snapshot:
   PostgreSQL → Parquet files → OneLake Landing Zone → Fabric Replicator → Delta tables

2. Ongoing changes:
   PostgreSQL WAL (Write-Ahead Log) → azure_cdc extension → Parquet batches → Landing Zone → Delta merge
```

**Confidence marker:** [HIGH] — Arkitektur-diagram hentet fra offisiell Azure-dokumentasjon.

### Delta Lake Format

All mirrored data lagres som **Delta Lake** (ikke bare Parquet):

**Fordeler:**
- ACID-transaksjoner (no data corruption)
- Time travel (query historical versions)
- Schema evolution (add/remove columns uten å ødelegge historikk)
- Z-Ordering og V-Order optimalisering (raskere queries)

**Eksempel time travel:**
```sql
-- Query data as it was 7 days ago
SELECT * FROM MirroredDatabase.dbo.Orders
VERSION AS OF (CURRENT_TIMESTAMP - INTERVAL 7 DAY);
```

---

## Praktisk Eksempel: End-to-End Setup

### Scenario: Azure SQL til Power BI (5 minutters setup)

1. **Opprett Mirrored Database i Fabric:**
   - Fabric Portal → Create → Mirrored Database → Azure SQL Database
   - Angi connection string og credentials (Entra ID eller SQL auth)
   - Velg tabeller å speilvende (eller hele databasen)

2. **Vent på initial snapshot** (5-30 minutter avhengig av datavolumet)

3. **Koble Power BI til SQL Analytics Endpoint:**
   - Power BI Desktop → Get Data → SQL Server
   - Server: `<workspace>.datawarehouse.fabric.microsoft.com`
   - Database: `<mirrored-database-name>`
   - Velg Direct Lake mode (anbefalt)

4. **Bygg rapport:**
   - Dra tabeller inn i rapport
   - Data er nå live-synkronisert (< 1 minutts latens)

**Total tid:** < 1 time (inkl. initial snapshot)

**Confidence marker:** [HIGH] — Prosedyre bekreftet i offisiell Microsoft Learn-dokumentasjon.

---

## Vanlige Feil og Løsninger

### Problem 1: Mirroring feiler med "Internal error"

**Årsak:** Manglende permissions på kilde-databasen.

**Løsning (PostgreSQL):**
```sql
-- Grant required permissions
GRANT azure_cdc_admin TO fabric_user;
GRANT CREATE ON DATABASE mydb TO fabric_user;
ALTER TABLE orders OWNER TO fabric_user; -- fabric_user must own tables
```

### Problem 2: Høy storage-kostnad

**Årsak:** Retention er satt for høyt (default 7 dager for legacy mirrors).

**Løsning:**
- Fabric Portal → Mirrored Database → Settings → Maintenance → Retention → 1 day
- Eller via REST API: `PATCH /v1/mirroring/databases/{id}` med `retentionInDays: 1`

### Problem 3: Query fallback til DirectQuery (langsom)

**Årsak:** Power BI-query bruker en funksjon som ikke støttes av Direct Lake.

**Løsning:**
- Sjekk Power BI Performance Analyzer for fallback-årsak
- Omskriv query til å unngå ikke-støttede funksjoner (eks: CONCATENATE → "&")
- Eller aksepter DirectQuery for komplekse queries (fortsatt raskere enn import mode for store datasets)

**Confidence marker:** [MEDIUM] — Troubleshooting-tips basert på community-dokumentasjon og Microsoft Learn.

---

## Fremtidige Utvidelser (Roadmap)

**Følgende kilder er ikke støttet i februar 2026, men er på roadmap:**

- **MongoDB:** Planlagt Q2 2026 (per Microsoft Ignite 2025-announcements)
- **SAP HANA:** Preview forventet Q1 2026
- **IBM Db2:** Ingen offentlig timeline
- **MySQL:** CDC-basert mirroring (current: kun Azure Database for MySQL via Open Mirroring)

**Confidence marker:** [LOW] — Roadmap-informasjon er basert på konferanse-announcements, ikke offisiell produktdokumentasjon.

---

## Kilder og Verifisering

**Primærkilder (MCP: microsoft-learn):**
1. [What is Mirroring in Fabric?](https://learn.microsoft.com/en-us/fabric/mirroring/overview) — Sist oppdatert januar 2026
2. [Azure Database for PostgreSQL mirroring in Fabric](https://learn.microsoft.com/en-us/azure/postgresql/integration/concepts-fabric-mirroring) — GA-status bekreftet
3. [Medallion lakehouse architecture for Fabric with OneLake](https://learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture) — Materialized Lake Views
4. [Microsoft Fabric Pricing](https://azure.microsoft.com/pricing/details/microsoft-fabric/) — Prising bekreftet januar 2026

**Kodeeksempler (MCP: microsoft_code_sample_search):**
- SQL Server Resource Governor for Fabric mirroring
- PostgreSQL CDC monitoring functions (`azure_cdc.list_tracked_publications()`)
- Delta Lake time travel queries

**Søk brukt:**
- `microsoft_docs_search`: "Fabric mirroring", "zero ETL Fabric", "database mirroring OneLake"
- `microsoft_docs_fetch`: Mirroring overview, PostgreSQL architecture
- `microsoft_code_sample_search`: "Fabric mirroring OneLake Delta Lake"

**Sist verifisert:** 2026-02-11

---

## Oppsummering for Cosmo

**Zero-ETL med Fabric Mirroring er riktig valg når:**
- Kilden er en støttet database (SQL, Cosmos, Snowflake, PostgreSQL)
- Du trenger near real-time data (< 1 minutt latens)
- Du vil eliminere ETL-vedlikehold
- Du vil ha en åpen, multi-tool lakehouse (Delta Lake)

**Ikke bruk Mirroring hvis:**
- Data er ustrukturert (loggfiler, JSON, XML) → Bruk Eventstream eller Pipelines
- Transformasjonslogikken er svært kompleks → Bruk Dataflows Gen2 eller Pipelines
- Kilden er on-prem uten nettverkstilgang → Bruk On-Premises Data Gateway + Pipelines

**Kostnadsoptimalisering:**
- Start med F16/F32 for produksjon
- Bruk 1 dag retention (ikke 7 dager)
- Speilvend kun nødvendige tabeller
- Bruk Direct Lake i Power BI (ikke import mode)

**Next steps for kunden:**
1. Identifiser kritiske operasjonelle databaser
2. Vurder latens-krav per datakilde
3. Beregn lagringsbehov (free tier: 1 TB per CU)
4. Kjør POC med Fabric Trial (60 dager gratis)