EDB показывает замедление 2,7x против 3,9x у Snowflake в тесте TPC-DS

Главная цифра бенчмарка McKnight Consulting Group — 58 процентов: это верхняя граница годовой экономии TCO, которую EDB Postgres AI for WarehousePG заявляет по сравнению с ведущими облачными хранилищами данных на расширенной нагрузке TPC-DS объёмом 10 ТБ. В конкретном приведённом примере это составляет $222 886 в год для EDB против $351 953 для многокластерного развёртывания Snowflake — разница в 37 процентов в абсолютном выражении. Какая из цифр — 58 или 37 процентов — более честна, зависит от конфигурации, которую пресс-релиз полностью не раскрывает, и этот разрыв имеет значение.

Что произошло

31 марта 2026 года EnterpriseDB опубликовала результаты независимого бенчмаркинга McKnight Consulting Group одновременно с обновлениями платформы за первый квартал, как сообщил PR Newswire из Уилмингтона. McKnight тестировал EDB PG AI for WarehousePG в сравнении со Snowflake, Databricks, Amazon Redshift и Hive на Apache Iceberg на расширенном наборе данных TPC-DS объёмом 10 ТБ; тест был спроектирован с акцентом на смешанные нагрузки с высоким уровнем параллелизма, а не на пиковую производительность одиночных запросов.

Зафиксированные результаты по параллелизму при масштабировании от одного до пяти одновременных пользователей: EDB PG AI — замедление в 2,7x, Snowflake — 3,9x, Redshift — 4,0x, Databricks — 4,1x. Иными словами, три облачных хранилища укладываются в диапазон 5 процентов друг от друга по этому показателю, тогда как EDB опережает эту группу примерно на 30–35 процентов. Уильям МакНайт намеренно сформулировал свои выводы осторожно: облачные хранилища по-прежнему подходят для «наиболее требовательных запросов», однако EDB PG AI «эффективно работает при высококонкурентной аналитике, обеспечивающей ежедневные операции», и он прямо поддержал «гибридный подход», а не полную замену.

EDB дополняет бенчмарк релизом платформы за первый квартал: GPU-ускоренная аналитика через Apache Spark совместно с NVIDIA cuDF (заявленное ускорение в 50–100x для наборов данных от 3 ТБ и более), Agent Studio на базе Langflow с нативной поддержкой MCP, обновление векторного движка с VectorChord (заявленное ускорение индексирования в 100x), новый WarehousePG Enterprise Manager для MPP-нагрузок, чат-бот на естественном языке для администрирования и сертификация Red Hat Ansible Automation Platform с переключением при отказе менее чем за 30 секунд между зонами доступности.

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

Центром тяжести бенчмарка является масштабирование параллелизма, а не чистая латентность запросов, и этот выбор говорит о том, что именно продаёт EDB. TPC-DS на 10 ТБ с одним-пятью одновременными пользователями — это не стресс-тест для истории об эластичном масштабировании бессерверного хранилища. Это стресс-тест предсказуемости при повторяющихся дашбордных и агентных нагрузках, которые одновременно обращаются к одному и тому же кластеру хранилища. Замедление в 2,7x при 5-кратном параллелизме означает, что деградация EDB происходит сублинейно, тогда как показатели Snowflake (3,9x), Redshift (4,0x) и Databricks (4,1x) все ближе к линейной деградации относительно числа пользователей. Это согласуется с тем, чего можно ожидать от MPP-движка на базе Postgres, работающего на выделенных мощностях, по сравнению с движками запросов, которым приходится согласовывать выделение пула вычислительных ресурсов.

Модель ценообразования — второй аспект. EDB выставляет счёт за ёмкость на основе ядер, тогда как Snowflake, Databricks и Redshift используют потребительское ценообразование поверх размера хранилища или кластера. Для уровня высокочастотных дашбордов или агентного цикла, выполняющего запросы в режиме опроса, потребительское ценообразование превращает объём запросов в переменную P&L. Ценообразование на основе ёмкости превращает его в постоянные затраты. Сравнение $222 886 против $351 953 — это финансовое выражение этого архитектурного различия при одном конкретном профиле нагрузки.

То, что источник не раскрывает и что существенно меняет интерпретацию: настроенный размер кластера для каждой системы, уровень хранилища (раздельный или совмещённый), работал ли Snowflake на многокластерном хранилище с ограничениями автомасштабирования или на фиксированном хранилище, разбивка смеси запросов внутри расширенного TPC-DS, и было ли включено кэширование результатов. Без этих данных граница такова: даже если преимущество EDB сократится вдвое при других конфигурациях, преимущество TCO в 15–20 процентов на устойчивом высококонкурентном уровне по-прежнему обоснованно. Если же эти детали конфигурации качнутся в другую сторону, преимущество может исчезнуть на нагрузках, где преобладают ad hoc-запросы.

Кого это касается

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

Вендоры облачных хранилищ не находятся в непосредственной опасности. Сам МакНайт заявил, что облачные хранилища по-прежнему выигрывают по «наиболее требовательным запросам», то есть в исследовательской аналитике данных и ad hoc-анализе, где имеет смысл эластичное ценообразование за всплески. Угроза уже: операционный аналитический уровень, «всегда включённый» сегмент — именно здесь ценообразование на основе ёмкости для Postgres-совместимого MPP становится структурно дешевле. Ожидайте, что это проявится как раздвоение нагрузок, а не как полная миграция. CTO, которые уже используют Postgres для OLTP, получают очевидную смежную возможность.

Команда, наиболее подверженная риску в ближайшие 90 дней, — та, которая отвечает за счёт Snowflake или Databricks в компании, где финансовая служба начала задаваться вопросом, почему затраты на аналитику растут пропорционально числу сотрудников, умноженному на количество дашбордов. Сравнение долларовых затрат с разницей в 37 процентов от именитого стороннего аналитика — это именно тот артефакт, который отдел закупок использует для принудительного пересмотра условий. Мы не знаем, какие скидочные уровни предложат вендоры облачных хранилищ в ответ, но граница проверяема: если заявления EDB подтвердятся при независимой репликации, ожидайте, что менеджеры по работе с клиентами Snowflake предложат более глубокие скидки на обязательства по ёмкости в течение двух кварталов.

Руководство для команд по работе с данными

Во-первых, классифицируйте расходы на хранилище по паттерну нагрузки, а не по команде. Отделите «всегда включённый» уровень (плановые дашборды, встроенная аналитика, агентные циклы) от исследовательского (ноутбуки, ad hoc SQL, выборка признаков для обучения моделей). Именно на «всегда включённом» уровне выигрывает ценообразование на основе ёмкости. Если этот уровень составляет более 60 процентов ваших расходов на хранилище, у вас есть реальная оценка, которую нужно провести, а не закупочный блеф.

Во-вторых, воспроизведите форму бенчмарка на собственных данных, прежде чем верить цифрам любого вендора, включая этот. Возьмите репрезентативную выборку плановых запросов, выполните её при одном пользователе и при пяти одновременных пользователях на вашем текущем хранилище и измерьте коэффициент замедления. Если вы получаете результат лучше 3,9x, цифры МакНайта не предсказывают вашу среду. Если хуже — предложение EDB заслуживает реального proof of concept.

В-третьих, серьёзно отнеситесь к агентной стороне. Нативная поддержка MCP в Agent Studio EDB позволяет агентам обращаться к базам Postgres напрямую как к инструментам, что устраняет уровень трансляции, который большинство современных агентных стеков скрывает за конвейерами извлечения данных. В сочетании с VectorChord на том же движке это объединяет векторное хранилище и операционное хранилище в единый управляемый субстрат. Это архитектурно интересно само по себе, независимо от бенчмарка.

В-четвёртых, не игнорируйте сертификацию Ansible и заявление о переключении при отказе менее чем за 30 секунд. Для регулируемых отраслей, где хранилище находится на критическом пути для compliance-отчётности, multi-AZ HA на аналитическом уровне исторически являлась задачей нестандартной инженерии. Если теперь это упакованная сертификация, она меняет математику build-versus-buy для платформенных команд.

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

• Замедление EDB PG AI в 2,7x превосходит Snowflake (3,9x), Redshift (4,0x) и Databricks (4,1x) в тесте TPC-DS на 10 ТБ, но только в раскрытом диапазоне от одного до пяти пользователей.
• Сравнение $222 886 против $351 953 — это одна сконфигурированная инстанция, а не универсальное утверждение, причём размер кластера в релизе не раскрывается.
• Ценообразование на основе ёмкости структурно выигрывает у потребительского для «всегда включённых» нагрузок; обратное верно для скачкообразной исследовательской аналитики, что МакНайт прямо признал.
• Добавления платформы в первом квартале (интеграция NVIDIA cuDF, Agent Studio на базе Langflow, VectorChord, сертификация Ansible с переключением при отказе менее чем за 30 секунд) нацелены на уровень агентных нагрузок, а не на классический BI.
• Проверяемый прогноз: если конкурентное преимущество EDB по параллелизму реально, ожидайте, что как минимум один крупный вендор облачных хранилищ объявит ценовой уровень с обязательствами по ёмкости или SKU с фиксированной стоимостью параллелизма в течение двух кварталов.