HPs 32 % Cloud-Einsparung verändert die SQL-ETL-Kaufentscheidung

Jeder Plattformverantwortliche mit einem Budgetzyklus 2026 starrt auf dieselbe Kostenzeile: einen Data-Warehouse-Vertrag, eine Transformations-Framework-Lizenz, einen Orchestrator und einen separaten Observability-Stack – alle verlängern sich zu unterschiedlichen Zeitpunkten. Die HP-Serverless-Zahlen, die diese Woche kursieren, sind für sich genommen interessant, aber die eigentliche Geschichte ist, was sie mit der Build-vs-Buy-Kalkulation für SQL ETL in den nächsten zwei Quartalen anstellt. Teams, die 2023 Drei-Anbieter-Stacks unterzeichnet haben, werden bald herausfinden, ob ihre Architekturentscheidungen strategisch oder nur bequem waren.

Das Problem

SQL ETL ist in den meisten Unternehmen kein einzelnes System. Es sind vier. Wie Databricks darlegte, verteilt der typische Stack die Ausführung auf ein Data Warehouse, die Modellierung auf ein Transformations-Framework, die Planung auf einen Orchestrator und Lineage, Monitoring sowie Qualität auf noch weitere Systeme. Jede Schicht wurde angeschafft, um ein reales Problem zu lösen. Zusammen erzeugen sie operativen Mehraufwand, der mit jeder hinzugefügten Pipeline wächst.

Der Stellenmarkt verschärft das Problem noch. Der Analytics Engineer, der dbt in- und auswendig kennt, ist nicht dieselbe Person wie der Warehouse Engineer, der Stored Procedures schreibt – und der wiederum nicht dieselbe Person wie der Analyst, der No-Code-Transformationen erstellt. Jeder fragmentierte Stack braucht am Ende mindestens einen Spezialisten pro Schicht plus ein Plattformteam, das alles zusammenhält. Das sind drei bis fünf FTEs an Koordinationskosten, bevor auch nur eine einzige Pipeline ausgeliefert wird. Series-B-Fintechs und Mid-Market-iGaming-Betreiber spüren das besonders, weil sie sich keine 12-köpfige Data-Plattform-Organisation leisten können, ihre regulatorische Exposition (SOX, MGA, MiCA-Reporting) aber dieselben Lineage- und Qualitätsgarantien wie eine öffentliche Bank erfordert.

Die Folgen sind vorhersehbar. Pipelines schlagen in mehreren Systemen fehl. Abhängigkeiten sind schwer nachzuverfolgen. Die Störungsbehebung wird zur Slack-Schnitzeljagd über Tools hinweg, die keinen gemeinsamen Kontext teilen. Fragmentiertes SQL ETL ist der Treiber versteckter Kosten, fragiler Pipelines und langsamer Störungsbehebung – das ist keine Marketing-Sprache, sondern eine genaue Beschreibung dessen, was im Monat 18 eines Multi-Vendor-Data-Stacks passiert, wenn Ihr erster leitender Data Engineer das Unternehmen verlässt und das institutionelle Wissen mitnimmt.

Die entscheidende Veränderung der letzten 18 Monate: Serverlose und deklarative Ausführung haben endlich mit der Warehouse-Erfahrung aufgeholt. Das Kostenargument für „einfach Snowflake plus dbt plus Airflow plus Monte Carlo nutzen" war früher vertretbar. Es wird schwieriger zu rechtfertigen, wenn eine Einzelplattform-Alternative HP-ähnliche Zahlen liefert.

Die verfügbaren Optionen

Für einen CTO, der in den nächsten 90 Tagen eine sechsstellige bis siebenstellige Entscheidung trifft, gibt es realistisch vier Wege.

Weg eins: fragmentiert bleiben, jede Schicht optimieren. Snowflake oder BigQuery als Warehouse behalten, dbt für Transformationen, Airflow oder Dagster für Orchestrierung und Observability ergänzen. Hier befinden sich die meisten Series-B-Teams bereits. Der Vorteil ist Best-of-Breed auf jeder Ebene und ein breiter Einstellungspool. Die Kosten sind die Integrationssteuer – auf dem Bestellschein unsichtbar und im On-Call-Rota sehr sichtbar.

Weg zwei: Konsolidierung auf einer Lakehouse-Plattform. Ausführung, Orchestrierung, Lineage und Qualität auf ein einziges System verlagern. Databricks unterstützt jetzt das direkte Ausführen bestehender dbt-Workflows auf der Plattform, Lift-and-Shift von Warehouse-SQL in Skripte und Stored Procedures, Materialized Views zur BI-Beschleunigung, deklarative Pipelines für den Produktionseinsatz und No-Code-Tools für Analysten. Das Versprechen: All das teilt sich eine Ausführungs-Engine, ein Governance-Modell und eine Observability-Schicht. HPs 32 % Cloud-Einsparung und 36 % Laufzeitreduzierung kamen von diesem Weg – konkret der serverlosen Variante.

Weg drei: Konsolidierung auf der erweiterten Oberfläche des Warehouse-Anbieters. Snowflake drängt mit Snowpark, Dynamic Tables und nativer Orchestrierung in dieselbe Richtung. Der Kompromiss ist dem Geist nach ähnlich, aber mit anderem Lock-in-Profil. Man setzt auf einen Anbieter, dessen Preismodell an Compute-Einheiten statt an Node-Stunden gekoppelt ist.

Weg vier: Open-Table-Format DIY. Iceberg oder Delta auf Objektspeicher, mit ClickHouse oder Trino für Abfragen, dbt für Modellierung und einem Orchestrator nach Wahl. Maximale Flexibilität, maximaler Plattformteam-Headcount. Realistisch nur für Teams mit acht oder mehr Senior-Data-Engineers und einer starken Plattformkultur.

Eine ehrliche Einschätzung: Weg zwei und drei nähern sich aus entgegengesetzten Richtungen demselben Architekturmuster an. Weg eins ist der Status quo, den die HP-ähnlichen Zahlen für kostenbewusste Teams stillschweigend unhaltbar machen. Weg vier ist für eine kleine Anzahl von Organisationen richtig und für den Rest ein Prestigeprojekt.

Was Data-Teams wirklich tun sollten

Meine Einschätzung: Wenn Sie weniger als 50 Data Practitioners haben und Ihr SQL ETL über mehr als drei Anbieter verteilt ist, ist der nächste Verlängerungszyklus der Moment zur Konsolidierung. Nicht weil Konsolidierung tugendhaft ist, sondern weil die Integrationssteuer für die meisten Workloads unter einigen Petabyte inzwischen größer ist als die Best-of-Breed-Prämie.

Die Frage, die Ihr CFO diese Woche dem Head of Platform stellen sollte, ist nicht „sollen wir zu serverlos wechseln", sondern „welcher Prozentsatz unserer aktuellen Dateninfrastrukturausgaben fließt in Koordinationsaufwand statt in Compute?" Wenn die Antwort mehr als 30 % beträgt – was sie meist ist, sobald man Engineering-Zeit für Glue-Code und Incident Response einrechnet – haben Sie ein Unit-Economics-Problem, das sich als Architekturproblem tarnt.

In der Praxis bewährt sich folgende Migrationsreihenfolge: Beginnen Sie mit den kostenintensivsten, am wenigsten komplexen Pipelines (typischerweise BI-orientierte Aggregationen, die von Materialized Views profitieren), migrieren Sie diese zuerst, messen Sie Laufzeit und Kosten ehrlich gegen den bestehenden Stack und erweitern Sie dann. Migrieren Sie das verwirrende Stored-Procedure-Geflecht nicht zuerst. Dort sterben Konsolidierungsprojekte. Das HP-Ergebnis kam aus der Umstellung bestehender Pipelines auf serverlose Compute, nicht aus einem Greenfield-Neuaufbau – und das ist das realistische Playbook für die meisten Teams.

Auf eines sollte man bestehen: Lineage und Governance müssen automatisch als Teil der Pipeline-Ausführung erfasst werden, nicht nachträglich angeflanscht. Wenn Ihre Evaluierungskriterien nicht die Frage beinhalten „Was sieht der Datenschutzbeauftragte, wenn ein Regulierer Lineage auf Spaltenebene für Kunden-Finanzdaten anfordert", evaluieren Sie ein Werkzeug, keine Plattform.

Fallstricke und Sonderfälle

Bei Konsolidierungsprojekten tauchen drei Fehlermuster immer wieder auf.

Erstens, die Persona-Falle. Korrekt werden drei SQL-Praktiker-Personas identifiziert: Analytics Engineers, Data Warehouse Engineers und Analysten. Eine Plattform, die alle drei auf dem Papier unterstützt, aber nur für eine Gruppe eine wirklich gute Erfahrung bietet, drängt die anderen Personas still und leise zu Schatten-Tools zurück. Evaluieren Sie den SQL Editor für Stored Procedures, den deklarativen Pipeline-Editor und den Lakeflow Designer mit tatsächlichen Vertretern jeder Gruppe. Lassen Sie die Analytics Engineers den Bake-off nicht allein durchführen.

Zweitens, die serverlose Kostenüberraschung. Serverlose Kostenstrukturen sind ausgezeichnet für stoßartige Workloads und können bei gleichmäßigen, vorhersehbaren Jobs schlechter als bereitgestelltes Compute sein. HPs 32 % Ersparnis ist eine reale Zahl für HPs Workload-Mix. Ihrer kann abweichen. Führen Sie vor einer Verpflichtung eine zweiwöchige Shadow-Workload-Auswertung durch.

Drittens, die dbt-Portabilitätsfrage. Ja, dbt-Workflows laufen auf der Plattform. Nein, das bedeutet nicht, dass jedes dbt-Makro und jeder Adapter identisch funktioniert. Prüfen Sie Ihr dbt-Projekt auf warehouse-spezifisches SQL, bevor Sie von einer aufwandsfreien Migration ausgehen.

Und ein Hinweis für den Datenschutzbeauftragten: Automatisch erfasste Lineage ist nur nützlich, wenn sie in einem Format exportierbar ist, das Ihre Auditoren kennen. Prüfen Sie den Exportpfad, nicht nur die Benutzeroberfläche.

Die wichtigsten Erkenntnisse

• HPs 32 % Cloud-Einsparung und 36 % Laufzeitreduzierung auf serverlos stellt die Unit-Economics-Diskussion für jedes Team neu auf, das heute Multi-Vendor-SQL-ETL betreibt.
• Fragmentierung ist zuerst ein Einstellungsproblem, bevor es ein Tooling-Problem ist. Jede Schicht in Ihrem Stack fügt eine Spezialisierungsanforderung und eine Koordinationssteuer hinzu, die mit der Pipeline-Anzahl skaliert.
• Konsolidierungswege konvergieren. Lakehouse-Plattformen und Warehouse-native Erweiterungen streben aus entgegengesetzten Richtungen auf dasselbe Ziel zu – mit unterschiedlichen Lock-in-Profilen.
• Die Migrationsreihenfolge ist wichtiger als die Anbieterauswahl. Beginnen Sie mit kostenintensiven, wenig komplexen Pipelines und messen Sie ehrlich, bevor Sie das Stored-Procedure-Geflecht angehen.
• Teams, die 2026 SQL-ETL-Plattformen evaluieren, sollten fragen: Welcher Anteil unserer aktuellen Datenausgaben ist Koordinationsaufwand, und was sieht unser Datenschutzbeauftragter, wenn ein Regulierer nach Lineage fragt?