Ihr Data Warehouse ist kein CDP: Die 50-fache Compute-Rechnung, die niemand kommen sah

Stellen Sie sich Ihr Data Warehouse wie das zentrale Reservoir hinter einer Stadt vor: riesig, gut kontrolliert und ideal, um die Versorgung zuverlässig zu halten. Ihr CDP ist das Druckwassernetz unter den Straßen. Beides hängt zusammen und ist miteinander verbunden – aber wenn Sie versuchen, das Reservoir selbst in die Rohrleitungen jeder Küche zu verwandeln, platzen die Rohre, und die Wasserrechnung wird zum Problem einer anderen Abteilung. Genau dieses Gespräch führen viele Plattformverantwortliche gerade, und die Zahlen beginnen sich zu konkretisieren.

Die zentrale Zahl: Der Wechsel von täglichen zu stündlichen Audience-Refreshes kann die Warehouse-Compute-Kosten um das 25-fache in die Höhe treiben – und Near-Real-Time bringt einen Faktor von 50x oder mehr. Diese Kosten erscheinen nicht auf der CDP-Rechnung. Sie tauchen auf der Warehouse-Rechnung auf – einem anderen Team, einem anderen Budget und meistens einem anderen Streitgespräch.

Die Zahlen

Der Faktor 25x und 50x ist der Teil, bei dem jeder CTO aufhorchen sollte. Wie Oracle Blogs am 30. April 2026 darlegte, beschreiben diese Multiplikatoren, was passiert, wenn eine Organisation versucht, ein Zero-Copy- oder Composable CDP als operative Schicht für Echtzeit-Marketing zu nutzen. Täglich zu stündlich ist 25x. Stündlich zu Near-Real-Time ist 50x oder mehr. Und entscheidend: Dieser Compute-Aufwand schlägt auf den Warehouse-Posten durch, nicht auf die Rechnung des CDP-Anbieters.

Wer einem CFO schon einmal eine unerwartete Snowflake- oder BigQuery-Rechnung erklären musste, weiß, wie dieses Gespräch verläuft. Das Marketing-Team wollte schnellere Trigger. Das Data-Team baute häufigere Refreshes ein. Das Warehouse startete mehr virtuelle Warehouses, mehr Concurrency, mehr Autosuspend-Zyklen, die nie zum Suspendieren kamen. Sechs Monate später fragt die Finanzabteilung, warum die Analytics-Kosten sich verdoppelt haben, obwohl „keine neuen Dashboards hinzugekommen sind".

Der Beitrag, verfasst von Jake Spencer, Senior Outbound Product Manager bei Oracle Fusion Marketing, beschreibt die vergangenen 18 Monate in MarTech und CX als eine Phase erheblicher Veränderungen, in der KI-Agenten-Strategien, Kostenoptimierungsinitiativen und alte Fragen rund um Dateneigentümerschaft aufeinanderprallen. Zwei Technologien stehen dabei immer wieder im Mittelpunkt: der Data Lake bzw. das Warehouse und das CDP. Oracle selbst, so der Artikel, integriert die Oracle Unity Data Platform mit dem Oracle Autonomous AI Lakehouse, um unternehmensweite First-Party-Daten zu vereinheitlichen, zu verwalten und zu aktivieren – der Anbieter behauptet also keineswegs, das Warehouse sei irrelevant. Ganz im Gegenteil.

Was die Zahlen wirklich zeigen, ist dass die Unit Economics des „einfach das Warehouse abfragen"-Ansatzes nichtlinear sind. Latenzanforderungen verdichten sich, und Compute-Kosten steigen auf einer Kurve, die einer Exponentialfunktion nahekommt. Wer die Snowflake-Dokumentation zu Warehouse-Sizing und Concurrency Scaling genau gelesen hat, wird davon theoretisch nicht überrascht sein. In der Praxis kalkulieren die meisten Teams die Architektur auf Basis einer täglichen Refresh-Annahme – und lassen dann still und leise zu, dass Produktmanager zunächst stündliche, dann Echtzeit-Refreshes fordern, ohne die Zahlen je neu zu berechnen.

Was wirklich neu ist

Die Debatte um Composable CDPs wird seit zwei bis drei Jahren geführt. Was in diesem Zyklus wirklich anders ist, ist der Aufstieg von eingebetteten KI-Agenten in Marketing- und Vertriebs-Workflows und das Latenzprofil, das diese erfordern. Der Artikel ist eindeutig: Diese Agenten benötigen Sub-Sekunden-Zugriff auf vorberechnete Profile. Das ist kein „Warehouse tunen"-Problem. Das ist ein „Sie brauchen ein anderes System"-Problem.

Der Kern der Sache: Analytische Abfragen und operative Lookups sind unterschiedliche Arten von Arbeit. Ein Warehouse – selbst ein schnelles – ist dafür optimiert, viele Zeilen zu scannen, um eine Frage zu beantworten. Eine Aktivierungsschicht muss ein einzelnes, vollständig aufgelöstes Profil in einstelliger Millisekunden-Zeit abrufen, während zehntausend andere Agenten gleichzeitig dasselbe tun. Das lässt sich auf einem Warehouse aufbauen – aber Sie bezahlen doppelt: einmal für Compute, einmal für die Engineering-Stunden, um es am Laufen zu halten.

Der B2B-Aspekt ist ebenfalls schärfer als zuvor. Der Artikel weist auf die offensichtliche, aber häufig ignorierte Wahrheit hin, dass im B2B der „Kunde" eine Gruppe ist, kein Individuum. Das bedeutet Account-Hierarchien, Buying-Group-Mapping, Multi-Contact-Engagement-Tracking sowie die Abstimmung von Vertrieb und Marketing – alles Dinge, die persistente Datenstrukturen erfordern, keine Ad-hoc-Joins gegen Rohtabellen. Wer schon einmal versucht hat, eine Buying Group in reinem SQL auf einer Bronze-Schicht zu modellieren, weiß: Genau hier bricht das Ganze zusammen.

Das andere wirklich Neue ist die explizite Anerkennung, dass es vier Integrationsmethoden gibt, nicht eine. Zero-Copy oder Federated Query. Batch-Ingestion. Echtzeit-Streaming. Vorberechnete Profil-Persistenz. Das Argument lautet nicht „Wählen Sie die richtige". Es lautet: „Sie brauchen alle vier, abgestimmt auf spezifische Anwendungsfälle". Batch-Ingestion ist geeignet, wenn Aktualität in Stunden gemessen wird. Echtzeit-Streaming ist für Sub-Sekunden-Anwendungsfälle unverzichtbar. Wer ein einzelnes Muster als vollständige CDP-Strategie behandelt, optimiert für den Datenspeicherort statt für Geschäftsergebnisse.

Was für Data Teams bereits einkalkuliert ist

Die meisten erfahrenen Data Engineers wissen bereits, dass Zero-Copy ideal für Governance und Compliance ist. Das ist bekannt. Daten im Warehouse zu belassen bedeutet, dass bestehende Kontrollen (Zugang, Verschlüsselung, Datenresidenz) automatisch greifen und Diskussionen darüber enden, welches System den maßgeblichen Kundendatensatz hält. Weniger Redundanz, geringere Speicherkosten und die Möglichkeit, kuratierte Daten zu aktivieren, ohne sie zu replizieren: alles real, alles willkommen.

Was aus meiner Erfahrung jedoch nicht einkalkuliert wird, ist die Lücke zwischen „wir können das Warehouse von der Aktivierungsschicht aus abfragen" und „wir sollten das Warehouse von der Aktivierungsschicht aus abfragen – jedes Mal, für jede Entscheidung, in der Produktion". Der unspektakuläre Teil, den niemand modellieren möchte, ist Concurrency. Ein einzelner Pricing-Page-Trigger ist günstig. Zehntausend gleichzeitige Trigger während einer Black-Friday-Kampagne sind ein völlig anderes Kaliber – und das Autoscaling-Verhalten des Warehouse unter dieser Last ist der Ort, an dem Budgets sterben.

Identity Resolution im großen Maßstab ist der andere unterschätzte Kostenfaktor. Identitäten über Geräte und Kanäle hinweg per Warehouse-Abfrage on demand zusammenzuführen, ist rechenintensiv auf eine Weise, die sich mit jeder zusätzlichen Quelle potenziert. Voraufgelöste Identity Graphs in einem zweckgebundenen Speicher sind pro Lookup dramatisch günstiger, und der Artikel bringt das klar auf den Punkt. Teams, die dbt nutzen, um Auflösungslogik auf einem Zeitplan in breite Profiltabellen zu materialisieren, sind bereits auf halbem Weg zur richtigen Antwort – sie brauchen nur noch einen schnellen Speicherort, von dem aus diese Tabellen zum Aktivierungszeitpunkt ausgeliefert werden können.

Die Gegenperspektive

Nun die andere Seite. Es gibt ein echtes Argument dafür, dass für einen bedeutenden Teil der Organisationen der reine Zero-Copy-Ansatz ausreicht und die 50x-Compute-Warnung eine anbietergefärbte Panikmache ist. Wenn Ihre Aktivierungsszenarien hauptsächlich aus stündlichen E-Mail-Versendungen, wöchentlichen Lookalike-Audience-Builds und quartalsweisen Kampagnenanalysen bestehen, benötigen Sie keine vorberechneten Sub-Sekunden-Profile. Sie brauchen ein sauberes Warehouse, gut modellierte Marts und eine schlanke Aktivierungsschicht, die Segmente planmäßig abruft.

Für diese Teams ist ein separates CDP mit eigenem Profil-Store eine Verdopplung zugunsten eines Architekturdiagramms. Die Warehouse-Compute-Rechnung bei stündlichem Refresh, auf einem angemessen dimensionierten Cluster mit vernünftigem Caching, ist in der Praxis nicht bei jedem Workload 25x höher als täglich. Der Faktor 25x gilt für die Worst-Case-Interpretation. Ein Team, das Materialisierung, inkrementelle Modelle und Result-Caching beherrscht, kann diese Kurve deutlich abflachen.

Die ehrliche Einschätzung ist, dass die Antwort fast vollständig von den Aktivierungsszenarien abhängt. Genau deshalb ist die Empfehlung des Artikels, fünf bis zehn konkrete Aktivierungsszenarien zu definieren, bevor man eine CDP-Architektur evaluiert, der nützlichste Satz darin. Echtzeit-Trigger, Buying-Group-Engagement, prädiktives Lead-Scoring, Kampagnen-Orchestrierung, Vertriebs-Alerts: Schreiben Sie diese auf, ordnen Sie jedem eine Latenzanforderung und eine Volumenschätzung zu – und die Architektur entwirft sich weitgehend von selbst.

Wichtigste Erkenntnisse

• Tägliche auf stündliche Audience-Refreshes umzustellen kann die Warehouse-Compute-Kosten um das 25-fache steigern; Near-Real-Time kann auf das 50-fache oder mehr treiben – und die Rechnung landet beim Warehouse-Posten, nicht bei der CDP-Rechnung.
• Zero-Copy-Architekturen punkten wirklich bei Governance, Compliance, reduzierter Redundanz und der Aktivierung bestehender Investitionen – versagen jedoch bei Sub-Sekunden-KI-Agenten-Workloads und Identity Resolution im großen Maßstab.
• Es gibt vier Integrationsmethoden, die man kennen sollte (Zero-Copy oder Federated Query, Batch-Ingestion, Echtzeit-Streaming, vorberechnete Profil-Persistenz), und ausgereifte Architekturen nutzen alle vier, abgestimmt auf Anwendungsfälle.
• B2B-Aktivierung benötigt persistente Strukturen für Account-Hierarchien, Buying Groups und Multi-Contact-Engagement – keine Ad-hoc-Abfragen gegen Rohtabellen.
• Definieren Sie fünf bis zehn Aktivierungsszenarien mit expliziten Latenz- und Volumenanforderungen, bevor Sie eine Architektur wählen; das richtige Muster ergibt sich aus den Anforderungen, nicht umgekehrt.

Zurück zum Reservoir. Niemand mit Verstand bestreitet, dass man das Reservoir braucht. Die Frage ist, ob man auch das Druckwassernetz braucht – und die Antwort für die meisten Enterprise-Kundendatenstrategien im Jahr 2026 lautet: ja, man braucht es. Warehouse und CDP konkurrieren nicht um dieselbe Aufgabe. Sie sind zwei Teile desselben Wassersystems, und die Engineering-Entscheidung besteht darin, welches Rohr welche Last trägt. Wer das falsch einschätzt, bekommt die Rechnung dort präsentiert, wo niemand hingeschaut hat.