Lakehouse vs. Warehouse: Welche Architektur der Mittelstand wirklich braucht

Sobald du dich mit Microsoft Fabric beschäftigst, stößt du auf eine Entscheidung, die niemand gern trifft, weil sie technisch klingt: Lakehouse oder Warehouse? In Demos wird das gern weggewischt („nimm einfach beides"). In der Praxis ist es eine der wenigen Architekturentscheidungen, die du teuer korrigierst, wenn du sie falsch triffst. Dieser Artikel erklärt den Unterschied so, dass du danach eine begründete Wahl treffen kannst — ohne Data-Engineering-Studium.

1. Der Unterschied in einem Satz, den du dir merken kannst

Ein Warehouse ist eine SQL-Datenbank: strukturierte Tabellen, T-SQL, klare Schemata, optimiert dafür, dass Fachleute saubere relationale Daten abfragen. Ein Lakehouse ist ein Dateispeicher mit einer Tabellenschicht obendrauf: du landest erst Dateien (CSV, Parquet, JSON, auch Rohes und Halbstrukturiertes), verarbeitest sie mit Spark/Python und stellst dann Tabellen bereit.

Verkürzt: Warehouse = SQL-Welt. Lakehouse = Python/Spark-Welt. Beide liegen in Fabric auf demselben OneLake und im selben offenen Delta-Parquet-Format — der echte Unterschied ist nicht die Speichertechnik, sondern wer damit arbeitet und wie eure Daten ankommen.

2. Die ehrliche Entscheidungshilfe für den Mittelstand

Vergiss für einen Moment Performance-Benchmarks und Feature-Matrizen. Im Mittelstand entscheiden drei pragmatische Fragen.

Frage 1: Was kann dein Team? Hast du Leute, die SQL sicher schreiben — aber kein Python? Dann ist das Warehouse der Pfad des geringsten Widerstands. Habt ihr Data-Engineering-Kompetenz mit Python/Spark, oder einen Partner, der das mitbringt? Dann ist das Lakehouse offen. Diese Frage schlägt fast jede technische Überlegung, weil eine Architektur, die niemand bedienen kann, wertlos ist.

Frage 2: Wie kommen deine Daten an? Wenn deine Quellen sauber relational sind (ERP-Tabellen, eine CRM-Datenbank, strukturierte Exporte), passt das Warehouse natürlich. Wenn du es mit JSON aus APIs, Logdateien, IoT-Strömen, gemischten Dateiformaten oder rohen Dumps zu tun hast, spielt das Lakehouse seine Stärke aus — es nimmt erst alles auf und du strukturierst später.

Frage 3: Brauchst du Data Science / ML? Wenn ja (Prognosen, Klassifikation, Embeddings), führt am Lakehouse fast kein Weg vorbei, weil die Spark- und Notebook-Werkzeuge dort sitzen. Wenn dein Bedarf „korrekte Reports und Dashboards" ist — was im Mittelstand der Normalfall ist — reicht oft das Warehouse vollkommen.

Die häufigste richtige Antwort im Mittelstand lautet übrigens: Warehouse. Nicht weil es besser ist, sondern weil die meisten mittelständischen Datenlandschaften relational und SQL-Skills verbreiteter als Spark-Skills sind. Lass dich nicht zum Lakehouse drängen, weil es „moderner" klingt — Moderne, die niemand bedienen kann, ist teurer Stillstand.

3. Der „nimm einfach beides"-Mythos

In Fabric kannst du technisch tatsächlich beides parallel betreiben — Lakehouse für die rohe Aufnahme und Transformation, Warehouse als kuratierte Servierschicht für die Fachbereiche. Das ist ein etabliertes Muster (oft „Medallion-Architektur" genannt) und für größere Setups sinnvoll.

Für den Mittelstand ist „nimm beides" am Anfang fast immer der falsche Rat. Zwei Architekturen bedeuten doppelte Komplexität, doppelten Betriebsaufwand und doppelt so viele Stellen, an denen etwas schiefgehen kann. Starte mit einer. Du kannst die zweite später ergänzen, wenn ein konkreter Bedarf entsteht — die offene Delta-Parquet-Basis von OneLake macht das möglich, ohne alles neu zu bauen. Diese Disziplin ist Teil einer sauberen Einführung, die wir in Microsoft Fabric einführen Schritt für Schritt beschreiben.

4. Konkrete Szenarien aus dem Mittelstand

5. Was die Entscheidung NICHT ist

Drei Missverständnisse, die im Mittelstand regelmäßig zu falschen Wahlen führen.

„Lakehouse ist die Zukunft, Warehouse die Vergangenheit." Falsch. Beide sind in Fabric gleichberechtigte, aktiv weiterentwickelte Produkte. Das Warehouse ist nicht das alte Konzern-DWH von vor 15 Jahren — es ist eine moderne, SQL-native Engine auf demselben offenen Format. Die Wahl ist kein Zeitstrahl.

„Mit dem Lakehouse sind wir flexibler." Flexibilität, die niemand nutzen kann, ist kein Vorteil, sondern Risiko. Ein Lakehouse ohne Python/Spark-Kompetenz ist ein teures, leeres Versprechen. Flexibilität entsteht durch Können, nicht durch Produktwahl.

„Die Performance entscheidet." Für mittelständische Datenmengen (Millionen, nicht Milliarden Zeilen) sind beide schnell genug. Die Performance ist selten der Engpass — die Skills im Team und die Datenqualität sind es fast immer. Wer hier nach Benchmarks entscheidet, optimiert das Falsche.

Diese Modellierungsfrage hängt eng mit der Kostenfrage zusammen: Lakehouse-Workloads (Spark) und Warehouse-Workloads verbrauchen Fabric-Kapazität unterschiedlich. Wer die Architektur wählt, sollte die Kostenlogik kennen — die erklären wir in Microsoft Fabric: Kosten und Lizenzen. Und wer noch unsicher ist, ob die richtige Begleitung von außen sinnvoll ist, findet Orientierung in Power-BI-Beratung für den Mittelstand sowie im großen Rahmen im Leitfaden Microsoft Power Platform und im Microsoft-Dataverse-Leitfaden.

Fazit

Lakehouse oder Warehouse ist im Mittelstand keine Technikfrage, sondern eine Skill- und Datenfrage. Hast du SQL-Leute und relationale Quellen, ist das Warehouse fast immer die richtige, verzeihendere Wahl — und das ist der häufigste Fall. Brauchst du echtes Data Engineering, halbstrukturierte Daten oder ML und hast die Kompetenz dafür, ist das Lakehouse offen. „Nimm einfach beides" ist für den Start fast nie der richtige Rat — eine Architektur sauber schlägt zwei halb. Und manchmal ist die ehrliche Antwort: weder noch, Power BI plus eine SQL-Datenbank reicht. Entscheide nach Können und Datenrealität, nicht nach dem, was moderner klingt.

Lakehouse, Warehouse — oder doch keins von beiden?

Wir schauen uns eure Datenquellen und Team-Skills an und sagen dir, welche Architektur wirklich passt. Inklusive der ehrlichen Variante, dass du Fabric vielleicht gar nicht brauchst.

Gespräch vereinbaren Microsoft-Power-Platform-Leistungen ansehen