dltHub получает награду Snowflake «Партнёр года» 2026

3 июня 2026 года в 18:15 по центральноевропейскому времени на конференции Snowflake Summit 2026 компания dltHub получила награду Snowflake Startup Program Product Partner of the Year 2026. Главное — сама награда. Но цифра, заслуживающая пристального внимания, спрятана в двух абзацах пресс-релиза: в январе 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.

Продуктовая часть объявления: Snowflake Native App, обеспечивающее репликацию из MSSQL, Oracle, MySQL и PostgreSQL, при этом весь пайплайн работает внутри аккаунта Snowflake клиента без внешнего оркестратора. Эми Кодл, старший вице-президент по глобальным альянсам и каналам в 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 сделал для трансформации, нежели к классическому GUI для ETL.

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

Если эта архитектура устоит, я ожидаю, что категория Snowflake Marketplace Native App увидит как минимум трёхкратный рост производственных нагрузок на репликацию в ближайшие четыре квартала, а традиционные поставщики управляемого ELT будут заметно терять объявления о новых клиентах в регулируемых отраслях.

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

Наиболее очевидный удар придётся по категории управляемого ELT. Кейс Tasman Analytics, упомянутый в релизе, — это именно та точка данных, которая разрушает разговор о продлении контракта с Fivetran: 20 минут от документации API до работающего пайплайна против примерно двух недель раньше. Инженер среднего уровня в консалтинговой компании примерно из 20 человек в Амстердаме и Лондоне теперь выпускает готовый к производству REST API-коннектор за один день — работа, которая раньше занимала у старшего инженера неделю. Если это соотношение окажется универсальным, логика поштучного ценообразования GUI-ориентированных вендоров начнёт выглядеть несоответствующей по сравнению с предельными затратами на написанный агентом эквивалент.

Второй удар придётся по рынку консалтинга по интеграции устаревших ERP-систем. Мартин Зайферт, руководитель по данным в Pro Juventute, направил Claude Code с dltHub Pro на устаревшую ERP-систему с 1 231 таблицей и нулевой документацией и описал работу как «несколько минут на написание и несколько часов на выполнение». Сравните это со стандартным ангажементом SI для недокументированной ERP, который обычно измеряется месяцами и количеством задействованных сотрудников. Источник не раскрывает результаты по качеству данных и то, сколько из 1 231 таблицы действительно имеют ссылочную целостность — а это важно, поскольку «пайплайны работают» — не то же самое, что «пайплайны корректны».

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

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

План действий для команд по данным

Три конкретных действия на эту неделю. Первое: измерьте текущие затраты на создание пайплайнов. Возьмите данные за последний квартал по новым коннекторам или источникам данных, разделите на затраченные инженерные недели — это даст вам базовую стоимость одного пайплайна. Без этого вы не сможете честно оценить ни одну агентную альтернативу. Соотношение Tasman (один день против одной недели) — примерно 10x. Ваш показатель может быть 3x или 30x, но это должна быть именно ваша цифра.

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

Третье: проведите контролируемый пилот с одним из поддерживаемых агентных инструментов — Claude Code, Cursor или Codex — на одном некритическом источнике. Измерьте два показателя: время от спецификации до слитого PR и частоту дефектов, выявленных на стадии staging. Второй показатель — тот, который большинство команд пропускает, и именно он определяет, являются ли пайплайны, написанные агентами, реальным умножителем производительности или отложенными затратами на обслуживание.

Проверяемый прогноз: команды, внедрившие рабочий процесс агент плюс 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 клиента, устраняя зависимость от внешнего оркестратора, которая определяет экономику современного управляемого ELT.
• Подтверждённые примеры клиентов: Stellantis с 60 000 пайплайнов в месяц, Sparebank1 как стандарт приёма данных в банковском альянсе и Flatiron Health с сокращением затрат на пайплайны на 50%.
• Неизвестные факторы для отслеживания: качество данных и частота дефектов в пайплайнах, созданных агентами, — источник не раскрывает эти данные, а именно они определяют, является ли 10-кратное ускорение создания реальным или просто перекладывает затраты на последующую проверку.