Data Analytics & AI

Microsoft Fabric: Kosten und Lizenzen realistisch einordnen

Microsoft Fabric: Kosten und Lizenzen ehrlich erklärt

Die Frage vor jeder Fabric-Einführung ist nicht „Was kostet eine F-SKU?" — das steht in jeder Preisliste. Sie lautet: Was zahlen wir am Jahresende realistisch, mit unserer Last, unseren Nutzern, unseren Spitzen? Genau darauf gibt die offizielle Preisseite keine ehrliche Antwort. Dieser Artikel schon.

Vorwarnung: Fabric-Kosten sind nicht kompliziert, aber unintuitiv. Wer das Abrechnungsmodell nicht versteht, bekommt eine böse Überraschung auf der Rechnung oder zahlt monatelang für brachliegende Kapazität. Beides ist vermeidbar.

1. Das Kapazitätsmodell — der eine Begriff, den du verstehen musst

Fabric rechnet nicht pro Feature ab, sondern über eine geteilte Kapazität, gemessen in Capacity Units (CU). Du buchst eine SKU — F2, F4, F8, F16, F64 und so weiter, wobei die Zahl ungefähr für die Rechenleistung steht — und alles, was du in Fabric tust (Pipelines, Spark-Jobs, SQL-Abfragen, Power-BI-Renderings), zieht aus diesem gemeinsamen Topf.

Der entscheidende Mechanismus heißt Smoothing: Fabric verteilt kurze Lastspitzen rechnerisch über einen längeren Zeitraum. Ein 30-Sekunden-Spark-Job, der kurz die Kapazität überschreitet, killt dich also nicht sofort. Erst wenn du dauerhaft über deiner gebuchten Kapazität liegst, kommt es zu Throttling: Abfragen werden verzögert oder abgewiesen. Diese Mechanik erklärt, warum „die SKU ist zu klein" sich oft erst Wochen später als langsame Reports zeigt.

Smoothing: warum kurze Spitzen nicht sofort wehtun CU Zeit → echte Spitzen Konsequenz: Eine zu kleine SKU fällt nicht sofort auf — sie zeigt sich Wochen später als zähe Reports. Monitoring ist Pflicht. Visualisierung: Medienstürmer gebuchte Kapazität geglättete Last bleibt unter der Linie → kein Throttling

2. Reserved vs. Pay-as-you-go — der größte Spar-Hebel

Es gibt zwei Bezahlmodelle, und der Unterschied ist erheblich.

Pay-as-you-go: Du zahlst pro Stunde Laufzeit und kannst die Kapazität pausieren — pausiert fallen keine Compute-Kosten an. Ideal, wenn deine Last zeitgebunden ist (nur Bürozeiten, nicht nachts/Wochenende).

Reserved: Du verpflichtest dich auf ein Jahr und zahlst spürbar weniger pro Stunde — typischerweise rund 40 Prozent unter Pay-as-you-go. Dafür läuft die Kapazität durch und kann nicht zum Sparen pausiert werden.

Die ehrliche Faustregel: Starte mit Pay-as-you-go, bis du dein echtes Lastprofil kennst (ein bis zwei Monate Betrieb). Erst wenn du die Kapazität ohnehin fast durchgehend brauchst, lohnt Reserved. Wer von Tag 1 eine Jahresreservierung kauft, ohne das Lastprofil zu kennen, wettet — und verliert oft.

3. Power BI ist in Fabric mit drin — aber nur ab F64

Ein Detail, an dem viele Kalkulationen scheitern: Ab der Kapazität F64 sind Power-BI-Berichte für alle Betrachter ohne individuelle Pro-Lizenz nutzbar (der Mechanismus, der früher „Premium" hieß). Unter F64 brauchen Nutzer, die Berichte ansehen oder bearbeiten, weiterhin eine Power BI Pro Lizenz pro Kopf.

Das verschiebt die Rechnung dramatisch. Bei wenigen Konsumenten ist eine kleine SKU plus ein paar Pro-Lizenzen günstig. Bei 150 reinen Betrachtern kann der Sprung auf F64 (keine Einzellizenzen mehr nötig) unter dem Strich billiger sein als 150 Pro-Lizenzen — obwohl die SKU teurer aussieht. Diese Schwelle ist der wichtigste einzelne Hebel deiner Lizenzrechnung. Den Unterschied zwischen reinem Power BI und Fabric erklären wir im Vergleich Fabric vs. Power BI.


4. Eine ehrliche Beispielrechnung für den Mittelstand

Zahlen statt Prinzipien. Drei realistische Profile (gerundet, ohne Anspruch auf tagesaktuelle Listenpreise — prüfe die immer im Microsoft-Preisrechner für deine Region).

Drei Profile — wo der Hebel jeweils liegt Klein ~10 Report-Nutzer moderate Last Kleine F-SKU (F2–F8) + ~10 Pro-Lizenzen Pay-as-you-go, nachts pausieren Hebel: Pausieren Frage: braucht ihr Fabric? Mittel ~40 Report-Nutzer tägliche Pipelines F16–F32 + Pro-Lizenzen pro Kopf Lastprofil messen, dann ggf. Reserved Hebel: SKU-Größe Frage: F64-Schwelle nah? Groß 150+ Report-Nutzer viele nur lesend F64 — Pro-Lizenzen entfallen für Betrachter oft günstiger als 150 Einzellizenzen Hebel: F64-Schwelle Reserved fast immer sinnvoll Die teuerste Annahme: „Eine große SKU ist Verschwendung" Ab vielen reinen Betrachtern kann F64 günstiger sein als hunderte Pro-Lizenzen. Visualisierung: Medienstürmer

Die Beispiele zeigen das Muster: Im kleinen Profil ist der Hebel Pausieren (und die ehrliche Frage, ob ihr Fabric überhaupt braucht — siehe unten). Im mittleren Profil ist es die richtige SKU-Größe und das gemessene Lastprofil. Im großen Profil ist es die F64-Schwelle, ab der Einzellizenzen wegfallen. Es gibt keinen pauschalen Spar-Tipp — der Hebel hängt vom Profil ab.

5. Die versteckten Kosten, die niemand auf die Folie schreibt

Die SKU ist selten der größte Posten. Was wirklich kostet:

  • OneLake-Speicher. Wird separat zur Kapazität abgerechnet. Bei großen Datenmengen relevant — bei typischem Mittelstand meist klein, aber einplanen.
  • Datenausgang (Egress). Daten, die Fabric wieder verlassen (z. B. in andere Systeme), können Transferkosten verursachen.
  • Der laufende Betrieb. Der mit Abstand größte „versteckte" Posten ist Personalzeit: jemand muss die Kapazität überwachen, FinOps machen, Modelle pflegen. Eine Plattform ohne Betreiber ist kein Schnäppchen, sondern eine Investitionsruine. Das ist kein Lizenzthema, aber es gehört in jede ehrliche Kostenrechnung — wie eine saubere Einführung das berücksichtigt, steht in Microsoft Fabric einführen.

Auch die Architekturwahl beeinflusst die Kosten: Spark-lastige Lakehouse-Workloads verbrauchen Kapazität anders als schlanke SQL-Warehouse-Abfragen. Wer hier bewusst wählt, spart real — wir behandeln das in Lakehouse vs. Warehouse.

6. Wann sich Fabric-Kosten NICHT lohnen

Klartext: Wenn dein gesamtes Reporting aus einer Handvoll Power-BI-Datasets besteht, die einmal täglich aus einer SQL-Datenbank aktualisieren, und nur eine überschaubare Zahl Leute draufschaut, dann ist die kleinste sinnvolle Fabric-Kapazität trotzdem teurer als Power BI Pro plus eine ordentliche Azure SQL Datenbank. Du zahlst dann für eine Plattform, deren Mehrwert (Data Engineering, Echtzeit, Lakehouse) du gar nicht nutzt.

Fabric lohnt sich kostentechnisch ab dem Punkt, wo du mehrere Quellen integrierst, nennenswerte Datenmengen verarbeitest oder die F64-Schwelle dir Einzellizenzen erspart. Darunter ist „nur Power BI" fast immer die ehrlichere und günstigere Antwort — das rechnen wir im Vergleich Fabric vs. Power BI durch. Wer eine herstellerunabhängige Einschätzung dazu will, findet in Power-BI-Beratung für den Mittelstand den passenden Rahmen, und den großen Kontext liefern der Leitfaden Microsoft Power Platform und der Microsoft-Dataverse-Leitfaden.

Fazit

Fabric-Kosten sind beherrschbar, wenn du drei Dinge verstehst: Das Kapazitätsmodell mit Smoothing (eine zu kleine SKU fällt erst spät als zähe Reports auf), den Unterschied zwischen Pay-as-you-go und Reserved (starte flexibel, reserviere erst nach gemessenem Lastprofil) und die F64-Schwelle (ab vielen reinen Betrachtern kann die teurer aussehende SKU unter dem Strich billiger sein). Der größte versteckte Posten ist nicht die Lizenz, sondern der laufende Betrieb. Und die ehrlichste Erkenntnis: Unterhalb einer gewissen Komplexität ist „nur Power BI" schlicht günstiger. Rechne mit deinem echten Profil, nicht mit der Preisliste.

Was würde Fabric euch realistisch kosten?

Wir rechnen euer echtes Lastprofil durch — inklusive der ehrlichen Variante, dass Power BI ohne Fabric günstiger für euch ist. Eine Zahl, keine Verkaufsfolie.

Quellen