Palantir Foundry vs Snowflake: Das echte Kaufsignal für CTOs

Die Frage, die jeder Head of Platform beim Anblick eines Palantir-Foundry-Angebots seinem CFO diese Woche stellen sollte, ist nicht, ob die Pipeline-Demos schneller sind. Es ist die Frage, ob das Unternehmen eine kalkulierte Databricks- oder Snowflake-Alternative in der Einkaufsmappe liegen hat. Ohne diese Alternative kann die Jahresrechnung zwei- bis dreimal so hoch ausfallen wie bei einem vergleichbaren Unternehmen für dasselbe Deployment.

Der Erfahrungsbericht eines Data Engineers, der seine Karriere auf AWS, Azure und Snowflake aufgebaut hat und anschließend ein Foundry-Bootcamp absolvierte, ist genau deshalb lesenswert, weil er die zwei Variablen isoliert, die die Kaufentscheidung tatsächlich steuern: wie viele Nutzer im Unternehmen SQL schreiben können und mit wie viel Verhandlungsmasse man in das Gespräch geht. Alles andere ist Lärm.

Die wichtigsten Details

In einem Meinungsbeitrag für InfoWorld beschreibt Sashank Siwakoti ein Palantir-Foundry-Trainings-Bootcamp, in dem der Aufbau einer Pipeline, die Daten aus mehreren Quellen erfasste, Transformationen anwendete und Ergebnisse für Business-Nutzer bereitstellte, nur wenige Stunden dauerte. Sein Vergleichspunkt: Auf einem Standard-AWS- oder Snowflake-Stack mit dbt und einer Orchestrierungsschicht beansprucht dasselbe Setup für ein kleines Team typischerweise einen vollständigen Sprint. Er schreibt Foundrys Pipeline Builder die Fähigkeit zu, den Koordinationsaufwand zwischen Tools zu reduzieren, und beschreibt das Ontologie-Modell – eine gemeinsame semantische Schicht – als Werkzeug, das Self-Service-Zugang zur Standardoption macht, statt ihn als aufwändiges Engineering-Projekt zu behandeln.

Bei der Preisstruktur wird die Führungsentscheidung konkreter. Palantir veröffentlicht keine Listenpreise. Foundry verwendet ein kernbasiertes Lizenzmodell, bei dem die Zahlung an die zugewiesene Rechenkapazität (Server-Cores) gebunden ist und nicht an die Anzahl der Nutzer. Kernbasierte Lizenzen beginnen bei etwa 66.000 Pfund pro Server-Core pro Jahr ohne zusätzliche Nutzergebühren. Lösungsbasierte Nutzungslizenzen, die Implementierung und Support bündeln, beginnen auf Einstiegsniveau bei 250.000 Pfund und steigen je nach Datenkomplexität, Nutzerbasis und Betriebsumfang erheblich. Alles wird verhandelt.

Siwakoti zitiert eine Beschaffungsanalyse von Redress Compliance zu Palantir-Foundry-Verhandlungen aus den Jahren 2024 und 2025. Diese ergab, dass die jährlichen Plattformgebühren für vergleichbare mittelgroße Deployments allein aufgrund der Verhandlungsposition um den Faktor zwei bis drei variierten. Sein Fazit: Die wichtigste Verhandlungsmasse besteht darin, eine glaubwürdige, kalkulierte Alternative – typischerweise Databricks oder Snowflake – vorweisen zu können. Unternehmen ohne eine solche Alternative zahlen für dasselbe Deployment deutlich mehr. Er weist auch darauf hin, dass der Großteil der im Umlauf befindlichen Foundry-Inhalte entweder Palantir-Marketing oder von tief eingebetteten Praktikern verfasst ist – weshalb ein Bericht mit frischem Blick von Bedeutung ist.

Warum das für Daten-Teams relevant ist

Die zentrale Erkenntnis in Siwakotis Bericht dreht sich gar nicht um Foundry. Es geht darum, wie Plattformentscheidungen bewertet werden. Die meisten CTOs benchmarken Datenplattformen anhand von Pipeline-Performance, Warehouse-Kosten pro Abfrage und der Kompatibilität mit bestehenden CI/CD-Prozessen. Das sind ingenieurzentrierte Metriken. Siwakoti argumentiert, dass das richtige Bewertungskriterium der Anteil der Personen ist, die mit Daten arbeiten müssen und tatsächlich SQL schreiben können. In Unternehmen, in denen mehr als die Hälfte der Business-Analysten und operativen Nutzer keinen Code schreiben kann, wird der Engineering-Aufwand für den Aufbau von Self-Service-Zugang auf einem traditionellen Stack zu einer wiederkehrenden, sich kumulierenden Kostenstelle.

Das lässt sich als Einstellungsfrage reformulieren. Ein Snowflake-plus-dbt-Stack setzt voraus, dass man ein Data-Engineering-Team aufbauen und halten kann, das kontinuierlich semantische Schichten, Exposure-Spezifikationen und BI-Abstraktionen für nicht-technische Nutzer erstellt und pflegt. In einem engen Einstellungsmarkt ist das eine starke Annahme. Wenn das Verhältnis von Analysten zu Engineers 20:1 beträgt und weiter steigt, kostet jedes neue Self-Service-Dashboard auf einem traditionellen Stack einen Senior Engineer einen halben Tag. Dieser Aufwand summiert sich.

Foundrys Ontologie-Modell verändert die Arbeitsgleichung, indem es die semantische Schicht als Plattform-Primitiv in den Vordergrund stellt, statt sie vom Team zusammenbauen zu lassen. Den Trade-off benennt Siwakoti ehrlich: Ein starkes, gut ausgestattetes Data-Engineering-Team könnte in der Zeit, die es braucht, um Foundrys Ontologie zu beherrschen, eine bessere, maßgeschneiderte Self-Service-Schicht auf Snowflake aufbauen. Die Entscheidung ist also keine Frage technischer Überlegenheit. Es ist eine Build-vs-Buy-Frage zur semantischen Schicht, bewertet anhand der aktuellen und geplanten Engineering-Kapazität. Teams, die Platform Engineers günstig einstellen und halten können, sollten selbst bauen. Teams, die das nicht können, sollten die Kaufoption zumindest ernsthaft durchrechnen.

Auswirkungen auf die Branche

Für regulierte Branchen – iGaming-Betreiber, Fintech-Plattformen, Ad-Tech-Firmen mit umfangreichem Compliance-Reporting – neigt sich die Waage in eine bestimmte Richtung. In diesen Unternehmen ist die nicht-technische Bevölkerung, die mit Daten arbeitet, regulatorisch bedingt groß: Compliance-Beauftragte, Risikoanalysten, AML-Prüfer, Produktmarketing-Manager, die Kohortenberichte für Regulatoren erstellen. Nur wenige von ihnen schreiben SQL flüssig. Und nur wenige sollten das müssen.

Genau dieses Nutzerprofil identifiziert Siwakoti als Foundrys Sweet Spot. Es ist auch genau die Nutzergruppe, der traditionelle Stacks ohne erheblichen individuellen Aufwand schlecht dienen. Eine Fintech-Plattform mit einer 400-köpfigen Compliance- und Operations-Abteilung wird echte Engineering-Ressourcen für Aufbau und Pflege von Self-Service-Reporting auf Snowflake aufwenden. Ob diese annualisierten Kosten eine verhandelte Foundry-kernbasierte Lizenz übersteigen, ist eine reale Tabellenkalkulationsübung und keine philosophische Frage. Bei etwa 66.000 Pfund pro Server-Core pro Jahr ohne Nutzergebühren können die Stückkosten attraktiv wirken, sobald die Anzahl nicht-technischer Nutzer einen Schwellenwert überschreitet – weil das Hinzufügen von Nutzern nichts kostet.

Der Haken – und es ist ein großer – ist die Anbieterbindung. Kernbasierte Lizenzierung plus proprietäres Ontologie-Modell plus ein verhandelter Vertrag ohne öffentliche Listenpreise ergibt maximale Wechselkosten. Die Frage des General Counsel – nicht die des VP Engineering – lautet, wie die Ausstiegsklausel im dritten Jahr aussieht. Meine Einschätzung: Für Unternehmen, deren Datenmodell wirklich stabil ist und deren regulatorisches Risiko gut verstanden ist, ist die Bindung ein fairer Tausch für die Produktivität. Für Unternehmen, die noch herausfinden, was ihre Daten bedeuten, ist es teuer, eine gemeinsame semantische Schicht festzuschreiben, bevor die Semantik stabil ist.

Worauf man achten sollte

Drei Signale sind in den nächsten zwei Quartalen entscheidend. Erstens: ob Databricks und Snowflake weiterhin ausreichend in ihre eigenen semantischen Schichten und Self-Service-Werkzeuge investieren, um die Ontologie-Lücke zu schließen. Gelingt ihnen das, verengt sich Foundrys Differenzierung auf das Enterprise-Segment, in dem Implementierungsdienstleistungen wichtiger sind als Plattformfunktionen. Zweitens: ob Beschaffungsanalysedaten weiterhin eine zwei- bis dreifache Preisstreuung basierend auf der Verhandlungsposition zeigen. Diese Art von Streuung ist in reifen Enterprise-Software-Kategorien ungewöhnlich und deutet darauf hin, dass Palantirs Preissetzungsmacht noch stark situationsabhängig ist. Drittens: Signale vom Einstellungsmarkt. Wenn die Gehälter für Senior-Data-Platform-Engineers weiter schneller steigen als die allgemeine Software-Inflation, stärkt das den Kauffall für Foundry-ähnliche Plattformen rein durch Lohnkostenarbitrage.

Das CFO-Gespräch in diesem Quartal ist unspektakulär, aber entscheidend: Was sind die voll kalkulierten Jahreskosten des Data-Engineering-Personals, das derzeit mit Self-Service für Nicht-Techniker beschäftigt ist – und wie verhält sich das im Vergleich zu einem modellierten Foundry-Vertrag mit einer glaubwürdigen Alternative in der Hand? Wenn niemand in der Finanzabteilung diese Frage beantworten kann, wird die Plattformentscheidung nach Bauchgefühl getroffen.

Wichtige Erkenntnisse

• Foundry anhand der SQL-Kompetenzrate bewerten, nicht anhand von Pipeline-Benchmarks. Wenn mehr als die Hälfte der datenbezogenen Mitarbeiter kein SQL schreiben kann, verschiebt sich die Self-Service-Rechnung erheblich.
• Mit einer kalkulierten Databricks- oder Snowflake-Alternative in Verhandlungen gehen. Beschaffungsanalysen zeigen eine zwei- bis dreifache Preisstreuung allein aufgrund der Verhandlungsposition.
• Stückkosten auf Core-Basis berechnen, nicht auf Nutzer-Basis. Bei etwa 66.000 Pfund pro Server-Core pro Jahr ohne Nutzergebühren begünstigt Foundry Deployments mit großen nicht-technischen Nutzerpopulationen.
• Das Ontologie-Modell als Build-vs-Buy-Entscheidung zur semantischen Schicht behandeln. Starke Plattform-Teams können es auf Snowflake plus dbt replizieren; unterbesetzte Teams nicht.
• Den General Counsel bei Ausstiegsklauseln einbinden. Proprietäre Ontologie plus verhandelte Preise plus kernbasierte Lizenzierung ergeben maximale Wechselkosten im dritten Jahr.