Warehouse-Native CDP vs. Tealium: Der echte Engineering-Kompromiss

Jeder Plattformverantwortliche, mit dem ich 2026 spreche, steht vor derselben Weggabelung: Soll man den bereits bezahlten Snowflake- oder BigQuery-Footprint zu einer Customer Data Platform ausbauen, oder eine fertige CDP kaufen und einen weiteren Anbieter im Stack akzeptieren? Die Marketing-Abteilung will Segmente sofort live haben. Das Data-Team will eine einzige Source of Truth. Diese beiden Anforderungen stehen meist in direktem Widerspruch – und die Wahl zwischen Warehouse-nativer und eigenständiger CDP-Architektur ist der Ort, an dem dieser Konflikt gelöst wird. In den meisten Unternehmen schlecht.

Das Problem

Früher ging es in der CDP-Debatte darum, welchen eigenständigen Anbieter man wählt. Heute geht es darum, ob man überhaupt einen kauft. Wie MarTech diese Woche darlegte, ist das Warehouse-native-Argument einfach: Das Data Warehouse wird zur einzigen Source of Truth, Identity-Resolution- und Aktivierungstools liegen darüber, und man zahlt nicht mehr dafür, dieselben Kundendaten zwischen drei Systemen hin- und herzuschieben. Das Argument für eigenständige Plattformen wie Tealium und BlueConic ist ebenso einfach: vorgefertigte Integrationen, klare Identity-Frameworks und eine UI, die ein Campaign-Manager nutzen kann, ohne ein Jira-Ticket erstellen zu müssen.

Der Grund, warum das 2026 und nicht schon 2022 eine aktuelle Entscheidung ist, liegt darin, dass die Warehouse-Funktionen aufgeholt haben. Snowflake und BigQuery verarbeiten inzwischen das Datenvolumen, die Parallelität und – mit Einschränkungen – das Latenzprofil, das früher eine zweckgebaute CDP erforderte. Die Reibung hat sich von Speicherung und Modellierung hin zur Aktivierung verlagert: Echtzeit-Event-Firing, Identity Stitching über anonyme und bekannte Nutzer hinweg sowie Audience-Orchestrierung in Ad-Plattformen und E-Mail-Tools.

Die Rahmenbedingung, die sich wirklich verändert hat, ist das Engineering-Angebot. Eine eigenständige CDP verlagert die Kosten auf Lizenzgebühren, die mit MAU und Event-Volumen skalieren. Ein Warehouse-nativer Aufbau verlagert die Kosten auf Engineering-Kapazität und Infrastruktur. In einem Markt, in dem erfahrene Data Engineers nach wie vor teuer und schwer zu finden sind, ist dieser Tausch keineswegs neutral. Die Quelle gibt typische Kostenverhältnisse zwischen den beiden Modellen nicht an – was entscheidend ist, denn das gesamte Build-versus-Buy-Argument hängt davon ab, ob die eigenen jährlichen Engineering-Vollkosten über oder unter dem CDP-Lizenzangebot liegen. Ohne dieses Verhältnis ist jede Aussage, Warehouse-native sei günstiger, nicht widerlegbar.

Wenn der Warehouse-native-Trend real ist, sollten die Verlängerungsraten eigenständiger CDPs bei Enterprise-Kunden (mehr als 5.000 Mitarbeitende) in den nächsten 12 bis 18 Monaten spürbar zurückgehen, während Mid-Market-Verlängerungen stabil bleiben. Das ist die überprüfbare Grenze.

Die Optionen auf dem Tisch

Drei Architekturen, nicht zwei. Der MarTech-Artikel benennt das Hybridmodell explizit – und das ist das Modell, bei dem die meisten Teams letztlich landen werden.

Option 1: Eigenständige CDP (Tealium, BlueConic). Schnellere Time-to-Value, vorgefertigte Integrationen, marketerfreundliche Oberfläche. Der Kompromiss besteht darin, dass Identity Graph und Datenmodell des Anbieters klar vorgegeben sind. Man passt sich ihrem Schema an, nicht umgekehrt. Für einen mittelgroßen Einzelhändler mit einem relativ standardisierten Aktivierungs-Stack aus Web, E-Mail und Paid Social ist diese Meinungsstärke ein Vorteil, kein Nachteil. Man kauft ein funktionierendes System, anstatt es zu bauen. Laut der Quelle ist dies das Segment, in dem die Kompromisse als akzeptabel beschrieben werden.

Option 2: Warehouse-native auf Snowflake oder BigQuery. Das Warehouse ist die Source of Truth. Reverse-ETL-Tools und Aktivierungsschichten liegen darüber. Laut der Quelle reduziert dieser Ansatz Datenduplizierung, minimiert Datenbewegungen zwischen Systemen und senkt Latenz- und Governance-Risiken. Er erfordert jedoch mehr Engineering-Aufwand und längere Implementierungszeiträume. Echtzeit-Aktivierung, Identity Stitching und Audience-Orchestrierung müssen möglicherweise gebaut oder integriert werden, anstatt sie sofort nutzen zu können. Wenn man ein komplexes Daten-Ökosystem und individuelle Anwendungsfälle hat, die sich nicht sauber auf vorgefertigte CDP-Funktionen abbilden lassen, ist dies der richtige Weg.

Option 3: Hybrid (Warehouse-Fundament plus CDP-ähnliche Aktivierung). Das Warehouse hält den kanonischen Kundendatensatz. Ein schlankeres Aktivierungstool (Composable CDP, Reverse-ETL oder ein dünneres eigenständiges Deployment) übernimmt Segmentierung und Outbound. Identity Resolution kann in beiden Schichten liegen – genau dort scheitern die meisten Hybrid-Implementierungen. Die Snowflake-Dokumentation und dbt's Semantic Layer haben dieses Muster praktischer gemacht als noch vor zwei Jahren, weil Identity- und Audience-Definitionen als Code versioniert und getestet werden können.

Der ehrliche Vergleich: Eine eigenständige CDP bringt einen in Wochen live mit Marketer-Autonomie. Warehouse-native bietet Flexibilität und Kontrolle auf Kosten eines mehrmonatigen Aufbaus. Hybrid vereint das Beste aus beiden Welten – plus eine neue Fehlerquelle, bei der niemand die Grenze zwischen Warehouse und Aktivierungstool verantwortet.

Was Data-Teams wirklich tun sollten

Meine Einschätzung: Die Entscheidung hängt fast ausschließlich von zwei Variablen ab, und keine davon lautet „welche Architektur ist besser".

Die erste Variable ist die Data-Engineering-Kapazität. Wer weniger als drei Vollzeit-Data-Engineers hat, die glaubwürdig eine Customer-Data-Pipeline betreuen können, für den ist Warehouse-native keine echte Option – unabhängig davon, wie günstig die Infrastruktur auf dem Papier aussieht. Die Quelle macht deutlich, dass Warehouse-native mehr Engineering und längere Zeiträume erfordert. Das ist kein Marketingproblem, das sich durch den Einsatz eines CDP-Beraters lösen lässt. Es ist ein dauerhafter Betriebsaufwand.

Die zweite Variable ist die Komplexität der Aktivierungsfläche. Wer Audiences an vier Ziele ausliefert und dessen Identity Graph aus „E-Mail plus Geräte-ID" besteht, für den erledigt eine eigenständige CDP ab Tag eins 90 Prozent des Bedarfs. Wer an zwanzig Ziele ausliefert, serverseitiges Enrichment betreibt und Identitäten über ein Loyalty-Programm, eine Mobile-App und ein Offline-POS-System hinweg abgleichen muss, wird innerhalb von sechs Monaten mit dem starren Framework eines eigenständigen Anbieters in Konflikt geraten.

Für mittelgroße Organisationen – jenes Segment, in dem die Quelle die Kompromisse eigenständiger CDPs als akzeptabel einstuft – lautet meine Empfehlung: Die eigenständige CDP kaufen, aber alles zuerst durch das Warehouse leiten. Das CDP darf nicht zu einer zweiten Source of Truth werden. Das Warehouse bleibt kanonisch, das CDP wird zu einer Aktivierungsschicht mit einer UI. Wenn man darüber hinauswächst, ist der Migrationspfad klar, weil die Daten nie beim Anbieter gefangen waren.

Fallstricke und Sonderfälle

Das Kostenverschiebungsargument ist das, das ich am kritischsten hinterfragen würde. Die Quelle stellt fest, dass Warehouse-native-Ansätze Ausgaben von Lizenzgebühren auf Infrastruktur- und Engineering-Ressourcen verlagern können. Was sie nicht quantifiziert – und was die meisten internen Business Cases ebenfalls nicht quantifizieren –, sind die Folgekosten dieses Engineering-Teams nach dem Go-live. Eine CDP-Lizenz ist eine bekannte Zahl zum Verlängerungstermin. Eine interne Customer-Data-Platform auf Snowflake hat kein Verlängerungsdatum und keine feste Personalstärke – das ist in guten Zeiten ein Vorteil und ein Problem in dem Moment, in dem Finance 15 Prozent Einsparungen fordert.

Echtzeit-Aktivierung ist die andere Stolperfalle. Warehouses nähern sich Real-time an, aber „nahezu-echtzeit-analytische Abfrage" und „eine personalisierte E-Mail innerhalb von 200 Millisekunden nach einem Cart-Event senden" sind nicht dieselbe Workload. Wenn Anwendungsfälle Letzteres erfordern, muss man eine Streaming-Schicht (Kafka, eine CEP-Engine oder ein zweckgebautes Aktivierungstool) auf dem Warehouse integrieren einplanen. Das ist Engineering-Aufwand, den das Warehouse-native-Pitch gerne übersieht.

Unbekanntes, das erwähnt werden sollte: Die Quelle gibt nicht an, wie die Qualität des Identity Stitching zwischen eigenständigen CDPs und Warehouse-nativen Builds im Maßstab vergleicht. Die Grenze, die ich setzen würde, lautet: Wenn ein Warehouse-natives Team nach sechs Monaten Aufbau nicht innerhalb von 5 Prozentpunkten die Match-Rate eines eigenständigen Anbieters erreicht, scheitert der Build und sollte neu bewertet werden.

Die wichtigsten Erkenntnisse

• Warehouse-native CDPs reduzieren Datenduplizierung und senken Latenz- sowie Governance-Risiken, erfordern aber mehr Engineering und längere Implementierungszeiträume als Tealium oder BlueConic.
• Das Kostenargument ist ein Tausch, keine Ersparnis: Lizenzgebühren werden zu Infrastruktur plus Engineering-Kapazität. Die Vollkosten pro Engineer durchrechnen, bevor ein Gewinner erklärt wird.
• Für mittelgroße Organisationen bewertet die Quelle die Kompromisse eigenständiger CDPs als akzeptabel. Die fertige Plattform kaufen, aber das Warehouse als kanonische Source behalten.
• Hybrid ist das realistische Endziel für die meisten Teams. Das Risiko: Niemand verantwortet die Grenze zwischen Warehouse und Aktivierungsschicht.
• Überprüfbare Prognose: Enterprise-Verlängerungen eigenständiger CDPs sollten in den nächsten 12 bis 18 Monaten nachlassen, während Mid-Market-Verlängerungen stabil bleiben. Wenn nicht, ist das Warehouse-native-Narrativ lauter als die Migrationsdaten belegen.