Which CloudNativePG vs Zalando operator vs Crunchy PGO fits your team
Pick the operator that matches the failover and backup tooling your team already runs, then check the version window before you commit. If your platform team already operates Kubernetes and wants PostgreSQL failover handled by the Kubernetes API server without Patroni in the stack, CloudNativePG is the closest fit. Its Apache-2.0 license and CNCF Sandbox status are documented facts, and its failover does not depend on a separate configuration store. If your team already runs Patroni and Spilo in production under MIT terms, the Zalando postgres-operator keeps that operating model intact, with WAL-G or WAL-E handling point-in-time recovery. Crunchy PGO suits teams that want pgBackRest for full, incremental and differential backups, but only after legal review of the Crunchy Data Developer Program terms, because the PGO README states that images pulled from the Crunchy Data Developer Portal by default fall under those terms.
Version choice affects all three options. PostgreSQL 14 support ends on November 12, 2026, so any new cluster built on 14 will need a major upgrade soon after go-live. Confirm which PostgreSQL majors each operator supports at the release you plan to deploy, since the Zalando v2.0.3 release is documented for PostgreSQL 14 to 18 and CloudNativePG tracks the versions supported by the PostgreSQL Global Development Group. Ask your DeployOpen or vendor contact to confirm the exact image sources and license terms for the Crunchy Data images in your environment before the platform is designed.
Which operator fits which team situation
This table maps common team situations to the operator that fits best and the fact behind that choice. Read each row against your own platform, then confirm the flagged details with the vendor or in a proof of concept before you commit.
| Team situation | Best fit | Reason and what to confirm |
|---|---|---|
| Kubernetes-native platform team that wants failover inside the Kubernetes API | CloudNativePG | It uses the Kubernetes API server for failover without external tools such as Patroni and manages PVCs directly instead of StatefulSets. Confirm that your cluster admins accept the operator owning volume and failover logic. |
| Existing Patroni estate moving onto Kubernetes | Zalando postgres-operator | It uses Patroni and Spilo, so failover behavior and the Patroni REST API stay familiar to staff already running Patroni. Confirm the operator version covers your PostgreSQL major version, since the v2.0.3 release lists PostgreSQL 14 to 18. |
| Team standardizing on pgBackRest for backups | Crunchy PGO | PGO uses pgBackRest for full, incremental and differential backups. Confirm the backup repository targets and retention settings you need, because CloudNativePG relies on the Barman Cloud plugin and Spilo on WAL-G or WAL-E. |
| Team with strict image provenance review | Depends on your image source (confirm first) | PGO's installation pulls images from the Crunchy Data Developer Portal by default, which are subject to the Developer Program terms. Confirm with legal and your registry policy whether you can mirror those images, and compare the image sources of the other two operators before deciding. |
| Small team that needs one operator to run databases and backups | CloudNativePG or Zalando operator (confirm your skills) | CloudNativePG runs without a separate Patroni layer, which reduces components to operate. The Zalando operator adds Patroni and Spilo as components. Confirm which tool your on-call staff can troubleshoot in an outage. |
| Team that needs PostgreSQL built-in connection pooling | CloudNativePG | It includes PgBouncer pooling. Confirm that the pooler configuration meets your application's session needs before relying on it. |
| Team that depends on an Apache-2.0 CNCF Sandbox project | CloudNativePG | It is an Apache-2.0 CNCF Sandbox project, originally developed by EDB and now community driven. Confirm the project's current status with the CNCF before you rely on it. |
| Team that wants a permissive license on the operator itself | Zalando operator or Crunchy PGO | Both are open source, the Zalando operator under MIT and PGO under Apache-2.0. Confirm the licensing of any container images you pull from each vendor, since image terms can differ from the code license. |
How CloudNativePG vs Zalando operator vs Crunchy PGO differ on license and image terms
CloudNativePG is an Apache-2.0 licensed operator for running PostgreSQL on Kubernetes. It was originally developed by EDB and is now community driven, and it is a CNCF Sandbox project. The Apache-2.0 license covers the operator source code, and the project's documentation describes its release lines as open source without a separate paid edition in the supplied material. Its maintained minor lines are shown on the project's releases page, where 1.30.1 and 1.29.3 were both released on September 23, 2026.
- Source license: Apache-2.0 applies to the operator code you deploy and modify.
- Governance: A CNCF Sandbox project, so the project's maturity level differs from graduated CNCF projects.
- Maintained lines: Two minor lines, 1.30.1 and 1.29.3, were released together, which shows how the project ships fixes.
- Image path: The documentation describes operator and PostgreSQL images without an extra vendor download gate in the supplied facts.
- Commercial support: Ask the project's sponsoring vendors directly whether a paid support tier exists before you budget.
Confirm the image registry you pull from and the license of any plugin you add, such as the Barman Cloud plugin, because plugin terms are separate from the operator license.
The Zalando postgres-operator is MIT licensed and runs highly available PostgreSQL clusters on Kubernetes. You configure it through Postgres manifests, which are custom resources. It uses Patroni for high availability and Spilo with WAL-G or WAL-E for point-in-time recovery. The v2.0.3 release supports PostgreSQL 14 to 18, so the supported major versions are set by the operator release you deploy.
- Source license: MIT, one of the most permissive open source licenses, with no copyleft obligation on your deployment.
- Component licenses: Patroni and Spilo are separate components with their own licenses, so review each one in your bill of materials.
- Version coverage: v2.0.3 supports PostgreSQL 14 to 18, which matters if you plan to run an older major version.
- Backup tooling: WAL-G or WAL-E sit inside Spilo, so your backup target and retention policy are part of your configuration.
- Commercial support: The supplied material does not describe a paid support tier, so confirm with the maintainers or a support provider before you budget.
Check the licenses of the Spilo image and any base image you rebuild, and confirm how your team will handle updates to Patroni and Spilo together with the operator.
Crunchy Data's PGO is an Apache-2.0 licensed declarative Postgres operator for Kubernetes. It includes Patroni and uses pgBackRest for full, incremental and differential backups. The source license is permissive, but the README states that container images downloaded from the Crunchy Data Developer Portal, which the installation steps pull by default, are subject to the Crunchy Data Developer Program terms. That means the default image path can carry terms beyond the Apache-2.0 source license.
- Source license: Apache-2.0 covers the operator code in the repository.
- Default image terms: Images pulled from the Developer Portal by default are subject to the Crunchy Data Developer Program terms.
- Alternative registries: If you mirror or build images under your own control, confirm that your build path avoids the portal terms and that you keep the original notices.
- Backup tooling: pgBackRest provides full, incremental and differential backups, which you configure alongside the operator.
- Commercial support: Confirm with Crunchy Data whether a paid support or subscription tier exists and what it covers.
Read the Crunchy Data Developer Program terms in full before the first deployment, and have legal review them against your internal policy for air-gapped or mirrored registries.
How CloudNativePG vs Zalando operator vs Crunchy PGO compare on failover and backups
This table compares the three Kubernetes PostgreSQL operators on license, failover design, backup tooling, storage handling and supported versions. Read each row as a question to answer in your own environment, and treat any cell marked for confirmation as a point to verify with the vendor before you commit.
| Capability | CloudNativePG | Zalando postgres-operator | Crunchy PGO |
|---|---|---|---|
| License | Apache-2.0, CNCF Sandbox project | MIT licensed | Apache-2.0 licensed; bundled container images pulled by default are subject to the Crunchy Data Developer Program terms |
| Failover mechanism | Uses the Kubernetes API server for failover without external tools such as Patroni | Uses Patroni for high availability | Includes Patroni for high availability |
| Patroni use | Not used; Patroni is not required | Used inside Spilo-based clusters | Included as part of the operator design |
| Configuration store | Kubernetes API server | Kubernetes, via Patroni | Confirm the distributed configuration store with Crunchy Data's current documentation |
| Backup tooling | Object storage through the Barman Cloud plugin, volume snapshots and WAL archiving | WAL-G or WAL-E through Spilo | pgBackRest for full, incremental and differential backups |
| Point-in-time recovery | WAL archiving with point-in-time recovery | Supported through WAL-G or WAL-E archiving | Confirm the PITR procedure for your pgBackRest and storage setup |
| Replication options | Quorum-based failover and synchronous replication | Inherits Patroni replication options, including synchronous replication | Confirm which synchronous and quorum options your release exposes |
| Connection pooling | Built-in PgBouncer pooling | Confirm pooler support in your chosen release | Confirm pooler support in your chosen release |
| Persistent storage handling | Manages PVCs directly instead of StatefulSets | Confirm storage layout in your release | Confirm storage layout in your release |
| Supported PostgreSQL versions | Tracks PostgreSQL community supported versions | Operator v2.0.3 supports PostgreSQL 14 to 18 | Confirm the version matrix for your PGO release |
What drives the running cost of each operator
The licence line is often the smallest cost of running a PostgreSQL operator on Kubernetes. The larger costs come from the cluster and storage underneath, the backup target, the people who know the operator, and the cadence of upgrades. Work through each card with the written quote and your own environment in hand, because the answers differ between CloudNativePG, the Zalando operator and Crunchy PGO.
Kubernetes platform and storage
Every operator runs PostgreSQL pods on persistent volumes, so the Kubernetes cluster, its node pools and the storage class you pay for are usually the largest recurring cost. CloudNativePG manages PVCs directly rather than through StatefulSets, which affects how you size and reclaim volumes. Ask who provisions and monitors the cluster, which storage class each operator's clusters will use, and how many nodes the failover design needs at minimum. These costs recur monthly and scale with replica count and volume size.
Backup target and retention storage
Backup cost is a recurring line that grows with data volume, WAL archive size and how long you keep restore points. CloudNativePG supports object storage through the Barman Cloud plugin, volume snapshots and WAL archiving for point-in-time recovery. Crunchy PGO uses pgBackRest for full, incremental and differential backups, and the Zalando operator uses Spilo with WAL-G or WAL-E. Confirm the bucket or repository location, the retention policy you need for your recovery objectives, and whether restore tests are part of the quote.
Operator skills and staffing
CloudNativePG is Kubernetes-native and does its failover through the Kubernetes API, so the skills it needs are Kubernetes operations and CRD management. The Zalando operator and Crunchy PGO both depend on Patroni, so your team needs Patroni knowledge for failover, switchover and configuration tuning. Staffing is usually the largest one-time learning cost and a recurring cost when the people who understand the stack leave. Ask which skills the implementation includes as handover, and how runbooks are documented.
Image registry and terms review
Image sourcing can carry a licence cost even when the operator code is Apache-2.0 or MIT. The PGO README states that container images from the Crunchy Data Developer Portal, which its default installation steps pull, are subject to the Crunchy Data Developer Program terms. Legal review, a mirrored internal registry and image scanning are one-time setup costs, with recurring effort each time images update. Ask your counsel to review the current terms before you pull images, and ask your implementer which registry each operator's images will come from.
Upgrade cadence across two release tracks
Upgrades recur, and each operator adds a second track on top of PostgreSQL's own. PostgreSQL 14 is supported until November 12, 2026, while PostgreSQL 18 is supported until November 14, 2030, so major upgrades will fall due at different times in your estate. Operator releases, Patroni releases and PostgreSQL minor releases each need testing in staging. Ask for the upgrade plan per release track, who performs major upgrades, and how many environments are included in the scope.
Vendor support and quote scope
Support fees are optional but change the recurring budget. Crunchy Data and EDB sell commercial support around their operators, and the Zalando operator is community-maintained, so support terms differ by vendor. The Kubernetes distribution's support contract is a separate line item. Ask each vendor for written support terms, response expectations and what the subscription covers, and ask DeployOpen for a fixed-scope quote that names the deliverables, handover and any retainer for ongoing support and upgrades.
Why the Patroni layer changes day-two work
CloudNativePG handles failover through the Kubernetes API server without external tools such as Patroni, so the operator itself decides promotion and the cluster's failover path lives inside Kubernetes objects you already monitor. The Zalando operator and Crunchy PGO take a different route: both include Patroni, which runs as the high availability layer and holds leader election through its distributed configuration store. That means day-two work for those two operators includes a second control surface. Patroni exposes a REST API for health checks, cluster status, configuration, switchover and failover, restarts, reloads and reinitialization. Your runbooks, alerts and access controls need to cover that API as well as the Kubernetes resources.
Patroni is a documented and widely used layer, and its feature set is broad: synchronous replication including quorum commit, standby clusters, and watchdog device support are all described in its documentation. Those are real advantages if you need standby clusters in a second site or want a watchdog to guard against split brain on hosts you manage. The cost is more components to learn and patch. Patroni is MIT licensed and describes itself as a template that needs configuration for each deployment, so the settings you choose become your responsibility to test and document.
Confirm which Patroni version your operator images carry before you plan upgrades. The Patroni documentation notes a memory allocation issue on Python 3.11 and later, on memory-restricted systems, which releases 4.1.1 and 4.0.8 and later mitigate by starting threads earlier. Ask each vendor which Patroni release its current image pins, check the patroni version reported in a running pod, and record whether memory limits on database pods are tight enough to trigger the issue. Add that check to your upgrade procedure so a new operator release does not silently change the failover layer.
How a CloudNativePG, Zalando or Crunchy PGO rollout is sequenced
This sequence turns an operator choice into a PostgreSQL cluster the client can operate, restore and hand over, with each step closing on a check the client can verify before the next one starts.
Confirm the target PostgreSQL version and support window
The client provides the list of databases, their application owners, and the PostgreSQL major version each application is certified against. DeployOpen checks that version against the PostgreSQL versioning policy, which lists PostgreSQL 14 as supported until November 12, 2026 and PostgreSQL 18 as supported until November 14, 2030, and records the support end date for every major version in scope. The step closes when the client signs off on one target major version and the date the team expects to plan its next upgrade. Each operator also determines which PostgreSQL versions it will run, so the operator's supported version list must be confirmed in writing before the target is fixed.
Choose the backup target and run a restore
The client decides where backups and WAL archives will live, such as an object store in its own cloud account or a volume snapshot target, and provides access and retention requirements. DeployOpen configures the backup method for the chosen operator: pgBackRest for Crunchy PGO, WAL-G or WAL-E through Spilo for the Zalando operator, and the Barman Cloud plugin or volume snapshots for CloudNativePG. The step closes only after a test restore to a separate namespace has been run and a point-in-time recovery to a chosen timestamp has been verified against a known row set. A backup that has never been restored is not counted as evidence.
Decide the image source and approve its terms
The client's legal and procurement contacts review where container images will come from before anything is pulled. For Crunchy PGO, the client must check whether images from the Crunchy Data Developer Portal, which the default installation steps pull, fall under the Crunchy Data Developer Program terms, and decide whether to use those images or a mirror it controls. DeployOpen builds an internal image registry path, mirrors approved images, and records each source in the deployment manifest. The step closes when the client approves the written image source list and terms, and DeployOpen confirms that the cluster pulls only from that list.
Build storage and run failover tests on Kubernetes
The client provides the Kubernetes clusters, storage classes, node layout and the network policies its platform team requires. DeployOpen deploys the chosen operator, sets up persistent volume claims and storage classes, configures synchronous or asynchronous replication according to the client's data loss requirements, and runs failover tests that remove the primary pod and a worker node. For CloudNativePG, the test confirms that the Kubernetes API drives failover without an external tool. For Zalando and Crunchy PGO, the test confirms that Patroni's leader election and its configuration store behave as expected. The step closes with a test log showing promotion times and client connection behavior after each induced failure.
Run switchover drills under load
The client provides a maintenance window, a test application or replay workload, and named staff who will watch dashboards during each drill. DeployOpen runs planned switchovers and a controlled node drain while the workload is active, records how connections are routed during the switch, and checks that pooling, such as PgBouncer where the operator provides it, reconnects cleanly. Any dropped transactions or stalled connections are logged as defects and fixed before the next drill. The step closes when the team has completed the agreed number of clean drills and the client accepts the results in writing.
Document the runbook and hand it over
The client provides its incident contacts, escalation paths and change management process. DeployOpen writes the runbook covering backup verification, restore steps, switchover and failover procedures, minor version updates, and the path for a future major version upgrade, including the pg_upgrade or logical replication option the team selects. The client's operators are trained on the runbook and run one restore and one switchover themselves while DeployOpen observes. The step closes when the client's operations team signs the handover, and the documentation and test evidence are stored in the client's own systems.
Questions buyers ask before hiring help with a PostgreSQL operator
What drives the cost and effort of running each PostgreSQL operator?
The main drivers are how many clusters you run, how much of the backup and recovery design you must build yourself, and how many Kubernetes platform layers your team already operates. CloudNativePG relies on the Kubernetes API for failover, so there is no separate Patroni layer to run. Zalando's operator adds Patroni and Spilo, and Crunchy PGO bundles Patroni with pgBackRest, so each stack has different components to patch and test. Licensing is not the main cost: the Zalando operator is MIT, Crunchy PGO is Apache-2.0 but its default container images pull under the Crunchy Data Developer Program terms, and CloudNativePG is Apache-2.0. Ask any quote to split one-time design, migration and testing work from recurring upgrades, patching and on-call support, and to show who pays for each line.
How long does a PostgreSQL operator rollout take, and what sets the timeline?
No duration is supplied for this engagement, so confirm the timeline in writing before work starts. Most engagements are fixed-scope, which means scope, deliverables and timelines are agreed in writing first. The timeline is set by the number of databases, the backup target (object storage, volume snapshots or both), the point-in-time recovery requirement, whether you are migrating existing data, and how many environments need testing. Image licensing review and any change approval in your own change process can also add time. Ask for the schedule to list each milestone and the evidence each one produces.
What does the client team need to provide for an operator rollout?
The client team typically supplies access to the Kubernetes clusters, storage classes and network policies, a decision on the backup destination, and named owners who can approve changes. Engineers who understand PostgreSQL replication, WAL archiving and restore testing are needed to validate recovery, even when a partner does the build. Identify who owns the application connection pattern and whether connection pooling runs in the operator or in front of it. Put these inputs in the written scope so that responsibilities for each step are clear before a quote is final.
Can an internal team run a PostgreSQL operator without outside help?
Yes, many teams do, provided they already run Kubernetes and have database operations skills. The practical test is whether your team can perform a point-in-time restore into a scratch cluster, rotate credentials, upgrade the operator and the PostgreSQL minor version, and respond to a failed failover without guidance. CloudNativePG keeps failover inside the Kubernetes API, which reduces the moving parts to learn. Zalando and Crunchy PGO require familiarity with Patroni and, in Crunchy's case, pgBackRest. Recurring work such as patching, backup verification and version upgrades needs a named owner either way. DeployOpen can provide retainers for ongoing support and upgrades if you choose not to carry that load alone.
How hard is it to switch PostgreSQL operators later?
Switching is possible but not trivial, and the effort depends on how each operator stores cluster state and backups. Each operator defines its own custom resources, so manifests do not transfer directly. The safer route is to keep backups in a format the new operator can restore from, or to migrate with a logical replication path. PostgreSQL logical replication works between major versions, which can limit downtime to several seconds in a cutover, but it does not carry DDL, sequences or large objects, so those must be handled separately. Plan a rehearsal on a copy of production, and confirm backup restore compatibility with the new operator's documentation before committing.
Does PostgreSQL 14 support timing affect which operator to choose?
PostgreSQL 14 support ends on November 12, 2026, according to the PostgreSQL versioning policy, so any cluster still on version 14 needs a planned upgrade path. The timing matters more than the operator choice: all three operators run supported versions, and the Zalando v2.0.3 release supports PostgreSQL 14 to 18. Start by listing which clusters are on version 14 and when each will move to 15 or later. Ask each operator's maintainers, or the vendor you choose, how a major upgrade is performed and how it is tested before production cutover.
Does DeployOpen issue certifications for a PostgreSQL deployment?
No. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted platforms, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. If your organization needs formal assurance for a PostgreSQL platform, confirm with your auditor which evidence they expect, and ask DeployOpen to scope the documentation and control work in writing.
How DeployOpen helps choose and implement a PostgreSQL operator
DeployOpen starts with the question of which operator fits your Kubernetes platform, backup standards and PostgreSQL versions, then plans and implements the chosen operator inside your own clusters. Every step is written down so your team can run, upgrade and audit the result without depending on us.
How we scope
- We confirm which Kubernetes distribution, backup targets and PostgreSQL major versions your databases need before choosing an operator.
- The written scope names the operator, cluster topology, failover design, backup method and the PostgreSQL versions each cluster will run.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy the chosen operator in your cloud account, data center or air-gapped network, with replicas spread across failure domains.
- We configure WAL archiving and backups to your object storage, then test restores and point-in-time recovery before go-live.
- We run failover and switchover tests against the cluster and document each result so you can repeat them later.
How we hand over
- You receive architecture notes, runbooks for failover, backup restore and version upgrades, and the configuration as code.
- We walk your platform and database teams through the manifests, image sources and licensing terms that apply to your installation.
- We document which image terms, support windows and PostgreSQL end-of-life dates your team must track after handover.
How we support
- Ongoing support, minor and major upgrades, and continuous testing are available as a retainer, scoped separately from the build.
- We can plan operator upgrades and PostgreSQL major version moves as a defined piece of work with its own written scope.
- Ask us to confirm operator versions, image licensing and supported PostgreSQL releases against vendor sources before you sign.
