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 закрыл раунд Series L на $4 млрд в декабре 2025 года при оценке $134 млрд, по данным TechCrunch, и к середине 2026 года сообщил об аннуализированной выручке около $6,9 млрд. BigQuery входит в состав Google Cloud с годовым оборотом свыше $50 млрд, не выделяется отдельно и взимает $6,25 за TiB просканированных данных по модели по запросу.

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

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

Техническая анатомия

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

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

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

Моя точка зрения: история конвергенции преувеличена. Кластер Spark, притворяющийся хранилищем, в 2 часа ночи при поломке всё равно остаётся кластером Spark. Хранилище Snowflake, запускающее Python в контейнере, всё равно тарифицирует кредиты по-прежнему. Среды выполнения не забывают своего происхождения, как и операционные сценарии отказов, которые всплывают в производственных инцидентах.

Кто пострадает

Команды, наиболее уязвимые в ближайшие 90 дней, — это те, кто приобрёл платформу для одной задачи, а теперь должен запускать на ней другую. Команда BI, стандартизировавшаяся на Snowflake три года назад и столкнувшаяся с требованием вице-президента внедрить «функции AI к четвёртому кварталу», смотрит на Snowpark, контейнерные сервисы и кривую обучения, не соответствующую навыкам команды. Возможности существуют. Мышечной памяти нет.

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

Клиенты BigQuery сталкиваются с иным давлением. Цена $6,25 за TiB просканированных данных выглядит прекрасно на слайде — до тех пор, пока аналитик не пишет SELECT * по таблице объёмом 40 TiB в понедельник утром. Это $250 за один запрос, и команды, с которыми я работал, видели, как ежемесячные счета колебались в 3 раза из-за одного неудачного дашборда. Для команды из 10 инженеров неожиданный счёт в $50 тыс. за месяц — это бюджет двух инженеров, ушедший на один небрежный join.

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

Руководство для дата-команд

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

Во-вторых, отнеситесь серьёзно к истории про Iceberg, но не верьте маркетингу. Все три платформы поддерживают Iceberg по состоянию на 2026 год, что означает: ваши данные теоретически могут быть прочитаны любой из них. На практике путь записи, каталог и уровень управления по-прежнему привязывают вас к поставщику. Проведите пробную концепцию, где вы пишете из одного движка и читаете из другого, прежде чем доверять заявлению о переносимости в презентации для совета директоров.

В-третьих, отделите трансформацию от поставщика хранилища. Такие инструменты, как dbt, позволяют сохранять переносимость слоя моделирования даже тогда, когда базовый движок не является переносимым. Если в 2027 году вас ждёт миграция, команда, уже использующая dbt против хранилища, перейдёт за месяцы. Команда с тысячами хранимых процедур будет переходить годами.

В-четвёртых, подбирайте платформу под команду, которая у вас есть, а не под ту, которую вы хотели бы иметь. Snowflake — для BI с большим объёмом SQL без платформенного инженера. Databricks — если у вас есть настоящие дата-инженеры и дорожная карта ML. BigQuery — если вы уже работаете в экосистеме GCP. Выбор, не соответствующий вашей кадровой ситуации, — самая дорогостоящая ошибка в этой категории.

Ключевые выводы

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