Um das Konzept zu verstehen, hilft ein Blick auf die beiden Vorgänger. Ein Data Warehouse ist ein hochstrukturiertes System für Analysedaten: Die Daten sind sauber modelliert, konsistent und für Auswertungen optimiert – dafür ist es vergleichsweise teuer und eignet sich schlecht für rohe, unstrukturierte Daten wie Dokumente, Bilder oder Sensor-Ströme. Ein Data Lake ist das Gegenteil: ein riesiger, günstiger Speicher, in den man Daten jeder Art in ihrem Rohzustand kippt – flexibel und billig, aber ohne die Struktur, Verlässlichkeit und Verwaltung, die belastbare Analysen brauchen. In der Praxis endeten viele Data Lakes als unübersichtlicher „Data Swamp“, ein Datensumpf, in dem niemand mehr weiß, was wo liegt und ob es stimmt.
Das Data Lakehouse setzt genau an dieser Kluft an. Die Kernidee lässt sich in einem Satz fassen: Man legt die verlässliche, geordnete Schicht eines Warehouse direkt über den günstigen Speicher eines Data Lake – statt beide getrennt zu betreiben. Möglich wird das durch eine technische Neuerung, die wir in Kapitel 03 genauer betrachten: offene Tabellenformate, die auf preiswertem Objektspeicher eine transaktionssichere, strukturierte und verwaltbare Ebene schaffen.
Drei Eigenschaften definieren das Lakehouse-Konzept:
Der Name „Lakehouse“ ist Programm: Er verschmilzt Lake und (Ware)house und benennt damit exakt den Anspruch. Historisch mussten Unternehmen sich entscheiden – oder, häufiger, beides parallel betreiben. Data Scientists arbeiteten im flexiblen Data Lake mit rohen Daten für ihre Modelle; Fachbereiche und Controlling zogen ihre Berichte aus dem sauberen, aber starren Data Warehouse. Dazwischen lief ein permanenter Datentransport: Daten wurden aus dem Lake ins Warehouse geladen, dort transformiert und für Analysen aufbereitet. Diese doppelte Haltung ist teuer, langsam und fehleranfällig, weil zwei Wahrheiten entstehen, die auseinanderlaufen können.
Das Lakehouse verspricht, diese Trennung aufzuheben. Die Daten bleiben an einem Ort, im günstigen Speicher, und erhalten dort die Struktur und Verlässlichkeit, die man bisher nur im Warehouse hatte. Für den Mittelstand ist das vor allem eine Frage der Beherrschbarkeit: eine Plattform statt zwei, ein Datenstand statt konkurrierender Kopien, ein Governance-Rahmen statt zweier. Ob dieses Versprechen im Einzelfall eingelöst wird, hängt stark von der Datenlage und der gewählten Technologie ab – aber die Richtung ist klar und hat sich als tragfähiger Architektur-Trend etabliert.
Das Lakehouse ist besonders für Organisationen relevant, deren Daten über reine Tabellen hinausgehen. Wer neben strukturierten Verkaufs- und Finanzdaten auch Sensordaten aus der Produktion, Bild- oder Dokumentendaten, Web-Logs oder Textdaten sammelt und analysieren möchte, stößt mit einem klassischen Warehouse schnell an Grenzen – dort passen diese Formate schlecht hinein. Ebenso relevant ist das Konzept für Unternehmen mit ernsthaften KI-Ambitionen, weil maschinelles Lernen genau von dieser Datenvielfalt lebt und idealerweise auf derselben verwalteten Grundlage arbeitet wie das Reporting.
Gleichzeitig ist eine ehrliche Einordnung wichtig: Nicht jedes Unternehmen braucht ein Lakehouse. Für einen Mittelständler, dessen Analysebedarf sich auf strukturierte Kennzahlen aus ERP und CRM beschränkt, ist ein gutes Cloud-Warehouse häufig der einfachere und günstigere Weg. Das Lakehouse spielt seine Stärken erst aus, wenn Datenvielfalt, Datenvolumen und KI-Anspruch zusammenkommen. Genau diese Passung – Konzept zu tatsächlichem Bedarf – zu prüfen, ist aus unserer Sicht der wichtigste erste Schritt jeder Datenstrategie.
In den 1990er- und 2000er-Jahren dominierte das Data Warehouse die Analysewelt. Es war für seine Zeit hervorragend: strukturiert, konsistent, für Berichte optimiert. Doch es hatte einen Preis – im Wortsinn. Speicher und Rechenleistung waren teuer und eng gekoppelt, das Schema musste vorab festgelegt werden, und rohe oder unstrukturierte Daten passten schlecht hinein. Mit der Explosion der Datenmengen und der Datenvielfalt – Web-Daten, Sensoren, Texte, Bilder – wurde diese Starrheit zunehmend zum Hindernis.
Als Antwort entstand ab etwa 2010 das Konzept des Data Lake, eng verbunden mit der Big-Data-Bewegung und Technologien wie dem verteilten Dateisystem Hadoop. Die Idee: Man speichert erst einmal alles in seinem Rohzustand in einem günstigen, skalierbaren Speicher und entscheidet später, wie man es nutzt. Das war befreiend flexibel und billig. Doch in der Praxis kippte die Flexibilität oft ins Chaos. Ohne Struktur, ohne verlässliche Verwaltung und ohne Qualitätssicherung wurden viele Data Lakes zu unbrauchbaren Datensümpfen – Daten lagen zwar da, aber niemand konnte ihnen trauen oder sie verlässlich finden.
Die pragmatische Konsequenz war über Jahre eine Zwei-Welten-Architektur: Unternehmen betrieben beides nebeneinander. Der Data Lake sammelte alle Rohdaten und diente Data Scientists als flexible Spielwiese. Ein Teil dieser Daten wurde regelmäßig in ein klassisches Data Warehouse geladen, dort strukturiert und für Business Intelligence aufbereitet. Diese Architektur funktionierte, war aber teuer und schwerfällig. Man hielt Daten doppelt vor, betrieb zwei Systeme mit zwei Governance-Modellen, und zwischen beiden lief ein ständiger, fehleranfälliger Datentransport. Vor allem entstanden zwei potenziell abweichende Datenstände – ein Nährboden für Diskussionen darüber, welche Zahl denn nun stimmt.
Genau diese Reibung war der Auslöser für das Lakehouse. Die entscheidende technische Voraussetzung reifte erst um 2017 bis 2020 heran: offene Tabellenformate, die auf günstigem Objektspeicher die Verlässlichkeit eines Warehouse ermöglichen. Der Begriff „Lakehouse“ wurde maßgeblich durch das Unternehmen Databricks geprägt und populär, aber das zugrunde liegende Bedürfnis – eine Plattform statt zwei – war branchenweit spürbar. Heute verfolgen praktisch alle großen Anbieter im Datenumfeld eine Lakehouse-Strategie, auch wenn sie unterschiedliche Wege dorthin wählen.
Drei Entwicklungen mussten zusammenkommen, damit das Lakehouse praktikabel wurde. Erstens die Cloud mit ihrem günstigen Objektspeicher: Speicher wurde extrem billig und praktisch unbegrenzt skalierbar, wodurch das „Alles-Speichern“ erschwinglich wurde. Zweitens die Entkopplung von Speicher und Rechenleistung: Anders als im klassischen Warehouse lassen sich beide in der Cloud getrennt und bedarfsgerecht skalieren, was flexible und kostenkontrollierte Analysen ermöglicht. Drittens die offenen Tabellenformate, die dem billigen Speicher die fehlende Struktur und Verlässlichkeit gaben.
Der jüngste, kräftige Treiber ist die KI-Welle. Maschinelles Lernen und generative KI leben von großen, vielfältigen Datenmengen – genau der Stärke des Lake-Teils. Zugleich brauchen sie verlässliche, gut verwaltete Daten – die Stärke des Warehouse-Teils. Das Lakehouse trifft diesen Bedarf im Kern: Es hält die für KI nötige Datenvielfalt vor und legt zugleich die verlässliche Ordnung darüber. Deshalb hat die KI-Diskussion dem ohnehin wachsenden Lakehouse-Konzept in den letzten Jahren spürbaren Rückenwind gegeben.
Der entscheidende Unterschied zur klassischen Warehouse-Welt ist die konsequente Trennung von Speicher und Rechenleistung. Im Lakehouse liegen die Daten in einem günstigen, offenen Speicher, und die Rechenleistung wird bei Bedarf getrennt darauf angesetzt. Das erlaubt es, für verschiedene Aufgaben – Reporting, Datenaufbereitung, maschinelles Lernen – jeweils passende, unabhängig skalierbare Rechenmaschinen auf dieselben Daten anzusetzen, ohne die Daten zu duplizieren.
Ganz unten liegt der Storage-Layer: ein Objektspeicher, wie ihn alle großen Cloud-Anbieter bereitstellen und wie er auch selbst betrieben werden kann. Sein entscheidendes Merkmal ist der niedrige Preis pro gespeicherter Datenmenge, kombiniert mit nahezu unbegrenzter Skalierbarkeit. Hier landen die Daten in offenen Dateiformaten – etwa spaltenorientierten Formaten, die für Analysen effizient sind. „Offen“ bedeutet hier: Die Formate sind quelloffen und standardisiert, sodass verschiedene Werkzeuge dieselben Dateien lesen können und die Daten nicht in einem herstellerspezifischen Format gefangen sind. Dieser Punkt ist für die Vermeidung von Anbieterbindung zentral, wie wir in Kapitel 09 vertiefen.
Die eigentliche Innovation, die das Lakehouse überhaupt ermöglicht, ist die Schicht der offenen Tabellenformate. Ein rohes Verzeichnis voller Dateien ist noch keine verlässliche Tabelle – es fehlen Transaktionssicherheit, ein verwaltetes Schema und geordnete Aktualisierungen. Genau das liefern Tabellenformate: Sie legen über die Rohdateien eine intelligente Verwaltungsebene, die den günstigen Speicher mit Warehouse-Eigenschaften ausstattet. Drei Formate dominieren die Diskussion:
Allen drei Formaten ist gemeinsam, dass sie quelloffen sind und dem Speicher jene Eigenschaften geben, die früher das Warehouse ausmachten: verlässliche, nicht halb ausgeführte Schreibvorgänge (in der Fachsprache ACID-Transaktionen), eine geordnete Verwaltung des Datenschemas samt kontrollierter Änderungen sowie die Möglichkeit, zu früheren Datenständen „zurückzureisen“. Welches Format im Einzelfall passt, hängt von der gewählten Plattform und den Anforderungen ab; die Branche bewegt sich erkennbar in Richtung stärkerer Interoperabilität zwischen den Formaten. Den aktuellen Reifegrad und die konkrete Unterstützung sollte man für den eigenen Anwendungsfall bei der jeweiligen Plattform prüfen.
Über den Tabellenformaten sitzt die Metadaten- und Katalogschicht. Sie ist das Inhaltsverzeichnis und das Regelwerk des Lakehouse zugleich: Sie verzeichnet, welche Tabellen existieren, wie sie aufgebaut sind, wer worauf zugreifen darf und woher die Daten stammen (Datenherkunft). Ohne diesen Katalog bliebe das Lakehouse ein unübersichtlicher Speicher; erst er macht es durchsuchbar, verwaltbar und – besonders wichtig für den DACH-Raum – regelkonform steuerbar. Eine einheitliche, plattformübergreifende Governance über diese Schicht gehört zu den zentralen Reifekriterien einer Lakehouse-Umgebung.
Die oberste Ebene ist die Compute-Schicht, die eigentliche Rechenarbeit. Weil sie vom Speicher entkoppelt ist, lassen sich unterschiedliche Rechenmaschinen auf dieselben Daten ansetzen: eine SQL-Maschine für Berichte und BI, eine Verarbeitungs-Engine für die Datenaufbereitung, eine Umgebung für maschinelles Lernen. Jede skaliert bedarfsgerecht und unabhängig, und alle lesen dieselbe, einzige Datenbasis. Genau diese Kombination – ein Speicher, viele Rechenwerkzeuge, ein Katalog – ist die architektonische Signatur des Lakehouse.
In der alten Zwei-Welten-Architektur waren BI und KI physisch getrennt. Business Intelligence lief auf dem sauberen Warehouse, maschinelles Lernen auf dem rohen Data Lake. Das führte zu doppelter Datenhaltung, abweichenden Datenständen und der ständigen Frage, ob das KI-Modell und der Vorstandsbericht überhaupt auf denselben Zahlen beruhen. Das Lakehouse räumt diese Trennung aus dem Weg: Beide Disziplinen greifen auf dieselbe verwaltete, verlässliche Datenbasis zu – nur mit unterschiedlichen Rechenwerkzeugen.
Für klassische BI verhält sich ein gut aufgebautes Lakehouse weitgehend wie ein Data Warehouse. Über die Gold-Schicht – die geschäftsfertigen, gepflegten Analysetabellen – greifen BI-Werkzeuge wie Power BI, Tableau oder Looker per SQL auf die Daten zu und erzeugen Dashboards und Berichte. Für die Fachbereiche ändert sich im Idealfall nichts Sichtbares: Sie bekommen ihre Auswertungen wie gewohnt, nur dass darunter eine einzige, konsistente Datenbasis liegt statt einer kopierten Teilmenge. Wichtig für realistische Erwartungen: Ob die BI-Leistung eines Lakehouse an ein spezialisiertes Warehouse heranreicht, hängt stark von Plattform, Datenmodell und Optimierung ab – das ist ein Punkt, den man für den konkreten Fall bewerten sollte, statt ihn pauschal anzunehmen.
Der große Gewinn zeigt sich bei maschinellem Lernen. Data Scientists brauchen oft rohe, unstrukturierte oder halbstrukturierte Daten in großer Vielfalt – genau das, was der Lake-Teil des Lakehouse günstig vorhält. Sie können direkt auf dieselben verwalteten Daten zugreifen, aus denen auch das Reporting entsteht, ohne separate Kopien anlegen zu müssen. Das verkürzt den Weg vom Rohdatum zum trainierten Modell, verringert Reibung zwischen den Teams und stellt sicher, dass Data Science und BI von derselben Wahrheit ausgehen. Für Unternehmen, die KI ernsthaft betreiben wollen, ist diese gemeinsame Grundlage einer der überzeugendsten Gründe für das Konzept.
Mit dem Aufkommen generativer KI hat das Lakehouse zusätzliche Bedeutung gewonnen. Generative KI-Anwendungen, die auf unternehmenseigenem Wissen aufsetzen sollen – etwa ein interner Assistent, der Fragen anhand firmeneigener Dokumente beantwortet –, brauchen eine gut organisierte, verlässliche und zugriffskontrollierte Datenbasis. Das Lakehouse ist dafür ein natürlicher Kandidat, weil es genau die Vielfalt (Texte, Dokumente, Tabellen) mit der nötigen Verwaltung und Governance verbindet. Es wird damit oft zum Fundament, auf dem Verfahren wie das Anreichern von KI-Antworten mit firmeneigenen Daten (bekannt als Retrieval-Augmented Generation) aufsetzen.
Aus Beratungssicht ist hier jedoch Nüchternheit geboten: Ein Lakehouse ist eine Voraussetzung für seriöse KI-Vorhaben, kein KI-Produkt an sich. Es liefert die geordnete Datengrundlage; die eigentliche KI-Anwendung wird darauf gebaut. Wer glaubt, mit der Einführung eines Lakehouse allein „KI zu haben“, verwechselt Fundament mit Gebäude. Der Wert entsteht erst, wenn auf einer sauberen Datenbasis konkrete, fachlich durchdachte Anwendungsfälle umgesetzt werden.
Wichtig vorweg: Alle folgenden Plattformen verfolgen inzwischen eine Lakehouse-Strategie, kommen aber aus unterschiedlichen Richtungen. Manche stammen aus der Data-Science- und Big-Data-Welt und haben das Warehouse-Element ergänzt; andere kommen aus der Warehouse-Welt und haben sich zum Lake hin geöffnet. Das prägt bis heute ihre jeweiligen Stärken. Wir beschreiben sie hier neutral und verzichten bewusst auf Ranglisten oder erfundene Kennzahlen – die passende Wahl hängt vom konkreten Bedarf ab.
Die großen kommerziellen Plattformen bieten weitgehend fertige Lakehouse-Umgebungen. Ihr Vorteil ist die geringere Einstiegshürde: Speicher, Tabellenformat, Katalog und Rechenwerkzeuge sind aufeinander abgestimmt und werden vom Anbieter betrieben. Für viele Mittelständler, die kein großes Datenteam haben, ist das der pragmatischere Weg. Der Preis dafür ist eine gewisse Bindung an den Anbieter und dessen Preismodell sowie die Auslagerung des Betriebs. Wie stark diese Bindung wiegt, hängt maßgeblich davon ab, ob die Plattform auf offene Formate setzt – dazu mehr in Kapitel 09. Konkrete Funktionsumfänge, Preise und Serverstandorte unterscheiden sich zwischen den Anbietern und über die Zeit; sie sollten stets direkt beim jeweiligen Anbieter geprüft werden.
Weil alle Kernbausteine – Objektspeicher, Tabellenformate, Kataloge und Rechen-Engines – auch quelloffen verfügbar sind, lässt sich ein Lakehouse vollständig aus offenen Komponenten selbst zusammenstellen. Der Reiz ist offensichtlich: maximale Kontrolle, keine Lizenzbindung an einen einzelnen Anbieter und volle Datenhoheit, gerade auch bei Betrieb in einer selbst gewählten Umgebung. Die Kehrseite ist der höhere Eigenaufwand: Die Bausteine müssen ausgewählt, integriert, betrieben und gewartet werden, was technische Kompetenz voraussetzt. Für den typischen Mittelständler ohne spezialisiertes Datenteam ist der reine Selbstbau meist zu aufwendig; oft ist ein Mittelweg sinnvoll, bei dem man auf offene Formate setzt, aber eine verwaltete Plattform für den Betrieb nutzt.
Am besten versteht man das Lakehouse in der Reihe seiner Verwandten. Das Data Warehouse ist der strukturierte Klassiker für Analysedaten: verlässlich und für BI optimiert, aber teuer und schwach bei rohen, unstrukturierten Daten. Der Data Lake ist der günstige, flexible Rohdatenspeicher, der ohne Disziplin schnell zum Datensumpf wird. Das Lakehouse versucht, beide zu vereinen. Data Mesh schließlich ist etwas grundsätzlich anderes – kein technisches Speicherkonzept, sondern ein Organisationsansatz.
Gegenüber dem klassischen Data Warehouse ist das Lakehouse offener für Datenvielfalt und in der Regel günstiger im Speicher, weil es auf preiswertem Objektspeicher aufsetzt. Ein reines, ausgereiftes Warehouse kann bei klassischer SQL-BI mit sehr strukturierten Daten weiterhin Vorteile bei Einfachheit und ausgereifter Performance haben – ein Punkt, den man nicht wegdiskutieren sollte. Gegenüber dem klassischen Data Lake bringt das Lakehouse die entscheidende Ordnung und Verlässlichkeit, die dem Lake fehlt: Aus dem chaotischen Rohdatenspeicher wird durch die Tabellenformat-Schicht eine verwaltbare, verlässliche Grundlage. Man kann das Lakehouse insofern als „Data Lake mit angezogener Handbremse und Sicherheitsgurt“ verstehen – die Flexibilität bleibt, aber das Chaos wird gebändigt.
Wichtig ist die realistische Einordnung: Das Lakehouse ist ein Kompromiss, der in vielen Fällen sehr gut aufgeht, aber nicht in jedem Aspekt beide Vorgänger gleichzeitig übertrifft. Ein spezialisiertes Werkzeug kann in seiner Nische überlegen sein. Der Vorteil des Lakehouse liegt weniger in der Spitzenleistung einer Einzeldisziplin als in der Vereinigung – eine Plattform statt zwei, ein Datenstand statt konkurrierender Kopien.
Häufig wird Data Mesh in einem Atemzug mit dem Lakehouse genannt, was zu Verwirrung führt, weil beide gar nicht dasselbe Problem lösen. Das Lakehouse ist ein technisches Architektur-Konzept für die Datenspeicherung und -verarbeitung. Data Mesh ist dagegen ein organisatorisch-methodischer Ansatz: Er beschreibt, wie große Organisationen die Verantwortung für Daten verteilen – nämlich dezentral, indem die Fachbereiche ihre Daten selbst als „Datenprodukte“ verantworten, statt alles an ein zentrales Team zu delegieren. Data Mesh sagt also etwas über Zuständigkeiten und Organisation, das Lakehouse etwas über Technik.
Beide schließen sich nicht aus, sondern können sich ergänzen: Eine Organisation kann einen Data-Mesh-Ansatz verfolgen und dabei ein Lakehouse als technische Grundlage nutzen. Für den typischen Mittelständler ist Data Mesh allerdings meist überdimensioniert – es adressiert vor allem die Organisationsprobleme sehr großer, dezentraler Konzerne. Wir erwähnen es hier vor allem zur Abgrenzung: Wer „Lakehouse“ und „Mesh“ als Alternativen behandelt, vergleicht Äpfel mit Organigrammen.
Der häufigste Fehler ist der Big-Bang-Ansatz: alles auf einmal ins neue Lakehouse migrieren zu wollen. Das überfordert Teams, Budgets und Nerven. Bewährt hat sich das Gegenteil – ein fokussierter Start mit einem konkreten, schmerzhaften Anwendungsfall, der schnell sichtbaren Wert liefert und Akzeptanz schafft. Aus diesem ersten Erfolg wächst die Plattform organisch weiter, statt sich an einem überdimensionierten Erstwurf zu verheben.
Die wichtigste inhaltliche Weichenstellung ist die Datenmodellierung. Ein Lakehouse ohne innere Ordnung ist nur ein teurerer Datensumpf. Bewährt hat sich die bereits erwähnte Schichtung nach dem Medaillon-Prinzip: rohe Daten in der Bronze-Schicht, bereinigte und geprüfte Daten in Silber, geschäftsfertige Analysetabellen in Gold. Diese Stufung – vom Rohen zum Fertigen, in benannten, dokumentierten Schritten – ist das wirksamste Mittel gegen Wildwuchs und schafft die Nachvollziehbarkeit, die Fachbereiche und Prüfer brauchen. Aus unserer Erfahrung ist eine von Anfang an saubere Struktur samt Namenskonventionen einer der am meisten unterschätzten Erfolgsfaktoren; nachträgliches Aufräumen ist deutlich mühsamer.
Ein wertvolles Werkzeug für die Transformation innerhalb dieser Schichten ist eine dedizierte Transformationsschicht. Viele Lakehouse-Umgebungen lassen sich mit einem SQL-basierten Transformationswerkzeug kombinieren, das Modelle, Tests und Dokumentation zwischen den Schichten pflegt – ein Baustein, den wir in einem eigenen Fachartikel vertiefen.
Die Migration in ein Lakehouse verläuft selten als radikaler Umzug, sondern als schrittweise Ablösung. Häufig läuft das bestehende System zunächst weiter, während für einen ersten Anwendungsfall parallel eine Lakehouse-Grundlage entsteht. Bewährt sich diese, wandern nach und nach weitere Datenbereiche hinüber. Diese Koexistenz nimmt Risiko aus dem Projekt und erlaubt es, zu lernen, bevor man sich vollständig festlegt. Wer ein Lakehouse auf offenen Formaten aufbaut, hält sich dabei zusätzlich die Tür offen, Werkzeuge später auszutauschen.
Gerade im deutschsprachigen Mittelstand entscheidet die Data Governance über Erfolg oder Scheitern eines Lakehouse. Weil in einem Lakehouse potenziell alle Daten des Unternehmens an einem Ort zusammenlaufen, wird die Frage, wer worauf zugreifen darf, geschäftskritisch. Die Metadaten- und Katalogschicht ist dafür das zentrale Werkzeug: Über sie werden Zugriffsrechte, Datenklassifizierung, Datenherkunft und Qualitätsregeln zentral verwaltet. Ein Lakehouse ohne durchdachte Governance ist nicht nur unübersichtlich, sondern auch ein Datenschutz- und Compliance-Risiko.
Wir empfehlen, Governance nicht als lästige Nachrüstung, sondern als integralen Bestandteil des Aufbaus zu behandeln. Ein klares Rollenkonzept, konsequente Zugriffssteuerung, nachvollziehbare Datenherkunft und dokumentierte Datenqualität sind kein bürokratischer Selbstzweck, sondern die Voraussetzung dafür, dass man den Daten trauen und sie regelkonform nutzen kann. Genau an dieser Schnittstelle zwischen Technik, Daten, Organisation und Regelwerk setzt unsere Beratungsarbeit an – herstellerneutral und mit Blick auf die Besonderheiten des DACH-Raums.
Besonders naheliegend ist das Lakehouse für mittelständische Unternehmen, deren Daten über reine Tabellen hinausgehen. Ein klassisches Beispiel ist ein Produktionsbetrieb mit Sensordaten: Neben den strukturierten Auftrags- und Finanzdaten fallen große Mengen an Maschinen- und Sensordaten an, die man für vorausschauende Wartung oder Qualitätsanalysen nutzen möchte. Ein klassisches Warehouse tut sich mit diesen Datenströmen schwer, ein Lakehouse hält sie günstig vor und macht sie zugleich analysierbar. Ähnlich relevant ist das Konzept für Unternehmen, die strukturierte und unstrukturierte Daten gemeinsam auswerten wollen – etwa Verkaufszahlen zusammen mit Kundendokumenten, Bildern oder Textdaten.
Ein zweiter typischer Auslöser ist ein ernsthaftes KI-Vorhaben. Wer über Dashboards hinaus in maschinelles Lernen oder generative KI auf eigenen Daten investieren will, profitiert von der gemeinsamen, verwalteten Datenbasis, die ein Lakehouse bietet. Ein dritter, sehr pragmatischer Auslöser: Unternehmen, die bereits getrennt einen Data Lake und ein Warehouse betreiben und unter der doppelten Datenhaltung, den doppelten Kosten und den auseinanderlaufenden Datenständen leiden. Für sie ist die Konsolidierung auf eine Lakehouse-Plattform oft eine spürbare Vereinfachung.
Genauso wichtig ist die Gegenprobe. Für einen Mittelständler, dessen Analysebedarf sich auf strukturierte Kennzahlen aus ERP und CRM beschränkt und der keine ernsthaften KI-Ambitionen hat, ist ein Lakehouse häufig überdimensioniert. Ein gutes Cloud-Data-Warehouse ist dann einfacher aufzusetzen, leichter zu betreiben und oft günstiger. Wir sehen es als Teil ehrlicher Beratung, Unternehmen auch von einem Lakehouse abzuraten, wenn ihr Bedarf es nicht hergibt. Die Faustregel: Der Wert des Lakehouse steigt mit der Vielfalt der Datenarten, dem Datenvolumen und dem KI-Anspruch. Fehlen diese Treiber, gewinnt die Einfachheit.
Ein erster, klar umrissener Lakehouse-Anwendungsfall – von der Plattformwahl über den Aufbau der Datenschichten bis zu einem verlässlichen, dokumentierten Analysedatensatz – ist in vielen Mittelstands-Projekten in einigen Wochen bis wenigen Monaten realisierbar, abhängig von Datenlage und gewählter Plattform. Der Aufbau einer breiten, unternehmensweiten Datenplattform über viele Bereiche hinweg ist dagegen ein fortlaufendes Programm über mehrere Monate. Wichtig ist die ehrliche Einordnung: Das Lakehouse ist ein Fundament, kein Rundum-sorglos-Paket, und entfaltet seinen Wert erst, wenn darauf konkrete, fachlich durchdachte Anwendungen entstehen.
Die Kostenstruktur eines Lakehouse hat mehrere Bestandteile, die man zusammendenken muss. Der Speicher ist dank günstigem Objektspeicher meist der kleinere Posten – hier liegt ein wesentlicher Kostenvorteil gegenüber einem klassischen Warehouse. Der größere und variablere Posten ist die Rechenleistung: Weil sie vom Speicher entkoppelt ist und bedarfsgerecht zugeschaltet wird, entstehen Kosten vor allem dann, wenn tatsächlich gerechnet wird. Das ist einerseits fair, andererseits schwerer vorhersehbar – ineffiziente Abfragen oder unkontrollierte Rechenlast können die Rechnung schnell in die Höhe treiben. Hinzu kommen je nach Weg Plattform- oder Lizenzkosten (bei verwalteten Anbietern) oder Betriebsaufwand (beim Selbstbau aus offenen Komponenten).
Für die Kostenkontrolle ist die entkoppelte Architektur zugleich Chance und Risiko. Chance, weil man Speicher und Rechenleistung getrennt und bedarfsgerecht dimensionieren kann, statt teure Kapazität dauerhaft vorzuhalten. Risiko, weil verbrauchsbasierte Modelle ohne Kostenbewusstsein aus dem Ruder laufen können. Wir empfehlen, von Anfang an auf effiziente Datenmodelle, überlegte Abfragen und eine Überwachung der Rechenlast zu achten. Wer die Gesamtkosten seiner Datenplattform betrachtet, muss Speicher, Rechenleistung, Plattform- beziehungsweise Betriebskosten und die Kosten der umliegenden Werkzeuge zusammenrechnen – eine seriöse Kalkulation ist immer eine Einzelfallbetrachtung.
Weil in einem Lakehouse potenziell große Mengen – auch personenbezogener – Daten an einem Ort zusammenlaufen, ist der Datenschutz besonders sorgfältig zu betrachten. Die zentrale Frage lautet, wo die Daten physisch liegen und wer sie kontrolliert. Bei den großen kommerziellen Plattformen handelt es sich häufig um US-nahe Anbieter, was – wie bei allen US-Anbietern – berechtigte Fragen zu Datenschutz und Datenhoheit aufwirft. Hier sind der angebotene Serverstandort (idealerweise eine EU-Region), die vertraglichen Instrumente wie ein Auftragsverarbeitungsvertrag und die etablierten Sicherheitszertifizierungen zu prüfen.
Ein entscheidender Hebel für Datenhoheit und Souveränität ist die Wahl zwischen Cloud und Self-Hosting sowie die konsequente Nutzung offener Formate. Ein Lakehouse aus offenen Bausteinen – offener Objektspeicher, offenes Tabellenformat, offener Katalog – lässt sich grundsätzlich auch in einer selbst kontrollierten oder europäischen Umgebung betreiben, wodurch die Daten das Unternehmen beziehungsweise den EU-Raum nicht verlassen müssen. Für Unternehmen mit hohen Souveränitätsanforderungen ist das oft der bevorzugte Weg. Bei verwalteten Cloud-Plattformen bleibt – wie bei allen US-nahen Anbietern – ein grundsätzliches Drittland-Thema, das seit den Schrems-Urteilen und der Diskussion um den US Cloud Act kontrovers bewertet wird.
Die offenen Tabellenformate sind dabei nicht nur eine technische Feinheit, sondern das wirksamste Mittel gegen Vendor-Lock-in. Weil die Daten in einem offenen, standardisierten Format vorliegen, das verschiedene Werkzeuge lesen können, bleibt man nicht dauerhaft an einen einzelnen Anbieter gebunden – ein Plattformwechsel wird realistisch, ohne die Daten aufwendig umzuformen. Für den Mittelstand, der langfristige Abhängigkeiten und schwer kalkulierbare Preissteigerungen fürchtet, ist dieser Schutz durch offene Formate ein zentrales strategisches Argument. Die endgültige datenschutzrechtliche Bewertung bleibt gleichwohl eine Frage des Einzelfalls und gehört in fachkundige Hände.
