ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-engineering/references/data-engineering/zero-etl-fabric-patterns.md

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:

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:

-- 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:

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:

-- 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:

-- 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:

-- 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):

-- 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? — Sist oppdatert januar 2026
2. Azure Database for PostgreSQL mirroring in Fabric — GA-status bekreftet
3. Medallion lakehouse architecture for Fabric with OneLake — Materialized Lake Views
4. Microsoft Fabric Pricing — 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)