Airbyte бесплатен, а вот память и CPU под его коннекторы — нет

MAATRIX

«Поставим Airbyte на недорогой VPS и настроим пару коннекторов — бесплатная синхронизация данных готова» — логика, которая держится ровно до третьей одновременно запущенной синхронизации. Сам Airbyte действительно open-source и не берёт денег за платформу как таковую. Но платформа — это диспетчер: реальную работу по вычитыванию и записи данных делают отдельные коннекторы, каждый из которых запускается как отдельный процесс со своей памятью и CPU. Один коннектор на маленьком VPS работает незаметно. Пять коннекторов, запущенных параллельно по расписанию в три часа ночи, — это уже нагрузка, для которой сервер, купленный «под Airbyte», может внезапно не хватить. Разберём, из чего на самом деле складывается стоимость владения self-hosted Airbyte.

Что в Airbyte действительно бесплатно

Ядро Airbyte и подавляющее большинство коннекторов распространяются с открытой лицензией, и запуск self-hosted инсталляции не требует платежей за сам продукт — в отличие от облачной версии Airbyte Cloud, где цена считается по объёму синхронизируемых данных. Это реальная экономия, особенно на больших и регулярных объёмах: если бизнес гоняет через ELT-пайплайн терабайты в месяц, разница со счётом от облачного сервиса может быть существенной.

Но бесплатна именно лицензия на управляющую платформу — веб-интерфейс, планировщик, каталог коннекторов. Сама синхронизация данных — это не строчка в конфиге, а выполняемая работа: чтение из источника, передача через сеть, запись в приёмник. Эта работа потребляет ресурсы сервера независимо от того, платите вы за лицензию или нет, и именно она — основная статья расходов, которая не видна на этапе установки:

• сервер под саму платформу — веб-приложение, планировщик, внутренняя база метаданных;
• ресурсы под каждый активный коннектор — отдельный контейнер на источник и отдельный на приёмник для каждой запущенной синхронизации;
• сеть и диск — трафик между источником, Airbyte и приёмником, а также временное хранение данных в процессе передачи;
• время администратора — обновления коннекторов, разбор упавших синхронизаций, настройка расписаний так, чтобы они не накладывались друг на друга.

Ни один из этих пунктов не указан на странице «open source, бесплатно» — потому что формально это действительно так. Но сервер под Airbyte считается не по цене лицензии, а по сумме ресурсов, которые реально забирают запущенные синхронизации.

Архитектура: почему коннектор — это отдельный процесс, а не строчка конфига

Airbyte построен по протоколу, в котором источник и приёмник — независимые исполняемые модули, а не встроенные функции ядра. Платформа (веб-сервер, планировщик, внутренняя оркестрация) запускает исходный коннектор как отдельный процесс — в Docker-развёртывании это контейнер, в актуальных для 2026 года инсталляциях через abctl это под в локальном Kubernetes-кластере. Коннектор-источник читает данные и построчно пишет JSON-сообщения в стандартный вывод, коннектор-приёмник читает их со своего стандартного ввода и пишет в целевую систему. Между ними, в зависимости от версии и конфигурации, может стоять ещё и шаг нормализации данных.

Отсюда то, что часто упускают при прикидке «сколько нужно сервера»: у каждой активной синхронизации — минимум два одновременно работающих процесса, каждый со своим потреблением памяти и CPU, независимо от того, насколько лёгкая сама платформа в состоянии простоя. А именно в состоянии простоя сервер и находится в момент, когда вы его выбираете и тестируете — реальная нагрузка проявляется только тогда, когда запускается первое расписание с несколькими коннекторами сразу.

Это принципиально отличается от инструмента, который просто выполняет SQL-запрос по расписанию: там нагрузка — это один запрос к базе. Здесь нагрузка — это запуск изолированного процесса для источника, изолированного процесса для приёмника, и передача через них потока данных, который сам по себе буферизуется в памяти на объёмы, зависящие от размера отдельных записей и настроек батчинга конкретного коннектора.

Airbyte — это не Airflow: разные задачи, разная нагрузка

Читатели, ищущие «self-hosted Airbyte», часто параллельно натыкаются на Apache Airflow, и путаница между ними — источник неверных ожиданий по ресурсам. Это разные инструменты для разных задач:

• Airflow — оркестратор произвольных пайплайнов и задач. Вы описываете граф зависимостей (DAG) из шагов, которые могут быть чем угодно: SQL-запрос, вызов API, скрипт на Python, отправка файла. Airflow не знает заранее, что именно вы будете делать — он просто планирует и запускает ваш код по расписанию и зависимостям.
• Airbyte — узкоспециализированный ELT-инструмент. У него одна задача: перекачать данные из источника в приёмник через готовый коннектор из каталога. Вы не пишете код синхронизации сами — вы выбираете источник (например, PostgreSQL, REST API, Google Sheets) и приёмник (например, ClickHouse, BigQuery, Snowflake) и настраиваете параметры конкретного коннектора.

На практике оба инструмента нередко работают в связке: Airbyte выполняет синхронизацию, а Airflow запускает её как один из шагов более широкого пайплайна — например, «сначала синхронизировать данные через Airbyte, потом трансформации в dbt, потом обновить дашборд». Ресурсы при этом считаются раздельно: Airflow сам по себе — планировщик и веб-интерфейс с предсказуемой базовой нагрузкой, а всплеск памяти и CPU от передачи данных даёт именно Airbyte и его коннекторы. Оценивая сервер под связку из двух инструментов, считайте ресурсы коннекторов Airbyte отдельной и основной статьёй, а не довеском к Airflow.

Сколько ресурсов нужно на практике

Здесь и кроется главная путаница из документации: официальные минимальные требования обычно описывают платформу в состоянии покоя, а не реальную нагрузку при синхронизациях. Разделим это на слои — ниже ориентировочные величины, которые стоит проверять на собственных коннекторах, а не воспринимать как гарантированный порог:

Базовый слой — платформа без единой активной синхронизации. Веб-сервер, внутренняя оркестрация, база метаданных — фиксированная нагрузка, которая есть всегда. На небольшом наборе коннекторов с редкими синхронизациями платформе обычно достаточно 2 ядер CPU и 4-8 ГБ RAM только под неё саму — без учёта того, что происходит во время самих синков.

Слой синхронизации — один активный коннектор. Пока идёт синхронизация, добавляется память и CPU конкретной пары источник-приёмник. Лёгкие коннекторы (чтение небольшой REST API-таблицы с пагинацией) добавляют скромную нагрузку. Тяжёлые — чтение большой таблицы полным снимком (full refresh), сложные вложенные JSON-структуры, коннекторы, буферизующие записи пачками перед отправкой, — способны на время синхронизации ощутимо превысить базовую нагрузку платформы, иногда в разы. Точная цифра зависит от конкретного коннектора и объёма таблицы — проверяйте на реальном источнике, а не по общей оценке.

Слой параллелизма — несколько синхронизаций одновременно. Вот где расчёт «платформа плюс немного сверху» перестаёт работать. Если в одно окно (типично — ночью) стартуют сразу несколько синхронизаций, их ресурсы складываются, а не усредняются. Пять параллельных синхронизаций — это до десяти одновременно работающих процессов коннекторов (источник плюс приёмник на каждую), и если хотя бы пара из них — тяжёлые full refresh больших таблиц, суммарное потребление памяти может кратно превысить то, на что рассчитывался сервер под требования одной лишь платформы.

Практический вывод: закладывайте запас не под платформу, а под пиковое число одновременно выполняемых синхронизаций, и разносите расписания по времени там, где это возможно — дешевле, чем докупать память под сервер, простаивающий 23 часа в сутки ради часа пиковой нагрузки. Общие принципы такого расчёта — в материале как рассчитать конфигурацию сервера под нагрузку: для Airbyte пик формируется числом одновременных синхронизаций, а не числом настроенных коннекторов вообще.

Normalization, большие таблицы и приёмники: где память проседает незаметно

Помимо самого переноса данных, есть частные случаи, заметно увеличивающие требования к ресурсам сверх базового расчёта:

• Нормализация и типизация данных. В более старых версиях Airbyte это был отдельный шаг на базе dbt после загрузки сырых данных в приёмник; в новых версиях типизация и дедупликация встроены в сам процесс синхронизации у части коннекторов-приёмников. Точная схема зависит от версии — сверяйтесь с документацией, но держите в уме: между «данные загружены» и «данные готовы к использованию» может быть ещё один этап обработки, потребляющий ресурсы отдельно от передачи.
• Full refresh против incremental. Полная пересинхронизация таблицы тяжелее по памяти и трафику, чем инкрементальная синхронизация только изменённых записей. Если источник поддерживает инкрементальный режим (по timestamp-полю или через CDC), настройте именно его — это снижает нагрузку и на Airbyte, и на сам источник.
• Приёмник тоже под нагрузкой. Запись большого объёма в PostgreSQL или ClickHouse — нагрузка на сам приёмник, а не только на Airbyte. Если приёмник на том же сервере, пиковая нагрузка синхронизации бьёт по обоим сразу. Базовые принципы установки целевой базы — в материале как установить и настроить PostgreSQL на VPS; закладывайте запас именно под пиковую запись во время синхронизации, а не только под обычную нагрузку базы.
• Схема источника усложняет расчёт. Таблицы с большим числом столбцов, вложенными JSON-полями или бинарными данными увеличивают объём каждой записи и память, которую коннектор держит в буфере. Два коннектора с одинаковым числом строк в источнике могут потреблять разную память просто из-за формы данных.

Как и с любым многоконтейнерным сервисом, стоит явно ограничивать ресурсы каждого коннектора через лимиты, а не полагаться на то, что хост сам справедливо распределит память между платформой и временными коннекторами. Как это делается на уровне Docker — в материале Docker: лимиты CPU и памяти для контейнеров: без явных лимитов один тяжёлый коннектор при параллельной синхронизации способен вытеснить по памяти саму платформу или соседние сервисы на том же сервере.

Считаем TCO: во что реально обходится self-hosted Airbyte

Сведём статьи расходов в таблицу — не как замену расчёту под ваши конкретные коннекторы, а как чек-лист того, что стоит учесть до, а не после переезда с облачного Airbyte Cloud или другого managed ELT-сервиса:

Self-hosted Airbyte оправдан, если у вас достаточно предсказуемый и не слишком широкий набор коннекторов, есть кому следить за расписаниями и ресурсами, а объём данных достаточно велик, чтобы разница со счётом Airbyte Cloud была ощутимой в деньгах. Он менее оправдан, если коннекторов много, они запускаются хаотично без явного планирования окон синхронизации, а сервер выбирался по минимальным требованиям к платформе без запаса под пиковый параллелизм — именно этот сценарий чаще всего приводит к внезапным OOM-ситуациям на сервере, который «на бумаге» вполне подходил под задачу.

Похожая по логике, но другая по предметной области статья о полной стоимости самостоятельного хостинга — TCO Mayan EDMS: там основная скрытая статья расходов — распознавание текста и обучение сотрудников, здесь — параллельная нагрузка на CPU и память от одновременных синхронизаций. Логика в обоих случаях одна: бесплатная лицензия — не то же самое, что бесплатная эксплуатация.

Частые вопросы