核心观点 (TL;DR)

• 核心风险：Greenplum 闭源后，最大的风险在于单厂商控制带来的治理和可持续性风险。

• 当前格局：我们分析了三个主要的 Greenplum 继任者：Apache Cloudberry (Incubating)、WarehousePG 和 Greengage。后两者仍由单一厂商控制，而 Cloudberry 是唯一由社区主导的选项。

• 解决方案：Apache Cloudberry (Incubating) 通过遵循中立的 "Apache 之道" 运作，确保了清晰的知识产权归属和公开的决策机制，从根本上解决了厂商锁定问题。

• 最终结论：对于寻求开放、持久且企业级的 MPP 数据库，并希望拥有现代内核和社区驱动演进的用户来说，Cloudberry 是最面向未来的选择。

2024 年 5 月，当 Greenplum 数据库突然归档并转为闭源开发时，现有的开源 Greenplum 用户社区面临着巨大的断档风险。失去了安全补丁、功能更新和性能改进，他们的 Greenplum 集群变成了脆弱的遗留资产。对于这些用户而言，寻找一个高度兼容、可持续发展的开源 Greenplum 替代方案至关重要，这不仅能最小化迁移成本，还能保留现有的工作流，避免团队面临额外的学习曲线。

随着 Greenplum 转为闭源，基于其原始代码库涌现出了三个主要的分支项目：Apache Cloudberry（目前最受关注）、WarehousePG（由 EnterpriseDB 发起）和 Greengage（由 Arenadata 发起）。社区用户经常询问这三个选项之间的异同以及选择标准。

本文将从多个维度对 Apache Cloudberry、WarehousePG 和 Greengage 进行全面对比，帮助用户做出明智的决策。

治理模式与社区可持续性

在归档之前，Greenplum 虽然技术上是开源的，但由单一厂商控制，缺乏开放的社区治理模式。这种结构使其极易受到公司开源战略转变的影响，最终导致了其从开源到闭源的突然转变——这一变化让社区开发者措手不及，也在整个生态系统中引发了震动。

虽然 WarehousePG 和 Greengage 都将其源代码托管在 GitHub 组织下，但这些仓库仍然由各自的发起公司拥有和控制。与 Apache Cloudberry 不同，它们缺乏可持续发展所需的坚实基础，并面临着导致 Greenplum 归档和闭源的同样潜在风险。即使你今天选择了 WarehousePG 或 Greengage 作为 Greenplum 的替代品，母公司商业策略的改变可能会迫使你再次面临同样的困境。此外，多个分支导致的力量分散会稀释生态系统；只有汇聚到一个真正开放、中立的平台上，我们才能最大化社区的生命力。

Apache Cloudberry 目前托管在 Apache 软件基金会孵化器下，每一位开发者都以个人身份参与，遵循厂商中立的原则。这从根本上为 Apache Cloudberry 的可持续发展奠定了坚实基础，消除了单一厂商锁定的风险，防止了 Greenplum 的命运重演。虽然理论上 Apache Cloudberry 即使在毕业成为 Apache 顶级项目后也可能退役（例如由于用户需求下降或社区贡献减少），但这种决定将由项目管理委员会（PMC）通过透明投票做出，不受任何厂商控制。

Apache Cloudberry 还受益于一个多元化、活跃且不断增长的 贡献者团队[1] 和参与度极高的用户社区——这是 WarehousePG 和 Greengage 难以比拟的优势。从目前的视角来看，Apache Cloudberry 拥有最强劲的长期可持续发展前景。

Apache Cloudberry 拥抱 Apache 的文化和治理模式（参见 The Apache Way[2] 和 How Apache Works[3]），遵守 Apache 行为准则[4] 和 安全策略[5]。这一框架为 Apache Cloudberry 的持续演进提供了强有力的保障。

PostgreSQL 内核

从诞生之初，Apache Cloudberry 的目标就是构建一个更现代的 Greenplum，而不是简单地复制和重塑品牌。PostgreSQL 内核是其关键基础之一。

目前，Greenplum 7 基于的 PostgreSQL 12 内核已于 2024 年 11 月达到生命周期终点（EOL）（参见 PostgreSQL 版本策略[6]）。Cloudberry 最初采用 PostgreSQL 14 作为基础。

升级 PostgreSQL 内核是一项极具挑战性的任务，需要深厚的技术专长和对内核的熟悉程度，涉及集成数千个上游 PostgreSQL 提交、解决冲突以及合并新的 PostgreSQL 特性——这并非任何团队都能轻易完成。

幸运的是，Cloudberry 的社区开发者目前正在推进从 PostgreSQL 14.x 到 PostgreSQL 16.x 的升级工作。你可以通过邮件列表或 GitHub Projects[7] 追踪这一持续了数月的工作进展。Cloudberry 团队计划在 2025 年底或 2026 年初完成这项工作，随后进行全面的测试和优化。

为了简化 PostgreSQL 内核的升级，Cloudberry 团队还对关键组件进行了模块化。例如，Interconnect 模块已从 cdb 模块中分离出来，以最大限度地减少对原生 PostgreSQL 内核的侵入，使未来的 PostgreSQL 升级更易于管理。

除了 Cloudberry 公开追踪的 PostgreSQL 内核升级工作外，我们尚未看到 WarehousePG 有类似的举措，GreengageDB 也未公开任何相关行动——仅在其官网主页上有相关的愿景声明。

路线图与新特性

如上所述，Apache Cloudberry 拥有清晰的开发 路线图[8]，它就像一张导航图，指引项目朝着目的地前进而不迷失方向。Apache Cloudberry 的路线图非常全面，涵盖了 Apache 孵化、内核升级、性能与易用性、可用性、质量保证、流处理/实时分析、湖仓一体解决方案、AI/ML、工具与生态系统、发布管理、网站与文档等多个方面。

相比之下，WarehousePG 在其网站或 GitHub 上均未提供路线图信息。Greengage DB 在其主页上提到了“目标特性”，但没有公开的线程来追踪进度，而且其列出的部分目标特性在 Cloudberry 中已经可用。

你可以通过邮件列表上的定期审查报告来追踪 Apache Cloudberry 的路线图进展。

以下是 Cloudberry 引入的一些新特性：

• PAX (行列混合存储引擎)[9]：专为处理海量数据摄入和频繁查询场景的复杂 OLAP 应用而设计。参见社区用户的 性能评测[10]。

• gpshrink[11]：用于集群缩容的系统工具。

• 动态表 (Dynamic Tables)[12]：支持近实时分析。

• MCP Server[13]：通过 AI 就绪的接口提供安全高效的数据库管理能力。

• 目录表 (Directory Tables)[14]：统一管理本地或对象存储上的非结构化数据。

• 增量物化视图 (Incremental Materialized Views)[15]：节省大量计算资源和时间，显著提高处理大数据集时的性能。

• 自动物化视图 (AQUMV)[16]：在规划阶段使用增量物化视图处理查询，非常适合能大幅减少处理时间的大表查询。

• 并行查询执行[17]：利用多 CPU 核心处理单个查询，根据数据量动态调整计算节点数量。特别适用于单台物理机上部署少量 Segment 的场景。

• 聚合下推[18]：将聚合操作移至更靠近数据源的位置，在 Join 操作之前处理聚合。

• RuntimeFilter[19]：在构建哈希表的同时构建 RuntimeFilter，以便在执行 HashJoin 之前过滤大表中的元组，使用布隆过滤器实现高效的内存使用和性能提升。

• 透明数据加密 (TDE)[20]：企业级数据安全。

• 密码策略[21]：基于配置文件的密码策略配置，用于控制用户密码安全，包括登录失败后的账户锁定和密码重用限制。

这仅代表了部分新特性和增强功能——许多错误修复和改进未在此列出。我们可以看到 WarehousePG 和 GreengageDB 上有一些错误修复和增强，但这两个项目都没有显著的新特性。

性能评测

性能是每个用户关注的重点。这里我们展示了 Apache Cloudberry、Greenplum 6.27.1 和 Greenplum 7.1.0 的 TPC-DS 基准测试结果。

TPC-DS 是由 TPC 开发的决策支持基准测试，模拟了决策支持系统的几个通用方面，包括查询和数据维护。它旨在提供一个全面且现实的工作负载，用于测试和评估零售环境中的数据库系统性能。

该基准测试针对 24 个表使用 1TB 数据量测试了 99 个复杂的 SQL 查询。主要的性能指标是查询响应时间——即从提交查询到接收结果的持续时间。

[!NOTE] 数据来源：此处展示的性能数据基于 SynxDB 4 的 TPC-DS 基准测试报告[22]。SynxDB 4 使用 Apache Cloudberry 作为内核，因此这些基准测试结果直接代表了 Apache Cloudberry 的性能能力。

下表显示了三个数据库在单并发和 5 并发场景下的性能：

在顺序执行中，Apache Cloudberry 比 Greenplum 6 快约 22%，比 Greenplum 7 快约 12%。

鉴于 WarehousePG 和 Greengage 尚未展示出与其 Greenplum 7 基础有显著的性能偏差，因此未将其纳入本次基准测试。随着它们的演进，我们计划在未来的对比中加入它们。

社区与开发活跃度

虽然我不主张过分强调表面数据——更倾向于关注项目为用户带来的实际价值——但一些指标确实能直观地对比 Apache Cloudberry、GreengageDB 和 WarehousePG 的开发状态：

当然，GreengageDB 和 WarehousePG 是在 2024 年或 2025 年才成立的，它们需要时间成长。然而，Apache Cloudberry 已经建立了独特且显著的优势。

Star History Chart

从过时 Greenplum 系统迁移

值得注意的是，Apache Cloudberry 搭载了更新的 PostgreSQL 内核和众多新特性。从旧版 Greenplum 7 迁移会因内核更新而不可避免地带来行为差异，但在一个已归档的系统上停滞不前并非长久之计。

此外，由于 Cloudberry 项目于 2022 年基于 Greenplum 7 beta 版本立项，而 Greenplum 在归档前一直在更新，Cloudberry 开发者花费了 2~3 个月的时间将大多数 Greenplum 更新同步到 Cloudberry 中。然而，一些不符合 Cloudberry 发展方向的变更未被合并。因此，虽然 Cloudberry 与归档的 Greenplum 版本保持高度兼容，但并非 100% 兼容。

鉴于 Cloudberry 与旧版 Greenplum 7 之间 PostgreSQL 内核版本的差异，加上众多新特性，从 Greenplum 迁移到 Cloudberry 无法通过简单的二进制替换完成。请注意，WarehousePG 或 GreengageDB 的二进制替换仅在同一主版本内切换时可行（例如，从 Greenplum 7 切换到它们的 v7 分支）。如果你是从 Greenplum 6 升级到它们基于 v7 的版本，二进制替换是不可行的，你仍然面临数据迁移过程——但却无法享受专用工具带来的便利。

为了解决这一挑战，Apache Cloudberry 社区提供了 cbcopy[23]，这是一个强大且便捷的迁移工具，支持：

• 从 Greenplum 4.x 到 7.x 迁移至 Cloudberry 2.x：支持整个 Greenplum 版本谱系的用户无缝迁移到 Cloudberry。

• Cloudberry 版本升级：支持从 Cloudberry 1.x 升级到 2.x，确保 Cloudberry 生态系统内的平滑版本过渡。

WarehousePG 和 Greengage 均未提供类似的迁移工具，用户只能手动管理复杂的迁移过程。虽然 cbcopy 需要一次性的数据迁移工作，但它打破了旧内核的束缚，开启了通往现代 PostgreSQL 特性和可持续未来的大门——与其停留在过时的分支上，不如大胆的接受 Apache Cloudberry 带来的新特性，这是一笔值得的投资。

不过，对于 Cloudberry 同一主版本系列内的更新，我们确保你可以通过二进制文件替换进行升级。

未来格局

归档后的 Greenplum 世界呈现出复杂的格局。据我观察，EnterpriseDB 最近刚刚进入这一领域，Arenadata 曾是开源 Greenplum 项目的积极贡献者，而 Apache Cloudberry 团队则包含了更多原 Greenplum 核心开发者。

目前，继续缓慢推进基于 Greenplum 的遗留系统是一个可行的策略，但随着时间推移，Greenplum 遗留代码库的价值将持续缩水。未来的创新需要技术远见和工程能力来推动这一基于 PostgreSQL 的 MPP 技术流向前发展，而 Apache Cloudberry 无疑正在引领潮流并日益壮大。

那么，它们最终会融合吗？融合通常发生在最活跃、最开放的上游周围。对于 WarehousePG 和 GreengageDB，它们的路径将由其厂商控制。如果它们选择将工作贡献给 Apache Cloudberry，那将是对所有原 Greenplum 用户的巨大价值。然而，如果它们继续沿着当前的路径走下去，分化是不可避免的。

Apache Cloudberry 目前托管在 Apache 孵化器下，真正消除了导致 Greenplum 归档和闭源的因素。它倡导透明，遵循 Apache 之道，保持开放，为全球开发者协作提供开放平台，是最具包容性的选择。

作为 Apache Cloudberry PPMC 成员，我邀请每一位希望参与 Apache Cloudberry 项目的开发者——无论是通过代码还是非代码贡献。我们有许多领域迫切需要改进。让我们携手共建更强大的 Apache Cloudberry！

如果你对上述内容有任何反馈或建议，请留言。我们期待更多的声音。希望这篇文章对你选择 Greenplum 替代项目有所帮助。

附录：对比表

以下是总结关键差异的简明对比表：

结论：虽然这三个项目都为 Greenplum 用户提供了替代选项，但 Apache Cloudberry 凭借其厂商中立的治理、活跃的社区、现代 PostgreSQL 内核、全面的路线图、丰富的新特性以及卓越的性能脱颖而出。对于寻求可持续、创新且社区驱动的已归档 Greenplum 替代方案的用户来说，Apache Cloudberry 是最具吸引力的选择。

欢迎加入 Apache Cloudberry

• 访问官网：https://cloudberry.apache.org

• 关注 GitHub：https://github.com/apache/cloudberry

• 加入 Slack：https://apache-cloudberry.slack.com

• 开发者邮件列表：https://cloudberry.apache.org/community/mailing-lists

参考资料

[1] 

贡献者团队: https://cloudberry.apache.org/team

[2] 

The Apache Way: https://apache.org/theapacheway/

[3] 

How Apache Works: https://apache.org/foundation/how-it-works/

[4] 

行为准则: https://www.apache.org/foundation/policies/conduct

[5] 

安全策略: https://github.com/apache/cloudberry/blob/main/SECURITY.md

[6] 

PostgreSQL 版本策略: https://www.postgresql.org/support/versioning/

[7] 

GitHub Projects: https://github.com/orgs/apache/projects/497

[8] 

路线图: https://github.com/apache/cloudberry/discussions/868

[9] 

PAX (行列混合存储引擎): https://cloudberry.apache.org/docs/operate-with-data/pax-table-format

[10] 

性能评测: https://github.com/apache/cloudberry/discussions/1421

[11] 

gpshrink: https://cloudberry.apache.org/docs/sys-utilities/gpshrink

[12] 

动态表 (Dynamic Tables): https://cloudberry.apache.org/docs/performance/use-dynamic-tables

[13] 

MCP Server: https://github.com/apache/cloudberry/tree/main/mcp-server

[14] 

目录表 (Directory Tables): https://cloudberry.apache.org/docs/advanced-analytics/directory-tables

[15] 

增量物化视图 (Incremental Materialized Views): https://cloudberry.apache.org/docs/performance/optimize-queries/use-incremental-materialized-view

[16] 

自动物化视图 (AQUMV): https://cloudberry.apache.org/docs/performance/optimize-queries/use-auto-materialized-view-to-answer-queries

[17] 

并行查询执行: https://cloudberry.apache.org/docs/performance/optimize-queries/parallel-query-execution

[18] 

聚合下推: https://cloudberry.apache.org/docs/performance/optimize-queries/use-aggre-pushdown-to-speed-up-queries

[19] 

RuntimeFilter: https://cloudberry.apache.org/docs/performance/optimize-queries/use-runtimefilter-to-optimize-queries

[20] 

透明数据加密 (TDE): https://cloudberry.apache.org/docs/security/transparent-data-encryption

[21] 

密码策略: https://cloudberry.apache.org/docs/security/set-password-profile

[22] 

SynxDB 4 的 TPC-DS 基准测试报告: https://docs.synxdata.com/synxdb-4/product-overview/tpc-ds-benchmark-report.html

[23] 

cbcopy: https://github.com/cloudberry-contrib/cbcopy