CloudNativePG vs Zalando: architecture and restore checks
Choose a PostgreSQL operator by the operational workflow your team can run and recover, not an unsupported popularity score. CloudNativePG and Zalando Postgres Operator both manage PostgreSQL on Kubernetes, but their high-availability and backup arrangements differ. Confirm the exact operator, PostgreSQL, Kubernetes, image and plugin versions before comparing a deployment.
Compare the management model
| Area | CloudNativePG | Zalando Postgres Operator |
|---|---|---|
| High availability | The project describes direct integration with the Kubernetes API rather than relying on external HA tools such as Patroni. | The documented scope manages Patroni-based PostgreSQL clusters; Spilo appears in its deployment and operations examples. |
| Desired state | The operator reconciles its Cluster resources and manages primary/standby operations. | The operator watches cluster manifests and configuration and orchestrates changes to the managed clusters. |
| Operational fit | Evaluate its resource model, plugins and procedures with your Kubernetes platform. | Evaluate the operator, Patroni/Spilo configuration and existing team procedures together. |
Sources: CloudNativePG's project documentation and Zalando's documented concepts and scope. An architecture choice does not, by itself, prove that one system is more secure, easier or faster for a particular team.
Check the actual backup and restore path
CloudNativePG's current backup documentation describes physical backups through CNPG-I plugins and volume snapshots. It identifies the Barman Cloud Plugin for supported object-store integration and marks the older native Barman integration as deprecated from version 1.26. Match the documentation to the version you deploy; do not copy an old backup stanza without checking its status.
Zalando's user guide documents cloning and recovery from backups and archived WAL, including point-in-time recovery configuration. The earlier answer's characterization of it as primarily a logical-backup option omitted that important capability. A feature being documented is still different from a successful restore in your storage, identity and network environment.
A replica, a volume snapshot, a logical dump and a recoverable physical backup are different mechanisms. State the recovery goal and check the required base backup, WAL continuity, retention, credentials and storage permissions. A backup job reporting success is not an executed recovery test.
Use the same acceptance tests for both
| Test in an isolated environment | Evidence to retain |
|---|---|
| Create a small representative database and exercise application connections. | Versions, manifests, storage class, connection path and observed application behavior. |
| Perform an authorized planned switchover. | Connection interruption, application recovery and operator events. |
| Restore to a new isolated cluster using a chosen recovery point. | Recovered records, latest recoverable point, elapsed restore time and all dependencies. |
| Test a documented upgrade path. | Compatibility checks, migration behavior and a usable recovery plan. |
| Exercise an alert and a team handoff. | Who receives it, the diagnostic procedure and whether the next operator can follow it. |
Decide your acceptable recovery point, recovery time and interruption before running the tests. Record failures as well as successes. A result from one cluster does not establish universal behavior under another workload, storage class or failure mode.
Account for the whole operation
Compare compute, allocated and used storage, backup retention, object operations, network transfer, monitoring and engineering/on-call work. Open-source licensing does not make those costs zero. For example, three 100 GiB data volumes allocate 300 GiB before backups and other storage; that arithmetic is not a provider bill or a sizing recommendation.
Choose according to evidence and existing responsibilities
A team with established Patroni operations may value continuity; another may prefer CloudNativePG's direct Kubernetes integration and plugin model. Check the releases and support arrangements you will actually use. This revision removes unsupported market-share, development-decline and automatic-cost-saving claims. It contains no executed operator benchmark, production migration or universal winner.