CloudNativePG and Crunchy PGO: an honest, opinionated comparison

CloudNativePG and Crunchy PGO: an honest, opinionated comparison · Unleashing the Power of Postgres in Kubernetes↓Skip to main content Table of Contents

This article compares CloudNativePG and Crunchy PGO, two of the most adopted open-source operators for running PostgreSQL on Kubernetes. It covers architecture, image design, backup strategy, major version upgrades, observability, licensing and community health. As a co-founder and maintainer of CloudNativePG, I make no claim to neutrality, and I say so upfront. What I can offer is informed bias, grounded in years of daily work on the project and a genuine respect for what Crunchy Data built in this space. For years, I resisted writing a direct comparison between CloudNativePG and Crunchy PGO. It felt like the wrong kind of article to write from where I sit. But after several years of both projects maturing, and particularly since Crunchy Data was acquired by Snowflake, I have been asked with increasing frequency how the two operators compare. I now think the time is right. Last week, I wrote Recipe 24 to answer the practical question of how to migrate. This post attempts something harder: an honest assessment of why the two operators differ and what those differences mean for teams choosing a long-term platform for PostgreSQL on Kubernetes. I will acknowledge Crunchy’s legacy, explain the architectural choices that I believe make CloudNativePG the stronger foundation, point to data where it exists, and flag the areas where my view is unavoidably subjective. I will not pretend this is a neutral document. Crunchy’s pioneering role # Crunchy Data released the first PostgreSQL operator for Kubernetes in March 2017, less than two years after Kubernetes itself debuted and shortly after CoreOS introduced the operator pattern. That was genuinely ahead of its time. My team at 2ndQuadrant (later acquired by EDB) monitored the ecosystem closely during this period but chose to wait, primarily due to the immaturity of Kubernetes storage primitives. The pivotal moment came in April 2019, when Kubernetes 1.14 introduced stable support for local persistent volumes. Our first cloud-native operator, Cloud Native BDR, followed shortly after, built for active/active workloads using 2ndQuadrant’s bi-directional replication technology (now EDB Postgres Distributed). The first commit to what became CloudNativePG was made on 18 February 2020, by Leonardo Cecchi, Marco Nenciarini and myself. The point is not to minimise what Crunchy built. PGO ran production PostgreSQL on Kubernetes before most people thought that was a reasonable idea, and a large number of teams built their infrastructure on it. That record deserves acknowledgement before any comparison. The architectural divide # The most important difference between the two operators is not a feature. It is a philosophy about where the intelligence for managing PostgreSQL high availability should live. Crunchy PGO delegates HA to Patroni, a Python-based distributed HA manager that runs as a process inside each pod. Patroni is a well-respected project and, in my view, the state of the art for PostgreSQL cluster management on traditional Linux environments. Patroni coordinates failover through a distributed configuration store, which can be etcd, Consul, ZooKeeper or Kubernetes itself, and PGO’s role is primarily to provision and configure what Patroni needs. The operator builds on top of Patroni rather than replacing it. In a Kubernetes context, this means running two sophisticated distributed systems alongside each other, which is a perfectly defensible choice, though one that carries trade-offs our team weighed differently. At KubeCon Salt Lake City in 2024, an engineer from Crunchy explained their reasoning directly: why write complex distributed systems code from scratch when Patroni already existed and was battle-tested? It is a reasonable position, and I understand it. Our team simply reached a different conclusion. We took a fundamentally different decision: to trust the Kubernetes API for exactly what it was designed for (managing distributed systems and applications) and to write the HA logic natively in the operator rather than delegating it to a separate tool. CloudNativePG was designed roughly three years later, with that premise at its core: Kubernetes is the control plane, and the operator should exploit it directly. There is no Patroni, no etcd dependency for HA and no HA framework running in parallel with Kubernetes. The Kubernetes API server is the single source of truth for the state of every resource, including the primary/standby topology. The controller documentation and the technical architecture document describe what that looks like in practice. Direct Pod management # CloudNativePG does not use StatefulSets. It manages Pod and PVC resources directly, which gives the operator granular control that StatefulSets cannot provide. When a failover occurs, CloudNativePG promotes...

CloudNativePG and Crunchy PGO: an honest, opinionated comparison

Related Articles

Amazon, Facebook, FBI have access to a private intelligence-sharing network

SpaceX not the behemoth everyone thought

Elevated error rates on requests to multiple models

Donald Trump and sons to be 'forever' exempt from tax audits

PopuLoRA: Co-Evolving LLM Populations for Reasoning Self- Play