Palantir Foundry проти Snowflake: реальний сигнал до покупки для CTO

Головне питання, яке кожен керівник платформи, що розглядає пропозицію Palantir Foundry, має поставити своєму CFO цього тижня, — не те, чи швидші демонстрації пайплайнів. Питання в тому, чи є в папці закупівель прорахована альтернатива у вигляді Databricks або Snowflake. Без такої альтернативи річний рахунок може виявитися у два-три рази вищим, ніж у колег за аналогічне розгортання.

Розповідь від першої особи дата-інженера, який починав з AWS, Azure і Snowflake, а потім пройшов буткемп Foundry, варта уваги саме тому, що вона ізолює дві змінні, які насправді визначають рішення про покупку: скільки ваших користувачів вміють писати SQL, і з якою переговорною позицією ви заходите на переговори. Все інше — шум.

Ключові деталі

У своєму матеріалі для InfoWorld Сашанк Сівакоті описує навчальний буткемп Palantir Foundry, під час якого побудова пайплайну, що збирав дані з кількох джерел, застосовував трансформації та надавав результат бізнес-користувачам, зайняла лічені години. Для порівняння: на стандартному стеку AWS або Snowflake з dbt та шаром оркестрації аналогічне налаштування зазвичай потребує повного спринту для невеликої команди. Автор відзначає заслугу Pipeline Builder у Foundry за скорочення накладних витрат на координацію між інструментами, а також онтологічну модель — описану як спільний семантичний шар — яка робить самообслуговування швидше стандартом, ніж окремим інженерним проєктом.

Структура ціноутворення — ось де виконавче рішення стає чіткішим. Palantir не публікує прайс-лист. Foundry використовує ліцензійну модель на основі ядер, тобто оплата прив'язана до обчислювальної потужності (ядер сервера), виділеної для платформи, а не до кількості користувачів. Ліцензії на основі ядер починаються від приблизно 66 000 фунтів за серверне ядро на рік без додаткових плат за користувача. Ліцензії на основі конкретних сценаріїв використання, що включають впровадження та підтримку, починаються від 250 000 фунтів на початковому рівні й суттєво зростають залежно від складності даних, бази користувачів та операційного масштабу. Все узгоджується в переговорному порядку.

Сівакоті посилається на аналіз консультантів із закупівель Redress Compliance щодо переговорів по Palantir Foundry, що проводилися у 2024–2025 роках. Виявилося, що річні платформні збори для порівнянних середніх розгортань відрізнялися в два-три рази залежно виключно від переговорної позиції. Його висновок: головна перевага в переговорах — наявність реальної, прорахованої альтернативи, як правило Databricks або Snowflake, а організації без такої альтернативи схильні платити значно більше за те саме розгортання. Також він зазначає, що більшість матеріалів про Foundry в мережі — це або маркетинг Palantir, або публікації глибоко залучених практиків, і саме тому погляд «свіжого ока» є цінним.

Чому це важливо для дата-команд

Ключовий інсайт у розповіді Сівакоті — зовсім не про Foundry. Він про те, як оцінюються рішення щодо платформ. Більшість CTO порівнюють дата-платформи за продуктивністю пайплайнів, вартістю сховища на один запит та сумісністю з наявним CI/CD. Це метрики, орієнтовані на інженерів. Сівакоті стверджує, що правильний критерій оцінки — це відсоток людей, яким потрібен доступ до даних і які реально вміють писати SQL. В організаціях, де більше половини бізнес-аналітиків і операційних користувачів не вміють писати код, інженерне навантаження на побудову самообслуговування на традиційному стеку стає постійними, наростаючими витратами.

Переформулюйте це як кадрове питання. Стек Snowflake плюс dbt передбачає, що ви можете найняти та утримати команду дата-інженерів, здатну безперервно будувати та підтримувати семантичні шари, специфікації відкриття та BI-абстракції для нетехнічних користувачів. На напруженому ринку праці це припущення несе велике навантаження. Якщо співвідношення аналітиків до інженерів становить 20:1 і зростає, граничні витрати на кожен новий дашборд самообслуговування на традиційному стеку — це половина дня роботи старшого інженера. І ці половини накопичуються.

Онтологічна модель Foundry змінює трудове рівняння, виносячи семантичний шар як примітив платформи, а не як щось, що ваша команда збирає самостійно. Компроміс чесний, і Сівакоті його називає прямо: сильна, добре забезпечена ресурсами команда дата-інженерів може побудувати кращий, більш адаптований шар самообслуговування на Snowflake за той самий час, що потрібен для освоєння онтології Foundry. Тож рішення — не про технічну перевагу. Це питання «будувати чи купити» стосовно семантичного шару, оцінене відносно поточної та прогнозованої чисельності інженерів. Команди, що можуть дешево наймати та утримувати платформних інженерів, мають будувати самостійно. Ті, що не можуть, принаймні повинні серйозно змоделювати варіант покупки.

Вплив на галузь

Для регульованих вертикалей — iGaming-операторів, фінтех-платформ, ad-tech компаній з інтенсивною compliance-звітністю — розрахунок схиляється в певний бік. Це організації, де нетехнічна частина персоналу, що взаємодіє з даними, є великою за регуляторною необхідністю: комплаєнс-офіцери, ризик-аналітики, AML-перевіряючі, керівники продуктового маркетингу, що формують когортні звіти для регуляторів. Дуже мало хто з них вільно пише SQL. І дуже мало хто повинен це робити.

Саме такий профіль персоналу Сівакоті визначає як зону найбільшої придатності Foundry. І саме така категорія людей погано обслуговується традиційними стеками без значних кастомних доробок. Фінтех-платформа зі штатом відділу комплаєнсу та операцій у 400 осіб витратить реальні інженерні ресурси на побудову та підтримку самообслуговування у звітності на Snowflake. Чи перевищить ця річна вартість узгоджену ліцензію Foundry на основі ядер — питання конкретної таблиці Excel, а не філософського порядку. При вартості близько 66 000 фунтів за серверне ядро на рік без плат за користувача одинична економіка може виглядати привабливо, коли кількість нетехнічних користувачів перетне певний поріг, адже ви не платите за додавання користувачів.

Підводний камінь — і він великий — це прив'язка до вендора. Ліцензування на основі ядер плюс власницька онтологічна модель плюс узгоджений контракт без публічного прайс-листа дорівнює максимальним витратам на перехід. Питання генерального юрисконсульта, а не VP Engineering, — як виглядає умова виходу на третьому році. Моя позиція: для організацій, чия модель даних справді стабільна і чий регуляторний ризик добре зрозумілий, прив'язка є справедливим обміном за продуктивність. Для організацій, що ще з'ясовують, що означають їхні дані, фіксація спільного семантичного шару до стабілізації семантики обійдеться дорого.

На що звертати увагу

Протягом наступних двох кварталів важливі три сигнали. По-перше, чи продовжать Databricks і Snowflake достатньо активно інвестувати у власний семантичний шар та інструменти самообслуговування, щоб скоротити онтологічний розрив. Якщо так — диференціація Foundry звузиться до корпоративного сегменту, де послуги впровадження важливіші за функції платформи. По-друге, чи продовжать консультаційні дані із закупівель демонструвати дворазово-триразовий розкид цін залежно від переговорної позиції. Такий розкид є незвичним для зрілих категорій корпоративного програмного забезпечення і свідчить про те, що цінова сила Palantir залишається дуже ситуативною. По-третє, сигнали ринку праці. Якщо зарплати старших інженерів дата-платформ продовжуватимуть зростати швидше за загальну інфляцію в ПЗ, аргумент на користь покупки платформ типу Foundry посилюватиметься суто через арбітраж на вартості праці.

Розмова з CFO цього кварталу є непомітною, але визначальною: яка повна річна вартість дата-інженерних ресурсів, що наразі виділені на самообслуговування нетехнічних користувачів, і як вона співвідноситься з модельованим контрактом Foundry за наявності реальної альтернативи на переговорах? Якщо ніхто у фінансовому підрозділі не може відповісти на це питання, рішення щодо платформи приймається на відчутті.

Ключові висновки

• Оцінюйте Foundry за рівнем SQL-грамотності, а не за бенчмарками пайплайнів. Якщо більше половини ваших співробітників, що працюють з даними, не вміють писати SQL, математика самообслуговування суттєво змінюється.
• Заходьте на переговори з прорахованою альтернативою Databricks або Snowflake. Аналіз закупівель показує дворазово-триразовий розкид цін виключно через переговорну позицію.
• Моделюйте одиничну економіку на ядрах, а не на місцях. При вартості близько 66 000 фунтів за серверне ядро на рік без плат за користувача Foundry вигідний для розгортань із великою кількістю нетехнічних користувачів.
• Розглядайте онтологічну модель як рішення «будувати чи купити» для семантичного шару. Сильні платформні команди можуть відтворити її на Snowflake плюс dbt; недоукомплектовані — ні.
• Залучайте генерального юрисконсульта до питання умов виходу. Власницька онтологія плюс узгоджене ціноутворення плюс ліцензування на основі ядер дорівнює максимальним витратам на перехід до третього року.