EDB показує уповільнення 2.7x проти 3.9x у Snowflake за тестом TPC-DS

Головна цифра бенчмарку McKnight Consulting Group — 58 відсотків: це верхня межа річної економії TCO, яку EDB Postgres AI for WarehousePG заявляє порівняно з провідними хмарними сховищами даних на навантаженні розширеного TPC-DS обсягом 10TB. У конкретному розкритому випадку це означає $222 886 на рік для EDB проти $351 953 для багатокластерного розгортання Snowflake — різниця у 37 відсотків в абсолютному вираженні. Чи є чеснішою цифрою 58 чи 37 відсотків — залежить від конфігурації, яку прес-реліз не описує повністю, і ця різниця має значення.

Що сталося

31 березня 2026 року EnterpriseDB оприлюднила результати незалежного бенчмарк-дослідження McKnight Consulting Group разом з оновленнями платформи за Q1, як повідомило PR Newswire з Вілмінгтона. McKnight тестував EDB PG AI for WarehousePG проти Snowflake, Databricks, Amazon Redshift та Hive на Apache Iceberg з використанням розширеного датасету TPC-DS обсягом 10TB, причому тест був зосереджений на змішаних навантаженнях із високою паралельністю, а не на піковій продуктивності окремих запитів.

Заявлені результати паралельності, при масштабуванні від одного до п'яти одночасних користувачів: EDB PG AI — уповільнення 2.7x, Snowflake — 3.9x, Redshift — 4.0x, Databricks — 4.1x. Іншими словами, три хмарні сховища згруповані в межах 5-відсоткового діапазону між собою за цим показником, тоді як EDB випереджає цей пакет приблизно на 30–35 відсотків. Формулювання Вільяма МакНайта було навмисно обережним: хмарні сховища все ще підходять для «найвибагливіших запитів», сказав він, але EDB PG AI «ефективно працює для аналітики з високою паралельністю, що забезпечує щоденні операції», і він прямо підтримав «гібридний підхід», а не повну заміну.

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

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

Центр тяжіння бенчмарку — масштабування паралельності, а не сира затримка запитів, і цей вибір говорить про те, що EDB насправді продає. TPC-DS на 10TB з одним-п'ятьма одночасними користувачами — це не стрес-тест для еластичного масштабування безсерверного сховища. Це стрес-тест на передбачуваність при повторюваному навантаженні дашбордів та агентів, які звертаються до одного кластера сховища у перекривних часових проміжках. Уповільнення 2.7x при 5-кратній паралельності означає, що EDB деградує суб-лінійно, тоді як 3.9x у Snowflake, 4.0x у Redshift та 4.1x у Databricks — усі ближчі до лінійної деградації відносно кількості користувачів. Це узгоджується з тим, чого слід очікувати від MPP-рушія на основі Postgres, що працює на виділеній потужності, порівняно з рушіями запитів, яким доводиться узгоджувати виділення обчислювального пулу.

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

Що джерело не розкриває, і що суттєво змінює висновки: налаштований розмір кластера для кожної системи, рівень зберігання (розділений чи суміщений), чи працював Snowflake на багатокластерному сховищі з обмеженнями автомасштабування або на фіксованому сховищі, розбивка міксу запитів у розширеному TPC-DS, а також чи було увімкнено кешування результатів. Без цього межа така: навіть якщо перевага EDB скоротиться вдвічі при інших конфігураціях, перевага TCO у 15–20 відсотків на стійкому рівні високої паралельності все одно є обґрунтованою. Якщо деталі конфігурації змінять ситуацію в інший бік, перевага може зникнути на навантаженнях, що складаються переважно з довільних запитів.

Хто в зоні ризику

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

Постачальники хмарних сховищ не перебувають у безпосередній небезпеці. Сам МакНайт сказав, що хмарні сховища все ще перемагають на «найвибагливіших запитах», тобто в дослідницькій data science та довільній аналітичній роботі, де еластичне тарифікування пікового навантаження є виправданим. Загроза вужча: операційний аналітичний рівень, завжди активний сегмент, — ось де тарифікація за потужністю на Postgres-сумісному MPP стає структурно дешевшою. Очікуйте, що це проявиться як розподіл навантажень, а не масова міграція. CTO, що вже використовують Postgres для OLTP, отримують очевидну суміжну можливість.

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

Стратегія для команд даних

По-перше, класифікуйте витрати на сховище за шаблоном навантаження, а не за командою. Відокремте завжди активний рівень (заплановані дашборди, вбудована аналітика, агентні цикли) від дослідницького рівня (ноутбуки, довільний SQL, вибірка ознак для навчання моделей). Тарифікація за потужністю перемагає на завжди активному рівні. Якщо цей рівень складає більше 60 відсотків ваших витрат на сховище, у вас є реальна оцінка для проведення, а не блеф у переговорах із постачальником.

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

По-третє, серйозно розгляньте агентний бік. Нативна підтримка MCP в Agent Studio від EDB означає, що агенти можуть звертатися до Postgres безпосередньо як до інструменту, що усуває рівень трансляції, який більшість сучасних агентних стеків маскує конвеєрами пошуку. У поєднанні з VectorChord на тому самому рушії це об'єднує векторне сховище та операційне сховище в один керований субстрат. Це архітектурно цікаво незалежно від бенчмарку.

По-четверте, не ігноруйте сертифікацію Ansible та заявлений час переключення менш ніж 30 секунд. Для регульованих вертикалей, де сховище знаходиться на критичному шляху для звітності щодо відповідності, мультизональний HA на аналітичному рівні історично був задачею кастомної розробки. Якщо це тепер є пакетною сертифікацією, це змінює математику «будувати чи купити» для платформних команд.

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

• Уповільнення паралельності EDB PG AI у 2.7x перевершує Snowflake (3.9x), Redshift (4.0x) та Databricks (4.1x) на тесті TPC-DS 10TB, але лише в розкритому діапазоні від одного до п'яти користувачів.
• Порівняння $222 886 проти $351 953 — це одна налаштована конфігурація, а не універсальна заява, а базовий розмір кластера не розкрито у прес-релізі.
• Тарифікація за потужністю структурно перемагає тарифікацію за споживанням на завжди активних навантаженнях; зворотне справедливо для пікової дослідницької аналітики, що МакНайт прямо визнав.
• Доповнення платформи Q1 (інтеграція NVIDIA cuDF, Agent Studio на базі Langflow, VectorChord, сертифікація Ansible з переключенням менш ніж за 30 секунд) орієнтовані на рівень агентних навантажень, а не на класичну BI.
• Перевіряємий прогноз: якщо перевага EDB з паралельністю є реальною, очікуйте, що принаймні один великий постачальник хмарних сховищ оголосить ціновий рівень із зобов'язаннями щодо потужності або фіксовану одиницю SKU для паралельності протягом двох кварталів.