dltHub отримав нагороду Snowflake «Партнер року» 2026

3 червня 2026 року о 18:15 за центральноєвропейським часом на Snowflake Summit 2026 компанія dltHub отримала нагороду 2026 Snowflake Startup Program Product Partner of the Year. Головне — сама нагорода. Але цифра, на яку варто звернути увагу, захована в третьому абзаці прес-релізу: у січні 2026 року AI-агенти створили 91% з 81 000 нових dlt-пайплайнів, запущених того місяця, тоді як рік тому цей показник становив 5% при місячному обсязі близько 2 400. Це зростання обсягу у 34 рази та майже повна інверсія того, хто — або що — пише інтеграційний код.

Що сталося

Берлінська компанія, що стоїть за open-source Python-бібліотекою dlt та отримала підтримку від Bessemer Venture Partners, була названа «Партнером року» Snowflake на щорічній конференції користувачів вендора, як повідомив TradingView у дистрибуції EQS. Нагорода стала підсумком року структурних змін: dltHub здобув компетенції Snowflake Industry Competencies у сферах фінансових послуг, технологій, виробництва та промисловості, а також охорони здоров'я та наук про життя, і тепер є партнером Snowflake Premier AI Data Cloud Products Partner.

Список клієнтів, наведений в оголошенні, є конкретним. Stellantis щомісяця запускає 60 000 Snowflake-пайплайнів на платформі на основі dlt. Sparebank1 використовує dlt як стандартний рівень прийому даних у межах альянсу незалежних банків. Flatiron Health у сфері охорони здоров'я повідомила про скорочення витрат на пайплайни на 50% після переходу на dlt разом зі Snowflake. Понад 1 000 організацій використовують dlt зі Snowflake у продакшені, тоді як понад 10 000 застосовують dlt в ширшій екосистемі — тобто приблизно 10% спільноти працює саме зі Snowflake.

Продуктова частина оголошення: Native App для Snowflake, що реплікує дані з MSSQL, Oracle, MySQL і PostgreSQL, причому весь пайплайн працює всередині облікового запису Snowflake клієнта без зовнішнього оркестратора. Емі Кодл, SVP Worldwide Alliances & Channels у Snowflake, описала це як можливість для клієнтів реплікувати операційні бази даних, «не виводячи дані за межі їхнього облікового запису». Те, що джерело не розкриває, — це ціноутворення, профіль споживання обчислювальних ресурсів та те, як Native App обробляє захоплення змін даних для навантажень Oracle із великою кількістю записів — усе це є важливим для покупців у сфері фінансових послуг і охорони здоров'я, у роботі з якими dltHub тепер має відповідні компетенції.

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

Цікавим інженерним твердженням є показник авторства агентів, і він заслуговує на детальний розгляд. Згідно з телеметрією спільноти dltHub за січень 2026 року, 91% з 81 000 нових щомісячних пайплайнів були створені AI-агентами, що працювали в Claude Code, Cursor або Codex з використанням інструментарію dltHub Pro. Рік тому цей показник становив 5% приблизно від 2 400 пайплайнів. У перерахунку: кількість пайплайнів, написаних людьми, зросла з приблизно 2 280 до приблизно 7 290 на місяць — зростання у 3,2 рази. Кількість пайплайнів, написаних агентами, зросла з приблизно 120 до приблизно 73 710 — зростання у 614 разів. Крива людей є здоровою. Крива агентів — це вся історія.

З архітектурної точки зору, dltHub Pro знаходиться між AI-агентом для написання коду та Snowflake. Агент знаходить джерело, dlt будує скаффолд пайплайну, розробник перевіряє локально, а одна команда розгортає у продакшен. Після того як дані потрапляють до Snowflake, CoCo — AI-асистент для написання коду від Snowflake — бере на себе написання SQL, створення Streamlit-додатків та налаштування Cortex Analyst Semantic Views. Передача контролю є ключовою частиною дизайну: агенти на стороні прийому даних, агенти на стороні споживання, люди перевіряють на межі. За духом це ближче до того, що dbt зробив для трансформацій, ніж до класичного ETL-інтерфейсу.

Патерн Native App — це ще один аспект, на який варто звернути увагу. Пакуючи реплікацію MSSQL, Oracle, MySQL і Postgres як Snowflake Native App, що працює всередині облікового запису клієнта, dltHub обходить модель вивантаження даних і довіри у стилі Fivetran. Немає зовнішнього оркестратора, який потрібно захищати, немає SaaS-тенанта, що зберігає облікові дані продакшену. Для регульованих покупців це спрощення процесу закупівлі. Що ми ще не знаємо — і що має значення — це семантика збоїв: як Native App обробляє зворотний тиск, дрейф схеми на джерелі Oracle із 1 200 таблицями та часткове відтворення. Межа визначається тим, що можуть гарантувати примітиви завдань і потоків Snowflake, — це нетривіально, але не безмежно.

Якщо ця архітектура збережеться, я очікую, що категорія Native App у Snowflake Marketplace побачить щонайменше триразове зростання навантажень реплікації у продакшені протягом наступних чотирьох кварталів, а традиційні постачальники managed-ELT помітно втрачатимуть логотипи клієнтів у регульованих вертикалях.

Хто постраждає

Очевидна загроза — категорія managed ELT. Кейс-стаді Tasman Analytics, наведений у релізі, — це саме той тип даних, який псує розмову про продовження підписки Fivetran: 20 хвилин від документації API до працюючого пайплайну проти приблизно двох тижнів раніше. Інженер середнього рівня у консалтинговій компанії приблизно на 20 осіб з офісами в Амстердамі та Лондоні тепер за один день створює коннектор REST API виробничої якості — робота, яка раніше займала у старшого інженера тиждень. Якщо це співвідношення стане загальним, цінова логіка «за коннектор» GUI-орієнтованих постачальників починає виглядати завищеною на фоні граничної вартості написаного агентом аналога.

Друга загроза — ринок консалтингу з інтеграції застарілих ERP-систем. Мартін Зайферт, керівник з даних Pro Juventute, направив Claude Code з dltHub Pro на застарілу ERP-систему з 1 231 таблицею та нульовою документацією і описав цю роботу як «кілька хвилин на написання і кілька годин на виконання». Порівняйте зі стандартним залученням системного інтегратора для недокументованої ERP — зазвичай це місяці роботи і значний штат. Джерело не розкриває результати щодо якості даних і не вказує, скільки з 1 231 таблиці насправді мають референтну цілісність, що важливо, адже «пайплайни працюють» — це не те саме, що «пайплайни правильні».

Третя загроза, і та, про яку керівники аналітики мають думати в першу чергу: власна команда дата-платформи, яка два роки тому побудувала індивідуальний стек на базі Airflow та Python-прийому даних. Вартість обслуговування цього стека щойно була порівняна з code-first Python-нативною альтернативою, де 91% нових пайплайнів написані агентами. Обґрунтування штатного розкладу, написані у 2024 році, не переживуть бюджетного перегляду 2026 року без змін.

Ті, хто програє в наступні 90 днів, у порядку черговості: GUI-орієнтовані ELT-постачальники, що продають у Snowflake-акаунти, середньорівневі SI з інтеграції даних без агентної практики, а також будь-яка внутрішня команда платформи, у дорожній карті якої написання пайплайнів все ще описується як завдання старшого інженера.

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

Три конкретні дії цього тижня. По-перше, виміряйте поточну вартість створення пайплайнів. Візьміть нові коннектори або джерела за останній квартал, розділіть на витрачені інженеро-тижні — і ви отримаєте базовий показник вартості одного пайплайну. Без цього ви не зможете чесно оцінити жодну альтернативу з агентним написанням. Співвідношення Tasman (день проти тижня) — приблизно 10x. Ваш показник може бути 3x або 30x, але він має бути саме вашим.

По-друге, якщо ви вже використовуєте Snowflake, оцініть Native App від dltHub порівняно з вашим поточним шляхом реплікації принаймні для однієї операційної бази даних. Архітектурне питання, на яке потрібно відповісти, — не «чи це дешевше», а «чи достатньо змінює мою відповідність вимогам зберігання реплікації всередині акаунту, щоб вивести суб-процесора з SOC 2». Для регульованих вертикалей такий вихід часто коштує більше, ніж рядкова вартість.

По-третє, проведіть контрольований пілот з одним із підтримуваних агентних інструментів — Claude Code, Cursor або Codex — на одному некритичному джерелі. Виміряйте дві речі: час від специфікації до злитого PR та частку дефектів, виявлених на стейджингу. Другий показник — той, який більшість команд пропускає, і саме він визначає, чи є пайплайни, написані агентами, справжнім підсилювачем продуктивності, чи відкладеним рахунком за обслуговування.

Перевірюване прогнозування: команди, які впровадять робочий процес агент + dlt цього кварталу, мають побачити скорочення часу на написання коннекторів щонайменше у 5 разів протягом 60 днів. Якщо показник нижчий за 3x, вузьке місце знаходиться у перевірці та валідації, а не в написанні, і ваші інвестиції мають змінити напрямок відповідно.

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

• dltHub здобув нагороду Snowflake «Партнер року» 2026 3 червня 2026 року: понад 1 000 організацій використовують dlt зі Snowflake у продакшені із загальної кількості понад 10 000 користувачів dlt.
• Визначальна цифра: 91% з 81 000 нових щомісячних dlt-пайплайнів у січні 2026 року були написані агентами, проти 5% від 2 400 рік тому — загальне зростання обсягу у 34 рази та зростання кількості пайплайнів, написаних агентами, у 614 разів.
• Snowflake Native App для реплікації MSSQL, Oracle, MySQL і Postgres працює повністю всередині облікового запису Snowflake клієнта, усуваючи залежність від зовнішнього оркестратора, що визначає поточну економіку managed ELT.
• Підтверджені клієнти: Stellantis із 60 000 щомісячних пайплайнів, Sparebank1 як стандартний прийом даних у банківському альянсі та Flatiron Health із повідомленим скороченням витрат на пайплайни на 50%.
• Невідоме, за яким варто стежити: якість даних і частота дефектів на рівні одного пайплайну для робіт, написаних агентами, — це джерело не розкриває, а саме це визначає, чи є прискорення написання у 10 разів реальним або перенесеним на витрати наступної перевірки.