来源：https://www.gabrielebartolini.it/articles/2026/05/cloudnativepg-and-crunchy-pgo-an-honest-opinionated-comparison/

CloudNativePG 与 Crunchy PGO：一个诚实且带有主观见解的比较

作者: Gabriele Bartolini
日期: 2026年5月18日

目录

• Crunchy 的开创性角色
• 架构分水岭
• 直接 Pod 管理
• 实例管理器
• 关于 Kubernetes API 服务器可用性
• 镜像设计、体积与安全
• 主版本升级
• 备份与恢复
• 可观测性
• 社区健康与治理
• 我诚实的结论

本文比较了 CloudNativePG 和 Crunchy PGO，这两个在 Kubernetes 上运行 PostgreSQL 时最受欢迎的开源 operator。文章涵盖架构、镜像设计、备份策略、主版本升级、可观测性、许可和社区健康。作为 CloudNativePG 的联合创始人和维护者，我事先声明我不声称自己是中立的。我能提供的是基于多年在该项目上的日常工作和对这个领域 Crunchy Data 所构建成就的真正尊重，从而形成的知情偏见。

多年来，我一直抵制直接比较 CloudNativePG 和 Crunchy PGO。从我的位置来看，写这种文章感觉不太合适。但在两个项目都成熟了几年之后，特别是自从 Crunchy Data 被 Snowflake 收购以来，我越来越频繁地被问到这两个 operator 如何比较。我现在认为时机成熟了。上周，我写了“食谱 24”来回答如何迁移这个实际问题。这篇帖子尝试做一件更难的事情：诚实地评估这两个 operator 为何不同，以及这些差异对在 Kubernetes 上为 PostgreSQL 选择长期平台的团队意味着什么。

我将承认 Crunchy 的遗产，解释我认为使 CloudNativePG 成为更坚实基础的那些架构选择，指出存在的数据，并标明我个人观点不可避免的主观领域。我不会假装这是一份中立的文档。

Crunchy 的开创性角色

Crunchy Data 于 2017 年 3 月发布了第一个用于 Kubernetes 的 PostgreSQL operator，距离 Kubernetes 本身问世不到两年，距离 CoreOS 引入 operator 模式也仅过去不久。这确实具有超前意识。我在 2ndQuadrant（后来被 EDB 收购）的团队在此期间密切观察了生态系统，但选择等待，主要是由于 Kubernetes 存储原语尚不成熟。关键转折点出现在 2019 年 4 月，Kubernetes 1.14 引入了对本地持久卷的稳定支持。我们的第一个云原生 operator，Cloud Native BDR，随后不久发布，它是为主动-主动工作负载构建的，使用了 2ndQuadrant 的双向复制技术（现在的 EDB Postgres Distributed）。最终成为 CloudNativePG 的第一次提交是在 2020 年 2 月 18 日，由 Leonardo Cecchi、Marco Nenciarini 和我本人完成。

这里并不是要贬低 Crunchy 的成就。PGO 在大多数人还认为这是个不靠谱的想法时，就已经在 Kubernetes 上运行生产级 PostgreSQL 了，并且有大量团队在其上构建了基础设施。在进行任何比较之前，这一记录值得被承认。

架构分水岭

这两个 operator 之间最重要的区别不是一个特性。而是一种关于管理 PostgreSQL 高可用性的智能应该放在哪里的哲学。

Crunchy PGO 将 HA 委托给 Patroni，这是一个基于 Python 的分布式 HA 管理器，作为每个 Pod 内的一个进程运行。Patroni 是一个备受尊敬的项目，在我看来，它是传统 Linux 环境下 PostgreSQL 集群管理的先进技术。Patroni 通过一个分布式配置存储（可以是 etcd、Consul、ZooKeeper 或 Kubernetes 本身）来协调故障转移，而 PGO 的主要角色是配置和供给 Patroni 所需的东西。这个 operator 是在 Patroni 之上构建的，而不是取代它。在 Kubernetes 环境中，这意味着同时运行两个复杂的分布式系统，这是一个完全可以辩护的选择，尽管它带来了我们的团队权衡时考量不同的取舍。

在 2024 年盐湖城的 KubeCon 上，一位 Crunchy 的工程师直接解释了他们的理由：当 Patroni 已经存在并且经过实战检验时，为什么要从头编写复杂的分布式系统代码？这是一个合理的立场，我理解它。我们的团队只是得出了不同的结论。我们做了一个根本不同的决定：信任 Kubernetes API 正是为了其设计目的（管理分布式系统和应用程序），并在 operator 中原生编写 HA 逻辑，而不是将其委托给一个单独的工具。

CloudNativePG 的设计大约晚了三年，其核心就是这个前提：Kubernetes 是控制平面，operator 应该直接利用它。没有 Patroni，没有用于 HA 的 etcd 依赖，也没有与 Kubernetes 并行的 HA 框架。Kubernetes API 服务器是每个资源状态的唯一真实来源，包括主/备拓扑。控制器的文档和技术架构文档描述了这在实践中是什么样子的。

直接 Pod 管理

CloudNativePG 不使用 StatefulSet。它直接管理 Pod 和 PVC 资源，这赋予了 operator StatefulSet 无法提供的细粒度控制。当发生故障转移时，CloudNativePG 会提升具有最高日志序列号的副本，确保无论其名称或索引如何，最新的实例成为新的主实例。绑定 StatefulSet 的序号逻辑无法原生表达这种决策；它需要一个额外的协调层，而这正是 Patroni 在 PGO 案例中所提供的。

直接 Pod 管理还使 CloudNativePG 能够按正确顺序协调整个集群的配置更改，包括那些在应用任何更改之前必须在备用节点上设置等于或高于主节点值的参数。使用 StatefulSet，这种协调排序需要在该原语之上添加额外的逻辑。

实例管理器

CloudNativePG 中没有 HA 管理 sidecar。管理逻辑作为一个实例管理器运行，这是一个作为 PostgreSQL 容器内 PID 1 运行的 Go 二进制文件。它处理整个 Postgres 生命周期，参与自我修复，并直接与 Kubernetes API 通信以报告健康状况、复制延迟和位置。

这一点特别重要，因为实例管理器通过健康探针与 Kubelet 交互，这些探针是数据库感知的，而不是通用的。启动探针防止 Kubelet 在初始化或恢复期间重启 Pod。就绪探针检查实例是否准备好服务流量，包括在配置时检查副本上的复制延迟。主节点上的存活探针执行隔离检查：如果 API 服务器和对等实例同时变得不可达，探针会故意失败，导致 Kubelet 重启 Pod 并将隔离的主节点下线。这降低了脑裂场景的风险（尽管在使用同步复制时不会出现这种情况）。Patroni 在其 3.0.0 版本中通过其 DCS 故障安全模式引入了类似的能力。CloudNativePG 以 Kubernetes 的方式独立实现了相同的概念：它不是通过 REST API 查询对等节点，而是让存活探针和 Kubelet 来完成工作。导致我们实现的相关讨论在此处，这是一个很好的例子，说明了如何根据你的执行环境，使用根本不同的原语来解决相同的问题。

关于 Kubernetes API 服务器可用性

对这种架构的一个常见反对意见是：当 Kubernetes API 服务器宕机时会发生什么？CloudNativePG 的答案是暂停故障转移操作并优先考虑数据保护。但我认为这个问题值得一个坦率的回答，而不仅仅是一个技术性的回答。

这里需要精确说明。正如 Kubernetes 文档所指出的，当 API 服务器不可用时，现有的 Pod 会继续运行，因为 Kubelet 在本地管理它们。停止的是调度、协调和 operator 逻辑，包括 CloudNativePG 的控制器。没有 API 服务器，CloudNativePG 无法对集群做出全局决策，例如触发故障转移，并且在没有可靠的全集群状态视图的情况下尝试这样做会引入风险，而不是消除风险。因此，暂停这些决策并优先考虑数据保护与其说是一个限制，不如说是一个信任单一权威真实来源的设计的诚实结果。同样值得注意的是，Kubernetes 本身旨在通过跨多个可用区部署来解决控制平面可用性风险，因此在配置正确的集群中，API 服务器完全宕机是一个越来越不可能发生的事件。我们认为，对于控制平面本身面临风险的场景，更健壮的答案是弹性的多区域架构，CloudNativePG 通过其副本集群的分布式拓扑来支持这一点。

根据我们的经验，这种方法带来的实际后果是更小的操作面：没有额外的分布式系统需要与 operator 一起监控、调试或升级，并且故障隐藏的地方更少。话虽如此，已经非常熟悉 Patroni 的团队可能会发现操作上的转换需要对其心智模型进行一些调整。

镜像设计、体积与安全

在操作镜像中除了 PostgreSQL 之外不嵌入任何东西的架构选择，对镜像大小和安全态势有直接影响。Crunchy 的操作镜像将 Patroni（及其 Python 运行时）、pgBackRest、pgAudit、pgvector、TimescaleDB、pg_cron、pg_partman 和其他扩展捆绑到一个基于 UBI9 的镜像中，因为它们都需要共置以便 Patroni 运行。CloudNativePG 的最小镜像仅包含 PostgreSQL，扩展在运行时通过 Kubernetes ImageVolume 功能作为 OCI 镜像卷交付（需要 PostgreSQL 18 或更高版本以及 Kubernetes 1.35 或更高版本，其中 ImageVolume 默认启用；在 1.33 和 1.34 上可以通过特性门控启用），这在 CNPG 食谱 23 中有详细介绍。添加或删除扩展是对集群清单的声明性更改；它不需要不同的基础镜像，并且关键的是，不会破坏不可变性。

以下数字来自 docker scout quickview 对当前镜像的检查：

镜像	包数量	严重漏洞	高危漏洞
crunchy-postgres:ubi9-17.9-2610	625	2	156
postgresql:18-minimal-trixie	140	0	4

CNPG 的 minimal-trixie 镜像包含 140 个包，而 Crunchy 源镜像为 625 个；零个严重漏洞对比两个，四个高危漏洞对比 156 个。它的 Debian Trixie Slim 基础镜像本身没有已知漏洞。包数量在操作上很重要：更少的包意味着任何未来披露事件的爆炸半径更小，需要审计的列表也更短。CNPG 最小镜像还附带完整的软件物料清单来源证明。

关于镜像许可的话题：Crunchy Data 的容器镜像历史上是根据 Crunchy Data 开发者计划分发的，该计划限制超过 50 名员工的组织在生产中使用。operator 本身是开源的；它默认使用的镜像并非总是如此。在 Snowflake 收购后，这是否发生了变化，需要在做出采购决定前直接与 Crunchy 核实。CloudNativePG 生态系统中的每个镜像——operator、操作镜像、扩展镜像——都是完全开源的，采用 Apache License 2.0。

主版本升级

这是 CloudNativePG 投入巨大的一个领域，也是差异具体的领域。

Crunchy PGO v6 通过专用的 PGUpgrade CRD 提供主版本升级。集群必须完全关闭才能进行升级；然后 pg_upgrade 运行完成，之后集群才能重新上线。停机时间窗口由关闭和重启周期驱动，而非数据集大小，因为 pg_upgrade 默认使用硬链接，无论数据量大小都能快速完成。该过程在文档中被明确描述为永久性的：没有声明性的回滚路径，如果担心回滚问题，Crunchy 建议保留旧版本的集群副本。升级期间不支持备用集群，必须在之后删除并从头重建。一些升级后任务也需要手动干预：运行 ANALYZE、升级扩展和清理旧数据目录。

正如我在“食谱 24”中所示，CloudNativePG 提供了两条路径。离线路径通过内置的 bootstrap.initdb.import 机制使用 pg_dump / pg_restore，完全是声明性的，在集群引导时执行。在线路径使用原生 PostgreSQL 逻辑复制和声明性的发布与订阅资源，将切换窗口减少到几秒钟，无论数据集大小如何。第三条路径，通过 pg_upgrade 进行的就地主版本升级，已在 CNPG 食谱 17 中引入，并支持在有副本时自动回滚。这三条路径今天都可用。

备份与恢复

我们对 PostgreSQL 备份的参与远远早于 CloudNativePG。Barman 起源于 2ndQuadrant 团队，并且是最广泛使用的 PostgreSQL 物理备份和 WAL 归档工具之一。这些经验从一开始就塑造了我们在 CloudNativePG 中处理备份的方式。

Crunchy PGO 将 pgBackRest 嵌入到操作镜像中，并通过 PostgresCluster 规范进行配置。pgBackRest 是一个优秀的工具。嵌入模型的结果是备份代码和数据库代码是耦合的：pgBackRest 的更新需要一个新的操作镜像。

CloudNativePG 支持两种备份方法，在文档中有详细比较。第一种是 Kubernetes 本地的卷快照，这是唯一由 operator 直接处理的备份方法。卷快照支持冷备份和热备份，尽管热备份需要 WAL 归档到位以实现一致性恢复。在 2023 年亚特兰大的 KubeCon 上，我们演示了使用这种方法在 2 分钟内恢复一个 4.5 TB 的数据库。

第二种是 CNPG-I，一个插件接口，它完全将备份工具与 operator 解耦。Barman Cloud 插件是参考实现，也是目前唯一由社区维护的实现，但该接口是开放的：没有什么能阻止社区或组织为其他工具（如 pgBackRest 或 WAL-G）编写插件。

可观测性

两个 operator 都为 Prometheus 提供 PostgreSQL 指标。CloudNativePG 更进一步，支持在 ConfigMap 或 Secret 中定义的声明性自定义指标，并由集群资源引用，允许团队将应用程序特定的查询作为 Kubernetes 资源与集群本身一起管理。监控文档和社区维护的 Grafana 仪表板涵盖了完整的默认指标集。

在日志方面，CloudNativePG 管理的每个容器都以 JSON 格式将结构化日志写入 stdout，如日志文档所述。这是一个刻意的设计选择：它不需要在 Pod 内部进行日志文件管理，并且可以直接与任何 Kubernetes 级别的日志聚合解决方案集成，无论是 EFK 堆栈、Loki、云提供商的本地产品，还是诸如 Logging operator 之类的专用 operator。

社区健康与治理

这一节是我最明显有利益冲突的地方，所以我会让数据说话，而不是发表评论。

我将 Patroni 包含在下面的图表中，不是作为 operator 领域的直接竞争对手，而是作为更广泛的 PostgreSQL 采用的参考点。Patroni 是传统 Linux 环境中 PostgreSQL 的主要 HA 解决方案，并且拥有自己庞大的社区。看到 CloudNativePG 接近并超越其星标数，可以感受到云原生 Postgres 运动背后的动力，这超越了狭义的 operator 范畴。CloudNativePG 的星标增长完全是自然的：没有星标农场活动，没有人为的放大。

[此处假设有图表，标题为：Patroni、CloudNativePG 和 Crunchy PGO 的 GitHub 星标历史]

下表涵盖了截至 2026 年 5 月的 18 个月内的指标。

指标	PGO (CrunchyData)	CloudNativePG
GitHub 星标（主仓库）	4.4k	8.6k（整个组织约 10k）
总提交数	4,418	4,662（较新的项目）
提交率（历史平均）	约 480/年	约 745/年
提交率（过去 3 年）	约 235/年	约 894/年
开放的拉取请求	约 18	约 174
贡献者	供应商内部	200+ 来自多个组织
GA 发布（过去 18 个月）	约 4（当前分支）	约 18（一致节奏）
最长发布间隔（过去 18 个月）	8 个月（2025 年 3 月 - 11 月）	无间隔（6-8 周节奏）
公开治理	无	CNCF（GOVERNANCE.md, MAINTAINERS.md）
CNCF 成员资格	无	沙箱，等待孵化中
公开路线图	无	ROADMAP.md
OpenSSF 最佳实践基线	无	是
SECURITY-INSIGHTS.yml	无	是
威胁评估	无	是
ADOPTERS.md	无	是
文档	专有门户	完全开放

PGO 发布历史中 8 个月的间隔（2025 年 3 月到 11 月）在数据中很突出。这是反映了故意的整合阶段还是更结构性的问题，我真的不知道。我能说的是，这种节奏、Snowflake 的收购以及缺乏公开治理的组合，正是团队在向我询问他们的选择时最常提出的问题。

我也会坦诚地说明 CloudNativePG 方面的情况。174 个开放的拉取请求是一个很高的数字，它反映了一个真正的挑战：项目增长速度快于我们当前审查和合并的能力。部分增长可归因于 AI 生成贡献的增加——这是我们在开源生态系统中观察到的一种模式。我们的 AI 政策是明确的：人类贡献者对他们提交的所有内容承担全部责任，维护者可能会关闭低质量的 AI 生成的 PR 而不进行详细评审，我们重视一个经过仔细考虑的贡献胜过十个肤浅的贡献。除此之外，我们正处于一个过渡阶段，正在积极减少三个方面的技术债务，这些方面目前消耗了我们大部分的认知预算：扩展镜像支持（工作已接近完成）、从核心 Barman Cloud 集成迁移到插件模型（也接近完成）以及重构端到端测试套件以与 CNPG-I 插件协同工作。一旦这些工作落地，审查范围将大大缩小，积压问题也应随之解决。

CloudNativePG 是一个 CNCF 沙箱项目，目前正在排队等待孵化，其健康指标在 LFX Insights 仪表板上公开可见。主仓库有 8.6k 个星标；在 CloudNativePG GitHub 组织的所有仓库中，总数接近 10,000。大部分开发工作仍由 EDB 推动，这在 CNCF 成熟度的这个阶段是完全预期的。孵化是项目的下一个里程碑，主要要求是展示广泛的生产采用——鉴于 ADOPTERS.md 文件的深度以及我与汇丰银行的 Laurent Parodi 在 KubeCon 上的演讲，我并不担心这一点。毕业，即第三步，是多组织贡献成为正式标准的地方，这是我们在达到孵化（希望如此）之后需要做的工作。治理模型、路线图和安全策略都是公开的。采纳者包括 IBM、Google Cloud、Microsoft Azure、Tesla、GEICO Tech、Novo Nordisk 和 Mirakl（8 TB，300+ 集群）等，列在 ADOPTERS.md 中。

安全透明度也是一个刻意的关注点。开源安全基金会一直是这项工作的关键合作伙伴。CloudNativePG 符合 OpenSSF 最佳实践基线，在 2026 年于阿姆斯特丹举行的 KubeCon + CloudNativeCon Europe 2026 上的 OpenSSF 安全大满贯活动中，CloudNativePG 是仅有的三个获得全部五个可用徽章（清洁工、编年史家、检查员、机械师和防御者）的项目之一。这项工作产生了一个 SECURITY-INSIGHTS.yml 文件和一个项目的 Gemara 威胁评估等成果。这两者都与正在或准备根据欧盟网络弹性法案运营的组织直接相关，该法案要求软件制造商在产品生命周期中展示安全尽职调查。作为一个开源社区项目，拥有这些工件并非理所当然，它反映了投入 CloudNativePG 维护方式的那种长期思考。

我诚实的结论

Crunchy Data 是开拓者，并且构建了实实在在的东西。我对此抱有真诚的敬意。但 2026 年的格局与 2017 年不同：Kubernetes 是一个成熟的控制平面，operator 模式已广为人知，在我看来，如今在数据库 Pod 内运行并行分布式系统的权衡比那时更重要。CloudNativePG 从一开始就旨在利用 Kubernetes 实际提供的东西，我相信这一决定体现在从架构到镜像体积再到备份模型的方方面面。

如果你今天正在评估 PostgreSQL operator，并且你的主要关切是长期的架构稳健性、开放的治理以及一个拥有显著发展势头的社区，我认为这里提供的数据值得仔细反思。这是我的观点，我深知它并非中立。作为一个项目的维护者和创始人，它不可能是中立的（如果我们最初的想法不同，现在就不会有 CloudNativePG 了）。

最终，选择权在你手中。我诚实的建议，尽管存在偏见，是尝试两者，并决定哪个最适合你的团队、你的工作负载和你的组织。这就是做出好的工程决策的方式。

请继续关注即将发布的食谱！如需最新更新，请考虑订阅我的 LinkedIn 和 Twitter 频道。

如果你觉得这篇文章信息丰富，请随时使用下面提供的链接在你的社交媒体网络中分享。非常感谢你的支持！

本文在 Claude (Anthropic) 的协助下起草和完善。所有技术内容、更正和编辑方向均由作者本人负责。

作者

Gabriele Bartolini
EDB 副总裁、Kubernetes 首席架构师 | PostgreSQL 贡献者 | DoK 大使 | CloudNativePG 维护者 | 前 2ndQuadrant（联合创始人）