Databricks für den Mittelstand: Wann eine gemeinsame Daten- und KI-Plattform sinnvoll ist
Die Kernaussagen auf einen Blick.
- Die teuerste Stelle im Mittelstandsdatenstack ist meistens die versteckte Betriebsseite. Betrieb, Integration und Pflege vieler einzelner Tools verschlingen den größten Teil, und genau dieser Aufwand pro Daten- oder KI-Anwendung taucht in keinem Reporting auf.
- Databricks konsolidiert die typischen Bausteine aus dem Modern Data Stack auf einer Plattform: Datenintegration, Analytics, Governance, ML, GenAI und ausgewählte operative Anwendungen. Weniger Tools, weniger Verträge, weniger Schnittstellen und eine klare Plattformverantwortung an einer Stelle.
- Drei Hebel senken die Gesamtkosten messbar: weniger Lizenzen und Verträge, effizientere Verarbeitung mit weniger manueller Wartung und vor allem mehr Kapazität für neue Datenprodukte und KI-Use-Cases. Der direkte Geschäftsnutzen: kürzere Umsetzungszeiten und mehr produktive Anwendungen pro Quartal.
- Mein Vorschlag: Weg vom individuellen Best-of-Breed- und Tool-Management, hin zum Plattformgedanken. Eine konsolidierte Plattform setzt Kapazität frei, die heute in Tool-Betrieb gebunden ist, und verschiebt den Fokus von Tool-Pflege zu Value Creation in Form neuer Datenprodukte und KI-Anwendungen.
Inhaltsverzeichnis
Warum Databricks für den Mittelstand relevant ist
Ein typischer Datenstack im Mittelstand ist oft über mehrere Jahre gewachsen: Fivetran für ein paar SaaS-Quellen, dbt Cloud für die Transformationen, Snowflake als Warehouse, Airflow für alles, was Fivetran nicht abdeckt, Power BI für Reporting, Hightouch für Reverse-ETL, seit dem ersten KI-Piloten eine Vektordatenbank, ein selbst gehostetes MLflow und ein paar Python-Skripte mit OpenAI-API. Fünf Personen im Datenteam, davon zwei für Pipelines, einer für BI, einer für ML und KI, einer als Lead. Auf den ersten Blick wirkt dieser Stack modern und flexibel.
Tatsächlich fließt aber viel Zeit in die Verbindung, Überwachung und Pflege der einzelnen Tools. Updates und Versionswechsel für jedes Tool, Bibliotheks- und API-Updates, Zugriffsrechte in mehreren Systemen, die regelmäßige Erneuerung technischer Zugangsdaten, Monitoring in mehreren Oberflächen. Für eine neue Datenquelle müssen oft mehrere Tools angepasst werden: Datenübertragung, Transformation, Berechtigungen und Reporting. Auch ein neuer KI-Anwendungsfall bringt oft neue Entscheidungen mit sich: zu Datenhaltung, Modellzugriff, Betrieb und Berechtigungen.
Oft ist nicht klar geregelt, wer für das Zusammenspiel der Tools verantwortlich ist. Auch die Frage „Was kostet uns das wirklich?" ist häufig nicht sauber beantwortet. Lizenzkosten sind sichtbar. Der interne Aufwand für Betrieb, Abstimmung und Fehlerbehebung bleibt dagegen oft verborgen.
In dieser Situation wird Databricks aus zwei Gründen oft übersprungen. Zum einen gibt es die Annahme, Databricks sei nur für Großkonzerne. Zum anderen die berechtigte Sorge, dass eine konsolidierte Plattform zunächst komplexer wirkt als mehrere spezialisierte SaaS-Lösungen, weil jede einzelne Lösung für sich überschaubar wirkt. Beide Annahmen führen dazu, dass Unternehmen ihr Tool-Portfolio dauerhaft erweitern, ohne die Plattformstrategie zu hinterfragen. Jede neue Anforderung führt zu einem weiteren Tool, ohne den Business Case einer gemeinsamen Plattform sauber zu prüfen.
Databricks TCO: Wo Kosten im modernen Datenstack wirklich entstehen
Eine realistische Gesamtkostenbetrachtung im Mittelstand zeigt oft ein anderes Bild als die Summe der monatlichen Tool-Rechnungen. Lizenzen und Cloud-Verbrauch sind leicht messbar, weil sie monatlich in der Buchhaltung sichtbar sind. Der Aufwand für Betrieb, Integration und Betreuung ist mindestens genauso wichtig, wird aber selten als eigener Kostenblock im Plattform-Reporting geführt. Er steckt oft in Personalkosten und Projektaufwand und bleibt damit unsichtbar für die eigentliche Investitionsentscheidung.
Eine grobe Aufstellung für einen typischen Mid-Market-Stack:
| Kostenblock | Anteil an TCO | Typische Treiber |
|---|---|---|
| Lizenzen und Nutzungsgebühren der Datenwerkzeuge (Fivetran, dbt, Snowflake-Credits, Power BI, MLflow, Vector-DB) | 15–25 % | Quellen, Modelle, User, Speicher |
| Zusätzliche Cloud-Ressourcen für selbst betriebene Tools | 5–10 % | Airflow-Cluster, Python-Worker, Vector-DB-Pods |
| Aufwand für Integration und Anpassung der Systeme | 15–20 % | jede Tool-Verkettung, jede neue Quelle, jede SDK-Migration |
| Laufender Betrieb, Updates, Monitoring und Support | 25–35 % | Personentage pro Tool und Monat |
| Aufwand für Berechtigungen, Datenschutz und Audit | 10–15 % | jede Berechtigungs-Schicht pro Tool |
| Verlorene Kapazität für neue Datenprodukte und KI-Anwendungen | nicht quantifizierbar | gebundene Engineering-Kapazität |
Die direkten Rechnungen sind meist bekannt. Für die langfristigen Gesamtkosten sind jedoch vor allem Integrations-, Betriebs- und Personalkosten entscheidend. Wenn mehrere Mitarbeitende einen großen Teil ihrer Zeit für Betrieb und Integration aufwenden, ist dies in kleinen Data-&-AI-Organisationen schnell ein erheblicher Kosten- und Kapazitätsfaktor. Wenn Personal-, Arbeitsplatz- und Gemeinkosten vollständig eingerechnet werden, kann der interne Aufwand deutlich höher sein als die Summe einzelner Softwarelizenzen.
Niedrigere Gesamtkosten entstehen im Mittelstand meist über weniger Tools, weniger Schnittstellen und weniger Betriebsaufwand. Günstigere Lizenzen tragen dazu bei, sind aber selten der Hauptfaktor. Der Effekt wird sichtbar, sobald der interne Betriebsaufwand systematisch erfasst wird.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Modern Data Stack vs. Lakehouse: Was eine gemeinsame Plattform vereinfacht
Eine gemeinsame Plattform muss nicht in jeder einzelnen Funktion besser sein als ein Spezialtool. Ihr Vorteil entsteht dadurch, dass weniger einzelne Systeme miteinander verbunden werden müssen. Zugriffsrechte werden zentral gepflegt und nicht mehr in mehreren Tools parallel. Deployments und Änderungen folgen einem einheitlichen Prozess. Compute wird einheitlich bereitgestellt, begrenzt und überwacht. Daten, Modelle und Berechtigungen liegen in einer gemeinsamen Verwaltungsstruktur.
Databricks beschreibt seine Data Intelligence Platform als einheitliche Schicht für Daten-, Analytics- und KI-Workloads: Ingestion, Lakehouse, Warehouse, BI, ML, GenAI und seit Lakebase auch OLTP in einer Governance-Schicht via Unity Catalog. Damit verschiebt sich die Entscheidung von „welches Spezialtool für welche Schicht" zu „welche Aufgaben auf einer Plattform gebündelt werden sollten und wo Spezialtools bewusst sinnvoll bleiben".
Im Zentrum Unified Governance und Unified Data, darum gleichmäßig verteilt die fünf Workload-Schichten Business Intelligence, Data Warehousing, AI & Data Science, ETL & Real-Time Analytics und Orchestration, umfasst von einem offenen Data Lake.
Plattform-Konsolidierung: Welche Tools Databricks ersetzen oder ergänzen kann
Für mittelständische Unternehmen lassen sich die wichtigsten Aufgaben so einordnen:
| Schicht | Typische Einzeltools | Mögliche Databricks-Bausteine |
|---|---|---|
| Anbindung von SaaS- und Fachsystemen | Fivetran, Airbyte | Lakeflow Connect, Auto Loader |
| Streaming und laufende Datenströme | Kafka + Self-Code | Zerobus, Structured Streaming |
| Orchestrierung von Datenjobs | Airflow, Dagster | Lakeflow Jobs |
| Transformation und Datenmodellierung | dbt Core/Cloud | Spark Declarative Pipelines, Lakeflow Designer |
| SQL-Analysen und Reporting-Schicht | Snowflake, BigQuery, Redshift | Databricks SQL, SQL Warehouses, Photon |
| BI | Tableau, Power BI, Looker | AI/BI Dashboards, Genie, Publish in BI-Tools |
| Vektorsuche für GenAI- und RAG-Anwendungen | Pinecone, Weaviate, Qdrant | Vector Search |
| Entwicklung, Versionierung und Freigabe von ML-Modellen | MLflow Self-Host, SageMaker | Mosaic AI, Managed MLflow |
| Model Serving | Bento, Triton, SageMaker Endpoints | Mosaic AI Model Serving |
| Bereitstellung aufbereiteter Daten für Anwendungen | Hightouch, Census | Delta Sharing, Lakebase, native Apps |
| Monitoring von Datenqualität und Datenzustand | Soda, Monte Carlo | Lakehouse Monitoring, Unity Catalog Tags |
| Transaktionale Datenbank für Anwendungen | separate Postgres/MySQL | Lakebase |
| Zentrale Verwaltung von Berechtigungen, Audit und Datenherkunft | pro Tool eigene Berechtigungen | Unity Catalog (eine Berechtigung, ein Audit, eine Lineage) |
Der konkrete Vorteil liegt in weniger getrennten Betriebs- und Integrationswegen. Eine konsolidierte Plattform ist für kleine und mittelständische Unternehmen nicht nur bequemer, sondern setzt Kapazität für neue Anwendungen frei. Der wichtigste Nutzen ist oft die Zeit, die nicht mehr in den Betrieb einzelner Tools fließt. Niedrigere Gesamtkosten sind dann eine direkte Folge dieser Vereinfachung.
Was unter dieser Schicht liegt und wie sie technisch aufgebaut ist, ordnen wir im Überblick zur Data Intelligence Platform ein.
Wie senkt Databricks Kosten im Mittelstand?
Drei Hebel beeinflussen gemeinsam die Gesamtkosten. Keiner davon reicht allein aus, um den Business Case zu begründen. Zusammen können sie aber spürbar verändern, wie wirtschaftlich eine Daten- und KI-Plattform betrieben wird.
Lizenz-Konsolidierung. Mehrere einzelne Softwareverträge können durch weniger zentrale Plattformverträge ersetzt werden. Der Vorteil liegt nicht nur im Einkaufspreis. Weniger Anbieter bedeuten auch weniger Aufwand für Verträge, Datenschutzprüfungen, Security Reviews und laufende Abstimmung. Gerade in kleineren Organisationen ist das relevant, weil diese Aufgaben oft nebenbei von denselben Personen getragen werden, die eigentlich Projekte voranbringen sollen. Trotzdem bleibt der tatsächliche Nutzungsumfang entscheidend, weil viele Plattformkosten verbrauchsabhängig entstehen.
Plattform-Bündelung. Ingestion, Orchestrierung, BI, ML und GenAI laufen auf einer gemeinsamen Plattform statt über viele einzelne Werkzeuge verteilt. Der eigentliche Effekt entsteht an den Stellen, die dadurch einfacher werden: weniger separate Pipelines zwischen Warehouse und Vector Store, weniger Reverse ETL zwischen Lakehouse und operativer Anwendung, weniger doppelte Datenkopien zwischen Reporting, Feature Store und KI-Anwendungen. Dadurch sinkt nicht nur die technische Komplexität, sondern auch der Aufwand für Monitoring, Berechtigungen, Fehlersuche und Änderungen. Wirtschaftlich zeigt sich das vor allem daran, wie viel weniger Engineering-Zeit für neue Datenquellen und neue Use Cases benötigt wird.
Personal-Effizienz. Das Team arbeitet mit einer gemeinsamen Plattform statt mit vielen spezialisierten Einzeltools. Das reduziert Einarbeitung, Übergaben und die dauerhafte Wartung verschiedener Architekturbausteine. Mit weniger Werkzeugen entsteht schneller Routine, neue Mitarbeitende werden früher produktiv und kritisches Wissen verteilt sich besser im Team. Genau dieser Effekt wird in TCO-Rechnungen oft unterschätzt. Die gewonnene Zeit steht auf keiner Software-Rechnung, entscheidet aber in der Praxis darüber, ob Engineers und Data Scientists ihre Zeit in Wartung stecken oder in neue Reports, Modelle, Automatisierungen und KI-Anwendungen.
Mehr Kapazität für neue Datenprodukte und KI-Anwendungen
Kostensenkung ist nur ein Teil des Nutzens. Mindestens genauso wichtig ist die Kapazität, die in der Data-&-AI-Organisation frei wird und in fachliche Use Cases fließen kann. Der Wert entsteht damit nicht nur über geringere Kosten, sondern über mehr Geschäftsnutzen.
Konkret: Wenn weniger Zeit in Betrieb und Tool-Pflege fließt, werden pro Woche spürbare Kapazitäten frei. Diese Stunden lassen sich in zwei Richtungen einsetzen:
- Fokus auf Value Creation. Eine KI-Suche über interne Dokumente, die Vertrieb und Service schneller antwortfähig macht. Eine Bedarfsprognose für Einkauf oder Lagerplanung, die Kapitalbindung und Bestände reduziert. Ein natürlichsprachiger Zugang zu Vertriebskennzahlen, der Fachbereiche unabhängig vom Reporting-Team macht. Die freigesetzte Kapazität fließt in das, was das Business braucht, und nicht in weitere Tool-Integrationen.
- Mehr Zeit für Qualität und Verlässlichkeit der Daten. Mehr automatisierte Tests, bessere Nachvollziehbarkeit von Datenflüssen, mehr Enablement für Fachbereiche, ein gepflegtes Daten-Glossar in Unity Catalog. Betriebliche Effizienz, die nicht auf der monatlichen Rechnung sichtbar ist, sich aber in weniger Abstimmungen über unterschiedliche Kennzahlen und Datenstände zeigt.
Offene Formate: Wie Delta und Iceberg Lock-in begrenzen
Eine berechtigte Frage bei jeder Plattformentscheidung ist: Was passiert, wenn Databricks später wieder abgelöst werden soll? Eine zentrale Datenplattform ist keine kurzfristige Tool-Entscheidung, sondern legt die technische Richtung für mehrere Jahre fest.
Das Risiko lässt sich reduzieren, wenn Daten nicht in proprietären Formaten eingeschlossen werden. Genau hier sind offene Datenformate und offene Schnittstellen wichtig:
- Delta Lake als primäres Tabellenformat, Open Source unter der Linux Foundation.
- Apache Iceberg über UniForm, damit andere Analysewerkzeuge dieselben Daten lesen können, zum Beispiel Snowflake, Trino, BigQuery oder AWS Athena.
- Apache Spark als offen verfügbare Verarbeitungsengine.
- SQL als vertraute Abfragesprache statt proprietärer Speziallogik.
- Delta Sharing als offenes Protokoll für den Datenaustausch über verschiedene Plattformen hinweg.
- Unity Catalog mit offenen Schnittstellen und seit 2024 selbst als Open-Source-Projekt.
Praktisch bedeutet das: Die Daten können im eigenen Cloud-Speicher liegen und in offenen Tabellenformaten gehalten werden. Bei einem späteren Wechsel müsste vor allem die technische Verarbeitung neu aufgebaut werden: Jobs, Pipelines, Orchestrierung, Automatisierungen und Teile der Governance. Die Datenbasis selbst ist aber nicht zwangsläufig verloren oder nur noch innerhalb von Databricks nutzbar.
Das ist ein wichtiger Unterschied. Ein Plattformwechsel bleibt trotzdem aufwendig. Kein offenes Format nimmt einem die Migration von Logik, Berechtigungen, Betriebsprozessen und Anwendungen vollständig ab. Aber es macht einen Unterschied, ob nur Workloads neu aufgebaut werden müssen oder ob zusätzlich die gesamte Datenbasis aus einem geschlossenen System herausgelöst werden muss.
Die zentrale Aussage ist deshalb: Databricks schafft keine vollständige Unabhängigkeit vom Anbieter. Die Abhängigkeit wird aber besser begrenzbar, weil Datenformate, Sharing-Protokoll, Catalog-Schnittstellen und Verarbeitungsengine auf offenen Standards aufsetzen. Damit wird ein späterer Wechsel nicht trivial, aber planbarer.
Unity Catalog im Mittelstand: Governance mit kleiner Plattformverantwortung
Zentrale Governance ist vor allem deshalb wichtig, damit wenige Verantwortliche mehrere Daten- und KI-Anwendungen zuverlässig betreiben können. Wenn jedes Tool eigene Rollen, Nutzer und Freigaben braucht, steigt der Verwaltungsaufwand schnell stärker als die Größe der Plattformverantwortung.
Unity Catalog ist die Antwort auf diese Frage. Ein gemeinsames Berechtigungsmodell für Daten, Dateien, Modelle, Funktionen und Anwendungen. Eine zentrale Sicht auf Herkunft und Nutzung der Daten. Eine gemeinsame Grundlage für Audit-Auswertungen. Eine zentrale Suche nach Daten und Modellen. RBAC, ABAC, Row-Level Security und Column Masking laufen auf derselben Engine. Die Berechtigungs-Tiefe reicht für DSGVO-konforme Freigaben, Auditierbarkeit und nutzerspezifische Datensichten aus, ohne paralleles Berechtigungs-Management über mehrere Tools.
Ein häufiges Problem im Mittelstand: Dieselbe Kennzahl wird in mehreren Berichten unterschiedlich berechnet, weil sie über mehrere BI-Pipelines mit eigener Logik läuft. Marketing berechnet Customer Lifetime Value über ein Power-BI-Dataset, Finanzen über ein Snowflake-View, Vertrieb über ein selbst gebautes Excel mit ODBC-Verbindung. Unity Catalog ermöglicht, dieselben kuratierten Daten für mehrere Nutzer und Werkzeuge bereitzustellen, ohne weitere Kopien zu erzeugen. Eine geprüfte Tabelle wird zentral gepflegt und an die benötigten Anwendungen freigegeben. Power BI, Tableau, Excel und Google Sheets binden sich über native Connectoren direkt an den Catalog an. Ein Teil der heutigen Rückübertragungen in operative Anwendungen kann durch Delta Sharing oder Lakebase vereinfacht werden.
Zusätzlichen Nutzen bieten verwaltete Tabellen und automatische Optimierungen. Unity Catalog Managed Tables automatisieren Liquid Clustering, Statistik-Sammlung und Vacuum. Predictive Optimization steuert das je Tabelle und kann Abfragen beschleunigen und den Speicherbedarf reduzieren. Der Effekt kann messbar werden: schnellere Queries, geringere Storage-Rechnung, weniger regelmäßige Pflege durch die Data-&-AI-Organisation.
Was Unity Catalog operativ leistet und wo die Topologie-Entscheidungen liegen, ordnen wir im Überblick zu Unity Catalog ein. Wie Datenprodukte über Delta Sharing organisationsübergreifend genutzt werden, ordnen wir im Überblick zu Delta Sharing ein.
AI/BI und Genie: Self-Service Analytics direkt auf der Datenplattform
KI-Projekte scheitern im Mittelstand häufig am Zugang zu verlässlichen und berechtigten Daten. Welches Modell eingesetzt wird, ist oft nicht die schwierigste Frage. Ein RAG-System auf Unternehmenswissen braucht vor allem drei Dinge: kuratierte Daten, Berechtigungen, die auch für KI-Anwendungen gelten, und eine Oberfläche, die Fachbereiche ohne technische Hürden nutzen können.
AI/BI Dashboards stellen Daten und Kennzahlen direkt für Fachbereiche bereit. Kuratierte Dashboards auf Lakehouse-Daten, mit Unterstützung bei passenden Visualisierungen, mit Cross-Filtering, mit Drill-Downs.
Genie ermöglicht Fragen in natürlicher Sprache: Ein Genie Space ist ein klar abgegrenzter Datenbereich mit geprüften Tabellen, Begriffen und Beispielfragen, in der Fachbereiche Fragen in natürlicher Sprache stellen. Die Berechtigungen kommen aus Unity Catalog, ohne ein zweites Berechtigungsmodell.
Entscheidend für die Akzeptanz im Fachbereich ist, dass Genie dort verfügbar ist, wo Mitarbeitende ohnehin arbeiten: im Slack- oder Teams-Thread, mobil auf dem Smartphone für die schnelle Frage zwischen Terminen. Damit verschiebt sich Self-Service Analytics aus einer separaten Reporting-Oberfläche in den Arbeitsfluss des Fachbereichs.
Der konkrete Vorteil: Beides läuft auf der Plattform, auf der die Daten ohnehin liegen. Es ist nicht zwingend eine zusätzliche KI-Plattform mit eigenem Vertrag nötig. Keine separate Berechtigungsschicht. Die Daten müssen nicht zunächst in ein weiteres System kopiert werden. Datasets lassen sich gleichzeitig in Power BI, Tableau, Looker, Excel und Google Sheets veröffentlichen, ohne ODBC/JDBC-Verbindungen pro Anwendung zu pflegen.
Wie die BI- und Genie-Schicht im Detail aufgebaut wird, ordnen wir im Überblick zu Business Intelligence auf Databricks ein.
ML und GenAI auf Databricks: Von Vector Search bis Model Serving
Im Sinne der Data Intelligence Platform laufen ML und GenAI direkt auf dem Lakehouse, mit derselben Datengrundlage, denselben Berechtigungen aus Unity Catalog und derselben Lineage. MLflow ist direkt eingebunden, mit Model Registry, Experiment Tracking und Model Serving auf nutzungsbasierter Rechenleistung. Vortrainierte Sprachmodelle können genutzt werden, ohne sie selbst zu hosten. Vector Search liefert die Vektorsuche für RAG- und GenAI-Anwendungen direkt auf Delta-Tabellen. Es entfallen zusätzlicher Vector-DB-Vertrag, separate Embedding-Pipelines und ein paralleles Datenmodell zwischen Analytics und KI.
Weitere Funktionen unterstützen den Aufbau von KI-Agenten und die Nutzung von Sprachmodellen in Datenprozessen. Mit AI Functions können Sprachmodelle direkt aus SQL heraus verwendet werden, ohne dafür immer eine eigene Anwendung bauen zu müssen. Agent Bricks ist die Schicht für GenAI-Agenten mit Tool-Zugriff auf die Plattform-Daten.
Auch Bewertung, Monitoring und Kostenanalyse von KI-Anwendungen können innerhalb der Plattform erfolgen: Lakehouse Monitoring für Drift- und Performance-Beobachtung, Evaluation Pipelines für Modell- und Agent-Bewertung, Token- und Cost-Tracking pro Modell und Endpoint. Viele dieser Funktionen stehen direkt innerhalb der Plattform bereit.
Was ML und GenAI im Detail brauchen und welche Architektur-Entscheidungen ein produktiver Betrieb stellt, ordnen wir im Überblick zu Artificial Intelligence auf Databricks ein.
Lakebase: Operative Anwendungen näher an Analytics und KI bringen
Analyse- und operative Anwendungsdaten laufen bisher meist in getrennten Systemen: Databricks für Analytics und KI, Postgres oder MySQL für operative Apps, eine Reverse-ETL-Strecke dazwischen. Lakebase kann diese Trennung für ausgewählte neue Anwendungen reduzieren. Lakebase ist eine verwaltete Postgres-Datenbank für transaktionale Anwendungen auf Basis von Open-Source-PostgreSQL, in die Data Intelligence Platform integriert. Databricks dokumentiert Lakebase mit getrennt skalierbarer Speicherung und Rechenleistung und nativer Synchronisation zu Delta-Tabellen.
Damit entsteht im Mittelstand ein neuer Ansatz: Anwendungen mit verlässlichen Schreib-, Änderungs- und Lesevorgängen können näher an den Analyse- und KI-Daten betrieben werden, mit gemeinsamer Berechtigung und Auditierbarkeit.
Konkrete Use Cases, die dadurch einfacher werden: Ein Dashboard, in dem Nutzer Daten sehen und zusätzlich korrigieren können, eine Anwendung für aktuelle Preisberechnungen, ein Mitarbeiter-Self-Service für Stammdatenpflege, ein Kundenportal, das bestimmte Stammdaten ändern darf. Alle vier laufen heute typisch über eine zweite Postgres-Instanz und eine Reverse-ETL-Strecke. Mit Lakebase und Delta-Sync laufen sie auf derselben Plattform, in derselben Berechtigungs-Topologie.
Wo Lakebase nicht passt: hochfrequente OLTP-Workloads mit Anforderungen jenseits einer managed PostgreSQL-Schicht, regulierte Setups mit eigener Datenbank-Compliance-Anforderung, Bestandsanwendungen, deren Datenbank nicht ohne Migration abgelöst werden kann. Empfehlenswert ist es, neue geeignete Anwendungen auf Lakebase zu starten und bestehende Systeme nur bei klarem Vorteil zu migrieren.
Wie Lakebase architektonisch in die Plattform passt und welche Migrations-Pfade es eröffnet, ordnen wir im Überblick zu Lakebase ein.
Databricks Foundation für den Mittelstand: Schlank starten
Ein sinnvoller Einstieg beginnt mit einer schlanken Foundation mit klarem Umfang, ohne Big-Bang-Rollout. Die erste Ausbaustufe sollte bewusst klein und sauber abgegrenzt bleiben, weil spätere Korrekturen teurer sind als der bewusste Verzicht auf Zusatzfunktionen in Phase 1. Für die ersten Use Cases reichen wenige zentrale Bausteine:
- Trennung zwischen Produktion und Experiment. Drei getrennte Umgebungen (Dev, Test, Prod) schützen die produktive Datenversorgung von Berichten, Apps und KI-Use-Cases vor experimentellen Workloads. Was getestet wird, kann nicht versehentlich live gehen.
- Klare Ownership pro Datenbereich. Jedes Datenprodukt hat einen verantwortlichen Bereich oder Owner. Wer pflegt, wer freigibt, wer haftet bei Fehlern. Schnitt nach Geschäftsbereich oder Umgebung, abhängig vom Organisationsmodell. Das verhindert die typische graue Zone zwischen IT und Fachbereich.
- Pay-per-Use als Compute-Modell. Serverless SQL Warehouses und Serverless Compute laufen nur, wenn sie gebraucht werden. Cluster-Größen und Reserved Capacity werden nicht vorab entschieden. Langfristige Bindungen erst nach Messung der tatsächlichen Nutzung.
- Nachvollziehbare und reproduzierbare Änderungen. Produktive Pipelines, Jobs und Catalog-Strukturen werden über Git und CI/CD verwaltet. Jede Änderung ist dokumentiert, prüfbar und rückrollbar. Das ist wichtig für Audit, Stabilität und Übergabe an neue Mitarbeitende.
- Kosten-Leitplanken als Governance. Wenige klar definierte Compute-Richtlinien (Policies) begrenzen, was jede Person und jedes Team an Rechenleistung anfordern darf. Schutz vor versehentlich teuren Abfragen und unbemerktem Kostenwachstum, ohne jedes Team einzeln freigeben zu müssen.
- Ein erster produktiver Use Case als Startpunkt. Eine vollständige Strecke von der Quelle bis zum nutzbaren Datenprodukt (Bronze-Silber-Gold), ein erstes Dashboard, ein erster Self-Service-Zugang über Genie. Die Plattform liefert messbaren Geschäftsnutzen, bevor weitere Bausteine kommen.
Ein solcher Einstieg lässt sich in überschaubaren Zeiträumen umsetzen: 4 Wochen über ein standardisiertes Einführungsprojekt. Erste produktive Pipelines: ebenfalls 4 Wochen. Erste ML- oder GenAI-Use-Cases: 4 bis 6 Wochen. Entscheidend ist neben der Geschwindigkeit der technischen Einrichtung vor allem die frühe produktive Nutzung. Die Plattform sollte erste messbare Ergebnisse im selben Quartal liefern.
Welche Bausteine die Foundation im Detail enthält, ordnen wir im Überblick zum Databricks-Hub ein.
Databricks, Snowflake oder Microsoft Fabric im Mittelstand
Der Vergleich mit Snowflake oder Microsoft Fabric sollte anhand der eigenen Ausgangslage bewertet werden. Beide sind ebenfalls Plattformansätze, setzen aber unterschiedliche Schwerpunkte. Snowflake kommt stark aus Data Warehousing, Marketplace und Snowpark, deckt Lakehouse und KI inzwischen über Cortex und Iceberg-Support ab. Fabric bündelt OneLake, Warehouse, BI und KI in der Microsoft-Welt und ist insbesondere für Unternehmen mit starkem Fokus auf Microsoft 365, Power BI und die Microsoft-Cloud eine Option.
Die ausführliche Einordnung gehört in eigene Vergleiche. Den herstellerneutralen Überblick über Databricks, Snowflake, Microsoft Fabric und SAP BDC nebeneinander geben wir im Datenplattform-Vergleich: Architektur, AI/ML, Governance, Kostenmodell und Offenheit als Entscheidungs-Frame. Wie Databricks und Snowflake im Mittelstand und für Lakehouse-Workloads gegeneinander stehen, ordnen wir im Überblick zu Databricks gegen Snowflake ein. Wie Databricks und Microsoft Fabric gegeneinander stehen, gerade für Bestandskunden im Microsoft-Stack, ordnen wir im Überblick zu Databricks gegen Fabric ein.
Databricks Foundation in 4 bis 6 Wochen aufsetzen
Für mittelständische Unternehmen, die vor der Plattform-Entscheidung stehen, beginnt das mit der Data & AI Beratung, plattformneutral, mit belastbarer TCO-Rechnung und Business Case gegen den bestehenden Stack. Wenn die Entscheidung für Databricks gefallen ist, setzen wir die produktionsreife Foundation über den Databricks Platform Accelerator als Festpreisprojekt in 4 bis 6 Wochen auf, mit klarem Umfang, planbarem Budget und ersten produktiven Ergebnissen im selben Quartal.
Fazit
Viele mittelständische Datenlandschaften sind über Jahre als Tool-Portfolio gewachsen, ohne bewusste Plattformstrategie. Jedes zusätzliche Tool bringt neue Verträge, Berechtigungen, Updates und Schulungsbedarf. Die direkten Softwarekosten sind im Reporting sichtbar. Der interne Betriebs- und Integrationsaufwand bleibt häufig unterhalb der Wahrnehmungsschwelle und wird oft erst beim nächsten Skalierungsschritt sichtbar.
Eine konsolidierte Plattform löst diese Kostenstruktur nicht automatisch. Sie wirkt aber an drei Stellen gleichzeitig: weniger Lizenz- und Vertragskomplexität, effizientere Verarbeitung und weniger Wartung und vor allem mehr Kapazität für neue Daten- und KI-Anwendungen. Der Wertbeitrag entsteht, wenn diese Kapazität in neue Datenprodukte und KI-Use-Cases fließt: KI-Pilot, neues Datenprodukt, Self-Service für die Fachbereiche. Also dort, wo die Data-&-AI-Organisation vom reinen Kostenblock zum Treiber neuer Anwendungen wird.
Mein Vorschlag: Unternehmen mit mehreren Datenwerkzeugen und konkreten KI-Plänen sollten die Konsolidierungsfrage als Investitionsentscheidung behandeln, jenseits einer reinen Tool-Auswahl. Der Einstieg sollte bewusst klein bleiben: klare Umgebungen, zentrale Governance, nur die zunächst nötigen Compute-Funktionen. Weitere Bausteine erst nach validiertem Business Case ergänzen, zunächst Datenintegration und Analytics, danach Self-Service, ML, GenAI und gegebenenfalls operative Apps. Offene Formate wie Delta und Iceberg sollten von Beginn an eingeplant werden, um Abhängigkeiten zu begrenzen. Eingesparte Betriebszeit sollte in messbare fachliche Use Cases fließen. Neue Tools sollten erst dazukommen, wenn die Plattform den Use Case nachweislich nicht sinnvoll abdeckt.
Steht bei euch die Konsolidierungsfrage an?
Wenn ihr im Mittelstand vor der Konsolidierungsfrage steht oder das Tool-Portfolio spürbar wächst, lohnt sich ein Blick darauf, ob eine gemeinsame Plattform den Betrieb entlastet und Kapazität für neue Daten- und KI-Anwendungen freisetzt.
- ob eine Konsolidierung auf Databricks in eurer Ausgangslage wirtschaftlich trägt und welche Bausteine dabei zuerst infrage kommen
- wo heute unsichtbarer Aufwand für Betrieb, Integration und parallele Governance zwischen euren Tools steckt
- welcher Einstieg zu eurem Stand passt: schlanke Foundation, gezielter Ersatz einzelner Bausteine oder ein größerer Konsolidierungsschritt
FAQ
Entscheidend ist weniger die Unternehmensgröße als die Vielfalt der Workloads. Datenvolumen allein ist kein guter Indikator. Sobald mehr als zwei Schichten betrieben werden (Warehouse plus Pipelines plus erste KI-Anwendung) und der Tool-Stack auf mehrere Komponenten gewachsen ist, lohnt sich eine Konsolidierungsrechnung. Bei reinem BI auf einer Quelle reicht eine schlankere Lösung.
