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.
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.
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.
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.
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.
Zahlen statt Prinzipien. Drei realistische Profile (gerundet, ohne Anspruch auf tagesaktuelle Listenpreise — prüfe die immer im Microsoft-Preisrechner für deine Region).
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.
Die SKU ist selten der größte Posten. Was wirklich kostet:
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.
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.
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.
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.