Greenplum много лет был в опенсорсе на GitHub под лицензией Apache 2.0. Казалось бы, лицензия Apache 2.0, что может пойти не так? Осенью 2023 года репозиторий неожиданно перестал принимать наши пул‑реквесты.

Формально для того, чтобы контрибьютить в Greenplum, нужно подписать с ними Contributor license agreement. Но все наши CLA отозвали, а новые не подтвердили без каких‑либо пояснений.

Публичные обращения в GitHub и в рассылку, а также личные сообщения ребятам из команды Greenplum остались без ответа. А в мае 2024-го репозиторий был закрыт. У нас нет претензий к ребятам из Greenplum, но много вопросов к корпорации. 

Да, к опенсорс‑проекту могут потерять интерес — и он окажется заброшен. Но здесь, по сути, присвоили наши пул‑реквесты (теперь их даже не найти в закрытом gpdb‑archive!), изменив лицензию у кода, который мы написали, просто потому, что «ничего личного, это бизнес». Обстоятельства менялись, и вот — новые правила использования БД. Твои опыт и достижения либо присваиваются корпорацией, либо обнуляются.

В этой статье попробую проанализировать, где вчерашние пользователи и контрибьюторы в Greenplum могут найти решения, у которых есть будущее.

Коротко о сегодняшнем положении дел

Если есть стабильно работающий кластер Greenplum, зачем что‑то менять? Ответ прост — моральное и физическое устаревание. Да, сейчас всё работает, но требования не стоят на месте: понадобится Apache Iceberg, новая версия Rocky Linux 10, фиксы безопасности, поддержка нового железа и форматов данных, улучшения в performance… Без всего этого кластер постепенно превратится в утиль. Рано или поздно всё равно придётся мигрировать.

Чтобы затраты на миграцию и вмешательство в существующие операционные процессы были минимальными, альтернатива должна быть в опенсорсе, устойчиво развиваться и, главное, хорошо совмещаться с Greenplum.

После сегментации Greenplum возникло три форка оригинальной кодовой базы: 

• Apache Cloudberry™ (мой выбор);

• WarehousePG от компании EnterpriseDB;

• Greengage DB, инициированный Arenadata.

Чем они отличаются? В чём, наоборот, похожи? И что всё‑таки выбрать? Я как Apache Cloudberry commiter, конечно, рекомендую Apache Cloudberry. Ниже поясню подробнее, зачем я выбрал этот проект и почему верю в него. 

Модель управления и устойчивость сообщества

До сегментации Greenplum технически был в опенсорсе, но модель управления сообществом не была открытой: решение контролировал единственный вендор. Именно эта стратегия сделала проект уязвимым к изменениям корпоративной стратегии, что застало пользователей и контрибьюторов врасплох. 

WarehousePG и Greengage DB хранят исходный код на GitHub — их репозитории считаются собственностью компаний‑инициаторов, EnterpriseDB и Arenadata. К тому же, в отличие от Apache Cloudberry, им не хватает основы для устойчивого развития. Это значит, что они сталкиваются с теми же потенциальными рисками, которые привели к архивированию и закрытию Greenplum. 

Если выбрать WarehousePG или Greengage DB в качестве альтернативы Greenplum сегодня, в будущем нет гарантий, что изменение бизнес‑стратегии материнской компании не столкнёт вас с новым закрытием ПО, как уже было с Greenplum. 

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

Apache Cloudberry сегодня размещается в инкубаторе Фонда программного обеспечения Apache (Apache Software Foundation) — каждый разработчик участвует в нём как частное лицо, не как представитель вендора, и не получает денег за своё участие в проекте. Теоретически Apache Cloudberry может закрыться даже после выхода из инкубатора или получив статус топового проекта Apache. Но решение о закрытии в таком случае будет приниматься путём прозрачного голосования людей из комитета по управлению проектом (Project Management Committee) без какого‑либо контроля со стороны вендоров.

Наш комитет по управлению проектом поимённо перечислен на сайте проекта. В него вошли люди из разных компаний и стран. Можно убедить их всех сделать что‑то, но нельзя заставить. 

Список продолжает расширяться. Недавно я тоже вошёл в комитет по управлению, и мы добавили 7 новых разработчиков в коммитеры. Прямо сейчас всё это даёт большие перспективы для обеспечения долгосрочной устойчивости.

Ядро PostgreSQL

С момента создания цель Apache Cloudberry — не просто копирование и ребрендинг, а построение более современной версии Greenplum. Ядро PostgreSQL служит одним из его критически важных фундаментов.

PostgreSQL 12, которое использовали в последнем Greenplum 7, достигло конца жизненного цикла в ноябре 2024 года — см. Политику версионирования PostgreSQL. 

Обновить ядро PostgreSQL очень сложно. Для этого нужно: 

• Интегрировать тысячи коммитов из апстрима. Даже внутри одной версии, между 14.4 и 14.22 diff составляет более 1500 коммитов. Между версиями — ещё выше. К тому же ветки PG14 и PG16 несовместимы: разработчики PG пишут разные патчи для них. 

• Разрешить все конфликты. Это место, где нужна работа всего сообщества: выполнить адаптацию огромного количества изменений. 

• Внедрить новые возможности. Обновление ядра делает всю систему нестабильной, и чем больше сообщество и больше разных инсталляций, тем быстрее мы сможем стабилизировать релиз.

Cloudberry изначально построен на PostgreSQL 14 и скоро обновится до 16-й версии — целимся в лето 2026-го. Чтобы следующие апдейты происходили быстрее и проще, мы вынесли ключевые компоненты Cloudberry в extensions. Например, появился новый extension — Interconnect из ядра backend/cdb. 

Вся разработка ведётся на GitHub, текущий статус можно посмотреть в проекте https://github.com/orgs/apache/projects/497. А код и PR — в ветке https://github.com/apache/cloudberry/tree/cbdb‑postgres‑merge. Сейчас в ней 6216 новых коммитов по сравнению с main.

Создатели WarehousePG и Greengage DB пока только заявили о намерениях обновить ядро PG на главных страницах своих сайтов. Действительно ли ведётся работа, что и как было сделано, на каком этапе сейчас разработка, как принимаются те или иные технические решения — доступной публичной информации найти не удалось.

Роадмап и новые фичи

Основная проблема Greenplum, как сказал Andy Pavlo ещё в 2024-м, — никто больше не ставит его добровольно. Мы хотим это изменить. В нашем roadmap инкубация в Apache, обновления ядра, производительность и удобство использования, доступность, обеспечение качества, потоковая обработка/аналитика в реальном времени, решения Lakehouse, AI/ML, инструментарий и экосистема, управление релизами, веб‑сайт и документация — это не полный список.

WarehousePG не публикуют свои планы ни на официальном сайте, ни на GitHub. Greengage DB упоминает «Целевые характеристики» на своей главной странице, но не предлагает публичных обсуждений для отслеживания прогресса. 

Что уже сделано в Apache Cloudberry:

• PAX (гибридный движок хранения строк и столбцов) для сложных OLAP‑приложений, обрабатывающих массивный ввод данных и частые запросы. 

• gpshrink — системная утилита для уменьшения кластеров (scaling in).

• Динамические таблицы, которые обеспечивают анализ почти в риалтайме.

• MCP‑сервер с безопасным и эффективным управлением базами данных через интерфейсы, готовые к работе с ИИ.

• Таблицы каталогов — единое управление неструктурированными данными в локальном или объектном хранилище.

• Инкрементальные материализованные представления, которые экономят значительные вычислительные ресурсы и время, одновременно повышая производительность при работе с большими объёмами данных. 

• Автоматические материализованные представления (AQUMV) — замена таблиц на материализованные представления на этапе планирования для быстрого взаимодействия с большими таблицами.

• Параллельное выполнение запросов, чтобы динамически регулировать количество вычислительных узлов в зависимости от объёма данных, не ограничивать параллельность числом сегментов на ноде. 

• Aggregation Pushdown — перемещение агрегации до операций соединения, ближе к источнику данных.

• RuntimeFilter создаётся параллельно с хеш‑таблицей для фильтрации кортежей из больших таблиц перед выполнением HashJoin. Фильтры Блума обеспечивают эффективное использование памяти и повышение производительности.

• Прозрачное шифрование данных на корпоративном уровне.

• Политика паролей основана на профилях — для контроля безопасности паролей пользователей, включая блокировку учётной записи после неудачных попыток входа.

Это лишь часть новых функций и улучшений. Главное отличие от WarehousePG и Greengage DB — вы можете влиять на roadmap. Необязательно предлагать что‑то крупное, можно сосредоточиться на небольшой, важной для вас функциональности. 

Например, есть платная утилита по управлению логическими бэкапами Greenplum. А есть её опенсорс‑аналог — gpbackman. Автор этой утилиты — woblerr (огромное ему спасибо за вклад в сообщество!) добавил gpbackman в репозиторий Apache Cloudberry и продолжает разработку уже в нём.

Интересно, что проекты WarehousePG и Greengage DB практически идентичны: оба основаны на Greenplum 7, но разработку ведут параллельно. Огромное количество коммитов — багфиксы. Две команды буквально делают одно и то же, но в разных репозиториях. Было бы здорово здесь объединить усилия, а не пытаться получить как можно больше контроля над проектом, который и так уже стагнирует.

Перформанс на бенчмарках

Давайте посмотрим, как изменения в ядре влияют на производительность. Команда SynxData, которая продаёт Greenplum в Европе, сравнила Apache Cloudberry, Greenplum 6.27.1 и Greenplum 7.1.0 на бенчмарке TPC-DS. 

Тест TPC-DS создан специально для аналитических баз данных: моделирует несколько общеприменимых аспектов систем поддержки принятия решений, включая выполнение запросов и обслуживание данных, а потом обеспечивает комплексную и реалистичную нагрузку для тестирования и оценки производительности. 

Во время прохождения бенчмарка кластеры должны выполнить 99 сложных SQL-запросов к 24 таблицам на объёме данных 1 ТБ. Основная метрика производительности — время отклика на запрос, от отправки до получения результата.

Производительность трёх баз данных в сценариях с одной одновременной задачей и с пятью одновременными задачами из отчёта о бенчмарке TPC-DS для SynxDB 4:

Поскольку SynxDB 4 использует Apache Cloudberry в качестве ядра, эти результаты бенчмарка напрямую отражают возможности производительности Apache Cloudberry.

При последовательном выполнении Apache Cloudberry примерно на 22% быстрее, чем Greenplum 6, и примерно на 12% быстрее, чем Greenplum 7.

У WarehousePG и Greengage DB нет публичных результатов TPC‑DS. Скорее всего, они будут близки к Greenplum 7, но буду рад ошибиться.

Активность комьюнити и разработчиков

Цифры говорят сами за себя — Cloudberry развивается быстрее и активнее, чем WarehousePG и Greengage DB. Цифры из конца 2025 года, с тех пор ребята немного ускорились, но принципиально ничего не изменилось.

Также можно посмотреть на количество звёзд проекта:

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

Вот сколько коммитов было в оригинальном репозитории Greenplum:

Пик пришёлся на 2017–2018, потом — стагнация и закрытие проекта. В Apache Cloudberry мы стремимся к активности тех лет в оригинальном репозитории Greenplum.

В заключение

Причин выбрать Cloudberry вместо Greenplum много. Вот они все ещё раз, сверху вниз:

Но главная из всех этих причин — сегодня Cloudberry лучше всех умеет работать с комьюнити. Точно лучше, чем Greenplum. 

Спасибо, что дочитали до конца. Куда мигрируете из Greenplum вы? Расскажите в комментариях.

Добро пожаловать в Apache Cloudberry!

• Сайт: https://cloudberry.apache.org

• GitHub: https://github.com/apache/cloudberry

• Slack: https://join.slack.com/t/asf‑cloudberry/shared_invite/zt-3um34r7hf‑Sh~6jG6hVxlQJo1tbhK2sw

• Рассылка для разработчиков:https://cloudberry.apache.org/community/mailing‑lists