<span id="OSC_h1_1"></span>
核心观点 (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 并发场景下的性能：
| 数据库 | 总执行时间 (单并发) | 总执行时间 (5 并发) |
|---|---|---|
| Apache Cloudberry | 5335s | 21125s |
| Greenplum 6 | 6834s | 28255s |
| Greenplum 7 | 6088s | 24750s |
在顺序执行中，Apache Cloudberry 比 Greenplum 6 快约 22%，比 Greenplum 7 快约 12%。
鉴于 WarehousePG 和 Greengage 尚未展示出与其 Greenplum 7 基础有显著的性能偏差，因此未将其纳入本次基准测试。随着它们的演进，我们计划在未来的对比中加入它们。
社区与开发活跃度
虽然我不主张过分强调表面数据——更倾向于关注项目为用户带来的实际价值——但一些指标确实能直观地对比 Apache Cloudberry、GreengageDB 和 WarehousePG 的开发状态：
| 数据库 | Forks | Stars | 新提交数 (自首次 PR 起) |
|---|---|---|---|
| Apache Cloudberry | 185 | 1.1k | ~2630 |
| WarehousePG | 23 | 77 | ~71 |
| GreengageDB | 12 | 66 | ~127 |
当然，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 替代项目有所帮助。
附录：对比表
以下是总结关键差异的简明对比表：
| 维度 | Apache Cloudberry | WarehousePG | GreengageDB |
|---|---|---|---|
| 治理 | Apache 基金会 (厂商中立) | 单一厂商控制 | 单一厂商控制 |
| 社区 | 活跃、多元化的贡献者团队 | 厂商内部驱动 | 厂商内部驱动 |
| PostgreSQL 内核 | PostgreSQL 14 (正在升级至 16) | PostgreSQL 12 | PostgreSQL 12 |
| 内核升级计划 | 公开追踪，进行中 | 无公开信息 | 仅在网站提及 |
| 公开路线图 | 全面且详细 | 无 | 有限 (“目标特性”) |
| 新特性 | 丰富 (PAX, 动态表, AQUMV 等) | 信息有限 | 信息有限 |
| 性能 | 比 GP6 快 22%，比 GP7 快 12% | 无公开基准测试 | 无公开基准测试 |
| GitHub Stars | 1.1k | 77 | 66 |
| GitHub Forks | 185 | 23 | 12 |
| 提交数 (自首次 PR 起) | ~2630 | ~71 | ~127 |
| 迁移工具 | 提供 (cbcopy) | 未提供 | 未提供 |
| 可持续性风险 | 低 (Apache 治理) | 中-高 (依赖厂商) | 中-高 (依赖厂商) |
| 创新速度 | 高 | 低 | 低 |
| 透明度 | 高 (Apache 之道) | 有限 | 有限 |
结论：虽然这三个项目都为 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
</div>
