Snowflake vs Databricks vs BigQuery: Реальність витрат у 2026 році

Кожен керівник платформи, який підписав семизначний контракт на сховище даних, знає про «сюрприз другого року»: обсяг запитів потроївся, рахунок зріс учетверо, і ніхто в команді не може пояснити чому. Огляд Snowflake, Databricks і BigQuery станом на 2026 рік потрапляє прямо в цю тривогу. Три платформи, три моделі ціноутворення та клієнтська база зі списку Fortune 500, що пильно стежить за лічильником.

Що відбулось

Свіже порівняння, опубліковане цього тижня, описує стан аналітичної «великої трійки» станом на середину 2026 року. Як повідомляє tech-insider.org, три платформи тепер забезпечують аналітичну основу більшості компаній зі списку Fortune 500, і показники зростання говорять самі за себе.

Snowflake опублікував $1,33 млрд доходу від продуктів за останній квартал — зростання на 34% рік до року. Вартість одного кредиту становить приблизно від $2 до $4 залежно від редакції та регіону. Databricks залучив $4 млрд у рамках раунду Series L у грудні 2025 року при оцінці $134 млрд, за даними TechCrunch, і повідомив про приблизно $6,9 млрд у річному вираженні доходу до середини 2026 року. BigQuery входить до складу Google Cloud з річним доходом понад $50 млрд, окремо не виділяється та стягує $6,25 за ТіБ просканованих даних у моделі з оплатою за запит.

Структурні зміни 2025 року не менш важливі, ніж показники доходу. Snowflake придбав Crunchy Data. Databricks придбав Neon. Обидва вендори в один рік увійшли у транзакційний Postgres, що сигналізує: моделі «лише сховище» та lakehouse-only більше не актуальні. Усі три платформи тепер підтримують Apache Iceberg — відкритий табличний формат, який теоретично дозволяє переносити дані без їх переписування.

Кожен вендор також вийшов на чужу територію. Snowflake додав Snowpark і контейнерні сервіси для інженерних та ML-навантажень. Databricks додав Databricks SQL і серверлес-сховища для BI-команд. BigQuery додав BigLake і підтримку Iceberg для lakehouse-патернів. Конвергенція реальна, але архітектури під капотом досі поводяться дуже по-різному, коли приходить рахунок.

Технічна анатомія

Архітектура Snowflake найпростіша в обслуговуванні. Дані зберігаються в хмарному об'єктному сховищі у власному стислому колонковому форматі Snowflake. Обчислення виконуються у віртуальних сховищах розміром від X-Small до 6X-Large, які автоматично призупиняються в разі простою та відновлюються на вимогу. Немає індексів для налаштування та кластерів для обслуговування. Оберіть розір, направте SQL на нього — і все. Документація Snowflake детально описує модель вибору розміру сховища, і саме тому BI-команди без платформного інженера можуть підтримувати повноцінний аналітичний стек.

Databricks — це протилежна філософія. Дані зберігаються у відкритих форматах у вашому власному хмарному сховищі під управлінням Delta Lake, який додає ACID-транзакції, контроль схеми та time travel поверх Parquet-файлів. Обчислення виконуються на кластерах Apache Spark, прискорених Photon — C++ векторизованим рушієм. Платформа охоплює ноутбуки, потокову обробку, SQL-сховища та повний ML-цикл через MLflow і Mosaic AI. Документація Databricks об'ємна з причини: це справжня платформа, а не керований рушій запитів, і вона винагороджує команди з реальними дата-інженерами.

BigQuery — єдина з трьох платформ, яка є по-справжньому серверлес. Немає сховища для вибору розміру. Ви надсилаєте запит, рушій Dremel від Google виділяє слоти зі спільного пулу, а потім звільняє їх. Дані зберігаються на Colossus — розподіленій файловій системі Google. Omni може запитувати дані з AWS і Azure, але панель управління залишається на GCP, тому мультихмарність — це лише напівобіцянка.

Моя думка: історія про конвергенцію перебільшена. Кластер Spark, який прикидається сховищем, о другій ночі, коли щось зламалося, залишається кластером Spark. Сховище Snowflake, що виконує Python у контейнері, однаково нараховує кредити. Середовища виконання не забувають своє походження — і не забувають режими операційних збоїв, які я спостерігав у виробничих інцидентах.

Хто отримує удар

Найбільш вразливі в наступні 90 днів — команди, які купили платформу для одного типу навантажень, а тепер мусять запускати на ній інші. BI-відділ, що три роки тому стандартизувався на Snowflake, і якому тепер віцепрезидент вимагає «AI-функції до Q4», дивиться на Snowpark, контейнерні сервіси та криву навчання, яка не відповідає навичкам команди. Можливості є. М'язова пам'ять — ні.

Дзеркальна проблема торкається команд на Databricks. Команди, які купили lakehouse для дата-інженерії та ML, тепер мусять забезпечувати самообслуговування BI для фінансів і маркетингу. Databricks SQL і серверлес-сховища є цілком придатними, але операційна модель все одно передбачає, що хтось розуміється на кластерах, оптимізації Delta та особливостях Photon. Незручна реальність: багато організацій купили Databricks заради обіцянок ML і тихо використовують хіба що 20% платформи, платячи повну ціну.

Клієнти BigQuery стикаються з іншим тиском. $6,25 за ТіБ просканованих даних виглядає чудово на слайді, доки в понеділок вранці аналітик не пише SELECT * до таблиці на 40 ТіБ. Це $250 за один запит, і команди, з якими я працював, бачили, як місячні рахунки зростали втричі через один невдалий дашборд. Для дата-команди з 10 інженерів несподіваний рахунок у $50 тис. на місяць — це бюджет двох інженерів, що пішов на один необережний join.

Придбання Postgres-рішень — Crunchy Data компанією Snowflake і Neon компанією Databricks — також змінює, хто отримає удар. Операційні сховища даних, які раніше були поза зоною інтересів вендорів сховищ, тепер потрапляють у фокус наступного циклу продажів. Очікуйте, що переговори про поновлення контрактів у 2026 році включатимуть транзакційний Postgres до розрахунку знижок, що ускладнює, а не полегшує вихід.

План дій для дата-команд

По-перше, інструментуйте витрати раніше за все інше. Для Snowflake — позначайте сховища за командами та агресивно налаштовуйте auto-suspend. Для Databricks — застосовуйте політики кластерів і завершуйте ноутбуки, що простоюють. Для BigQuery — встановіть ліміти байтів запитів на користувача та проект цього тижня, а не наступного кварталу. Один захисний бар'єр запобіжить більше перевищень, ніж будь-який квартальний огляд.

По-друге, ставтеся до Iceberg серйозно, але не вірте маркетингу. Всі три платформи підтримують Iceberg станом на 2026 рік, що означає: ваші дані теоретично може зчитати будь-яка з них. На практиці шлях запису, каталог і рівень управління все одно прив'язують вас до вендора. Проведіть proof of concept — запишіть дані одним рушієм і прочитайте іншим — перш ніж довіряти обіцянці портативності у презентації для ради директорів.

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

По-четверте, підбирайте платформу під команду, яка у вас є насправді, а не під ту, яку ви хотіли б мати. Snowflake — для SQL-орієнтованого BI без платформного інженера. Databricks — якщо у вас є справжні дата-інженери та дорожня карта ML. BigQuery — якщо ви вже у GCP-екосистемі. Вибір не відповідно до своїх кадрових можливостей — найдорожча помилка в цій категорії.

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

• Квартальний дохід Snowflake у $1,33 млрд при зростанні на 34% та оцінка Databricks у $134 млрд у рамках Series L доводять: аналітичний ринок не консолідується, а розширюється в бік Postgres та AI.
• $6,25 BigQuery за ТіБ просканованих даних винагороджує дисциплінований SQL і карає за недбалі запити; встановіть ліміти байтів до першого невдалого понеділка.
• Підтримка Iceberg на всіх трьох платформах реальна, але часткова; тестуйте запис і читання між рушіями, перш ніж довіряти обіцянці портативності.
• Придбання Postgres-рішень у 2025 році (Crunchy Data, Neon) означає, що операційні дані тепер входять у зону прив'язки до вендора сховища; плануйте поновлення контрактів відповідно.
• Обирайте платформу під вашу реальну модель укомплектованості персоналом, а не ту, що має найкраще AI-демо. Операційна відповідність завжди перемагає паритет функцій.