Microsoft Fabric nach einem Jahr im Enterprise: was funktioniert, was nicht

Als Microsoft Fabric im November 2023 launchte, versprach es eine vereinheitlichte Datenplattform — OneLake als Single-Storage, Lakehouse + Data Warehouse + Power BI + Data Factory in einem Produkt. Für Kunden, die eine Datenplattform überlegen, war das ein ernster Pitch: statt Stack aus Databricks + Snowflake + Fivetran + Power BI ein einziges Ökosystem.

Für Magistra (Netz von 200+ Apotheken, E-Shop, externe Systeme) läuft Fabric seit 8 Monaten. Hier ehrliche Review — was passt und was nicht.

Was gut funktioniert

OneLake und Data-Mesh ab Tag eins

OneLake ist das stärkste Fabric-Feature. Kein doppelter Storage für Lakehouse vs. Warehouse vs. Power BI — Daten liegen einmal, an einem Ort (Delta-Lake-Format), Zugriff via Shortcuts. Für Enterprises mit mehreren Teams entfernt das eine ganze Pain-Point-Kategorie.

Beispiel: Magistra hat Apotheken-Team, E-Shop-Team, Finance. Jedes braucht eigene Berechnungen über denselben Source-Daten. In Databricks hätten Sie 3 Workspaces, 3 Storage-Accounts und müssten synchronisieren. In Fabric haben Sie einen OneLake, drei Workspaces, Shortcuts dazwischen. Keine Daten-Duplizierung.

Power-BI-Integration ohne Reibung

Landen Daten in OneLake im Delta-Format, kann Power BI DirectLake-Mode — es liest Delta-Dateien direkt, ohne ETL ins Tabular-Model. Refresh ist sofort, weil es nichts zu refreshen gibt. Für Enterprise-Dashboards über Milliarden Zeilen senkt das Infrastruktur um 40-50 % gegenüber klassischem Import/Refresh.

Data Factory (Fabric-Variante) ist vernünftig

Fabric hat seine eigene Data-Factory-Variante (getrennt von Azure Data Factory — ja, verwirrend benannt). Ein Orchestration-Engine mit Drag-and-Drop plus SQL/PySpark- Notebooks. Deckt 80 % der ETL-Szenarien ab. Für komplexe Transformationen Spark-Notebooks.

Lizenzmodell einfach (in der Theorie)

Sie kaufen Capacity (F2, F4, F8...), nicht per-User, per-Pipeline, per-Warehouse. Capacity teilt sich über Workloads. Für eine Organisation mit klarem Budget viel einfacher als Databricks-DBUs + Snowflake-Credits + Power BI per-User.

Was NICHT gut funktioniert

Capacity ist underspecified — und teuer

„Capacity teilt sich über Workloads“ klingt super, bis Sie voraussagen müssen, welches F-Tier zu kaufen ist. F4 (~1 500 €/Monat) ist Minimum für irgendetwas Sinnvolles. F8 (~3 000 €/Monat) ist realistisches Minimum für Produktions-DWH mit täglichen Refreshes. F16+ für Enterprise-Scale.

Problem: Capacity-Throttling passiert unvorhersehbar. Eine DAX-Query in Power BI verbraucht dieselben Capacity-Units wie ein Spark-Job — ein „Kollege aus Finance“ mit einer langsamen Query kann die ganze Plattform drosseln. CU-Monitoring ist kritisch, aber die Dashboards sind primitiv.

CI/CD — immer noch ein Problem

Fabric-Workspaces haben keine First-Class-Git-Integration wie Databricks-Repos. Es gibt Fabric-Deployment-Pipelines (Dev → Test → Prod), aber:

• Notebooks sind Export/Import, nicht Git-first
• Parameter-Rewriting zwischen Environments ist manuell
• PR-Review von Power-BI-Reports? Geht nicht — Review muss im Live-Workspace passieren

In Databricks-Repos haben Sie einen vollen Git-Workflow. Fabric hat das 2026 noch nicht. Wenn Ihr Team an Software-Engineering-Praktiken gewohnt ist (Code-Review, Branch-Protection, PR-Checks), wird Sie das quälen.

Product-Maturity — noch in Bewegung

Microsoft pusht jeden Monat neue Features. Klingt gut, heißt aber auch:

• 6 Monate alte Dokumentation kann auf UI verweisen, die nicht mehr existiert
• Best-Practices aus Blogposts sind überholt, weil das Feature sich geändert hat
• GA-Status (General Availability) verzögert sich oft. Etwas, das Sie nutzen, ist noch Preview — kein SLA, potenzielle Breaking Changes

Databricks und Snowflake sind reifere Produkte. Fabric ist in der Teenagephase — viel Wachstum, nicht alles sitzt.

SQL-Endpoint-Performance unter Erwartung

Fabric Warehouse (SQL-Endpoint) liegt bei Latenz und Durchsatz noch hinter Databricks SQL und Snowflake. Für Ad-hoc-Analytical- Queries („zeige Umsatz nach Kategorie letzten Monat“) ok. Für High-Concurrency-BI mit Hunderten parallelen Nutzern… noch zu wenig Benchmarks.

Wo Fabric Databricks/Snowflake schlägt

• Microsoft-Shop-Kunde. Entra ID, Azure, Power BI, M365 schon da — Fabric passt ins Ökosystem. Procurement einfach.
• Team ohne tiefe Data-Engineering-Skills. Fabric ist zugänglich für BI-Analysten. Databricks will Data-Engineer-Orientierung.
• Budget-conscious Startups / Mid-Market. F4 ab ~1 500 €/Monat günstiger als produktives Databricks + Snowflake.
• Power BI first-class. Investitionen in Power-BI-Reports bereits vorhanden, Fabric ist Kontinuität, kein Rebuild.

Wo vermeiden

• Team braucht vollen Git-first-Workflow. Databricks-Repos besser.
• Extreme Query-Performance-Anforderungen. Snowflake bleibt Benchmark.
• Multi-Cloud. Fabric ist Azure-only. Wenn AWS/GCP auch, nein.
• Heavy Real-Time-Streaming. Fabric Real-Time-Analytics existiert, aber Databricks Structured Streaming reifer.

Was Magistra uns gelehrt hat

Nach 8 Betriebsmonaten:

• F8-Capacity reicht für 200+ Apotheken-DWH mit ~4 TB Daten und täglichen Refreshes
• Throttling-Issues 2× in 8 Monaten, beide durch Umplanung täglicher Runs in Off-Peak-Hours gelöst
• Data-Factory-Pipelines stabil, aber CI/CD ist weiter Reibung (aktuell Deploy via PowerShell-Skripte)
• Power-BI-DirectLake bedeutet Endnutzer sehen frische Daten binnen 15 Minuten nach Refresh — bei Databricks + Power-BI- Import-Mode wären es 1-2 Stunden
• Gesamtkosten ~42 % unter der Alternative Databricks + Snowflake + Fivetran, die wir ursprünglich quotiert hatten

Empfehlung

Wenn Sie im Microsoft-Stack sind, eine Datenplattform starten und Ihr Team mehr BI- als Data-Engineering-orientiert ist — Fabric ist heute eine legitime Wahl. Früher (2024) hätte ich gesagt, warten. 2026 gibt es genug Case-Studies und Product-Maturity ist ok.

Bei anderem Stack, Top-Tier-Performance-Bedarf oder vollem Git-Workflow — bleiben Sie bei Databricks + Snowflake. Keine langsamere Entscheidung, ein anderer Trade-off.