Patroni vs CloudNativePG: which fits where your databases run
PostgreSQL does not detect a primary failure or promote a standby on its own, so whichever option you choose, you are adding external logic to keep the database available. The real decision is where your databases will run. Choose Patroni if your PostgreSQL clusters live on virtual machines and you are prepared to run a distributed configuration store such as etcd, Consul, ZooKeeper or Kubernetes beside them. Choose CloudNativePG if your databases already run on Kubernetes and your platform team is comfortable operating PostgreSQL as Kubernetes resources, since the operator uses the Kubernetes API server for failover without an external configuration store.
Four factors should decide the choice. First, the platform: Patroni is a template you configure for each deployment, while CloudNativePG assumes Kubernetes and manages PersistentVolumeClaims directly rather than StatefulSets. Second, the people: a Patroni cluster needs staff who understand Python-based agents, the chosen configuration store and PostgreSQL internals, while a CloudNativePG cluster needs Kubernetes operators who understand storage classes, node drains and custom resources. Third, backups: confirm how each option ships WAL archives and base backups to your object storage and whether you can test point-in-time recovery on a schedule. Fourth, failover design: check how each handles synchronous replication, quorum commit and the fencing of an old primary, and confirm that behavior in a test before you commit.
Before you pick, confirm three things in your own environment. Check whether your Kubernetes platform is stable enough to hold stateful databases, because the operator inherits its storage and scheduling behavior. Check whether your existing automation and monitoring already run a configuration store, since adding one for Patroni is an operating cost you must own. Finally, run a failover drill with your expected network and storage conditions, and record how long clients take to reconnect. Your version and license checks should use the Patroni documentation and the CloudNativePG documentation for current supported versions.
Which scenario points to Patroni and which to CloudNativePG
This table maps common team situations to the better fit between Patroni on virtual machines and the CloudNativePG operator on Kubernetes. Read each row for the condition that tips the choice, and treat the environment questions as the points to settle with your own platform owners before committing.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Existing VM fleet with no Kubernetes control plane | Patroni | Patroni runs on the VMs you already operate and needs a distributed configuration store (etcd, Consul, ZooKeeper or Kubernetes). If no Kubernetes cluster exists, adopting CloudNativePG would also mean adopting Kubernetes operations. |
| Platform team already running Kubernetes in production | CloudNativePG | CloudNativePG uses the Kubernetes API server for failover, so it avoids a separate configuration store. This favors teams that already staff Kubernetes skills and monitoring for stateful workloads. |
| Air-gapped or disconnected estate | Depends on the environment | Both need internal mirrors for packages and container images. Patroni adds an etcd or Consul cluster to host and back up. CloudNativePG adds a Kubernetes cluster to host and patch. Confirm which of these your air-gapped network can support. |
| Mixed estate with VMs and Kubernetes | Depends on the environment | Choose one HA model per database tier where possible. Running both models in parallel doubles the runbooks, backup jobs and upgrade cycles. Ask which layer your platform team can operate consistently. |
| Need for several PostgreSQL major versions at once | Depends on the environment | Patroni documents support for PostgreSQL 9.3 to 18. CloudNativePG manages the versions supported by the PostgreSQL Global Development Group. Confirm the exact versions and image policy you need against each project's current documentation. |
| Backups to object storage with point-in-time recovery | CloudNativePG (by built-in tooling) | CloudNativePG supports Barman Cloud plugin backups, volume snapshots and WAL archiving with point-in-time recovery. With Patroni, you typically choose and operate a separate backup tool such as pgBackRest or Barman. |
| Team has DBAs but limited Kubernetes experience | Patroni | Patroni's failover is driven by a configuration store and a REST API that database teams can inspect directly on VMs. Operating a Kubernetes control plane is a separate skill set that must be budgeted for. |
How each design keeps one primary and what that means for operations
Both designs aim to keep one writable PostgreSQL primary and promote a standby when it fails, but they put the decision in different places. Patroni keeps that logic in an agent beside each database and a shared configuration store, while CloudNativePG keeps it in an operator that works through the Kubernetes API. The cards below set out the parts of each design and what they mean for upgrades and routine operations.
Patroni agent and configuration store
Patroni runs an agent next to each PostgreSQL instance, and the members hold leadership through a distributed configuration store. You choose that store yourself: ZooKeeper, etcd, Consul or Kubernetes. The store's health, quorum and access rules become part of your failover path, so check who operates it, how it is backed up and how it is monitored. Patroni documents itself as a template that needs configuration for each deployment, so the design and its settings are your responsibility.
Patroni REST API for control
Patroni exposes a REST API for health checks, cluster status, configuration, switchover, failover, restarts, reloads and reinitialization. Load balancers and runbooks can call it directly, which suits teams that already script around HTTP endpoints. Confirm that the API is restricted to the right networks and credentials, because switchover and reinitialization are powerful operations that can disrupt a live primary.
CloudNativePG operator and API server
CloudNativePG reads and writes cluster state through the Kubernetes API server, so failover does not depend on an external consensus tool such as Patroni. Promotion, replica management and quorum-based failover run inside the operator's reconciliation loop. The operational question shifts to the health of your Kubernetes control plane and its etcd, because the operator is only as available as the cluster it runs on.
Direct PVC management instead of StatefulSets
CloudNativePG manages persistent volume claims directly rather than through StatefulSets. Teams used to StatefulSet behavior should check how storage classes, volume expansion and pod replacement are handled during node drains and cluster upgrades. Your storage team also needs to confirm that the CSI driver behind your chosen storage class supports the snapshot and resize operations your backup plan relies on.
Upgrades and version lines
With Patroni, you upgrade the operating system, the Patroni package and PostgreSQL on each node, and you plan the order yourself. CloudNativePG publishes new operator and image versions that you roll out through Kubernetes, and it tracks PostgreSQL versions maintained by the PostgreSQL Global Development Group. Ask each vendor how a minor PostgreSQL update and a major upgrade are sequenced, and whether a rollback path exists before you schedule one.
Day-two skills and on-call load
Patroni teams need Linux administration, PostgreSQL replication knowledge and the operation of their chosen configuration store. CloudNativePG teams need Kubernetes operations, including RBAC, storage, upgrades of the cluster itself and operator troubleshooting. Decide which skill set your on-call rotation already has, because a failover that works in a lab can still stall when the people paged do not know the layer that failed.
Capability by capability: what the supplied facts support
This table sets Patroni on virtual machines against the CloudNativePG operator on Kubernetes, row by row, on the capabilities the supplied facts cover. Where a row shows a dash or a gap, the fact is not in our research, so confirm it with the project before you rely on it. Read the table as a map of what each tool does itself and what you must supply around it.
| Capability | Patroni | CloudNativePG |
|---|---|---|
| License | MIT licensed | Apache-2.0, CNCF Sandbox project |
| Runtime model | Python template that runs beside each PostgreSQL instance on a VM or container; needs configuration per deployment | Kubernetes operator that manages PostgreSQL clusters through the Kubernetes API |
| Supported PostgreSQL versions | Runs PostgreSQL 9.3 to 18 according to the Patroni documentation | Manages the PostgreSQL versions supported by the PostgreSQL Global Development Group; confirm the exact matrix for your release |
| Distributed configuration store | Requires ZooKeeper, etcd, Consul or Kubernetes; you operate that store | No external store; failover uses the Kubernetes API server |
| REST API | Exposes health checks, cluster status, switchover, failover, restarts, reloads and reinitialization | Managed through Kubernetes resources; confirm which operational actions are exposed outside the Kubernetes API |
| Synchronous replication and quorum commit | Supports synchronous replication including quorum commit | Supports quorum-based failover and synchronous replication |
| Standby clusters | Supports standby clusters (per the Patroni documentation) | Not covered by our supplied facts; confirm with the project |
| Watchdog support | Supports watchdog devices to guard against split brain | Not covered by our supplied facts; confirm how node fencing is handled in your Kubernetes setup |
| Object storage backups | Not a backup tool; pair with a separate backup solution you select and operate | Backups to object storage through the Barman Cloud plugin, plus WAL archiving with point-in-time recovery |
| Volume snapshot backups | Not covered by our supplied facts; confirm with your backup tooling | Volume snapshot backups supported |
| Built-in PgBouncer pooling | Not included; deploy PgBouncer separately | Built-in connection pooling with PgBouncer |
What each license and edition covers
Patroni is released under the MIT license, one of the most permissive open source licenses, so you can run, modify and redistribute it inside your own infrastructure without a license fee. It is a Python template for building high availability PostgreSQL clusters on virtual machines, and it originated at Zalando. Because it is a template rather than a packaged product, every deployment needs its own configuration.
- No paid edition: The supplied facts do not describe a commercial Patroni edition or a vendor-sold subscription.
- Cost is in the work: Your costs are the distributed configuration store (etcd, Consul, ZooKeeper or Kubernetes), the servers and the staff who build and maintain the configuration.
- Maintained releases: Patroni 4.1.5 and 4.0.11 were both released on August 12, 2026, which shows two active release lines.
- Commercial help is separate: Any support contract would come from a third party or from DeployOpen under its own written scope, not from the project itself.
Before you rely on Patroni in a regulated environment, confirm with your own review which license obligations apply to your modifications and whether any third party offers support terms you would need to contract for.
CloudNativePG is an Apache-2.0 licensed Kubernetes operator for running PostgreSQL. It is a CNCF Sandbox project, and it was originally developed by EDB before becoming community driven. Apache-2.0 allows commercial use, modification and redistribution, and includes an explicit patent grant, which many legal teams review as part of their open source approval.
- Permissive license: Apache-2.0 permits use and modification without a license fee, subject to its attribution and notice terms.
- Sandbox status: CNCF Sandbox is an early stage of the CNCF project lifecycle, so review its maturity and governance against your own adoption criteria.
- Origin at EDB: EDB started the project, but the documentation describes it as community driven today. Confirm how governance and roadmap decisions are made before you assume vendor stewardship either way.
- Maintained lines: CloudNativePG 1.30.1 and 1.29.3 were both released on September 23, 2026, showing two maintained minor lines.
- No paid edition named: The supplied facts do not list a paid CloudNativePG edition. Ask any commercial provider for written support terms and what they cover.
Ask whether the Sandbox level and the community governance model meet your procurement and risk policies, and get the support scope in writing.
PostgreSQL is released under the PostgreSQL License, a liberal open source license similar to the BSD and MIT licenses. The license lets you use, change and redistribute the database without royalties. The project does not sell a paid edition, and the database itself is maintained by the PostgreSQL Global Development Group. Both Patroni and CloudNativePG run this same database, so its license applies to every option in this comparison.
- Liberal terms: The PostgreSQL License is similar in scope to BSD and MIT, so it places few obligations on redistribution.
- Support windows: PostgreSQL 18 is supported until November 14, 2030, while 14 is supported until November 12, 2026. Plan your upgrade path around these dates.
- Minor and major cadence: Minor releases come at least once every three months, and a new major version arrives about once a year.
- Commercial support is external: Vendors and consultancies may sell PostgreSQL support, but the supplied facts do not name a single commercial edition from the project.
Check the support window for your chosen major version and confirm with your vendor or DeployOpen's written scope who will carry patches for any version you run.
What drives the running cost of each option
Running cost splits into who pays for what, and the split differs sharply between the two options. With Patroni on virtual machines, you pay for compute and storage for at least the PostgreSQL nodes, the configuration store (etcd, Consul, ZooKeeper or Kubernetes as the DCS), backup storage and the staff who patch and upgrade all of it. With CloudNativePG, you pay for the Kubernetes worker capacity that hosts the instances, the persistent volumes it claims, backup storage for the Barman Cloud plugin or volume snapshots, and the skills and tooling your platform team already needs to run Kubernetes. The one-time build cost is the initial design, automation and failover testing. The recurring costs are infrastructure, storage growth, backup retention, and the staff time spent on minor and major upgrades. Ask any quote to name each of these lines separately, and to state whether the configuration store and the Kubernetes control plane are included or assumed to exist already.
Recurring effort is driven mostly by release cadence. PostgreSQL minor releases arrive at least once every three months and never change the internal storage format, so each one means replacing executables and restarting. Under Patroni, that restart and the rolling sequence across nodes are your work to script and verify. Under CloudNativePG, the operator orchestrates instance restarts, but you still schedule the image update and validate it. Major upgrades cost more under either option, since PostgreSQL 18 is supported until November 14, 2030 and the upgrade path (pg_upgrade, dump and restore, or logical replication) must be rehearsed against your data volume. Ask the vendor or integrator to price a rehearsed minor upgrade and a major upgrade separately, and to state how many staff hours per cycle they assume.
Watch the cost drivers that move the number up or down: the number of clusters and replicas, the synchronous replication setting (which requires more nodes to keep quorum), backup retention and WAL archive volume, and whether you need a standby cluster in a second site. A useful check before signing anything is to ask who will be on call for a failed backup restore, and whether that cost is in the quote. Illustrative example: a team with three clusters that shares one Kubernetes platform may find the marginal cost of a fourth cluster low under CloudNativePG, while under Patroni each new cluster adds its own VMs and configuration store scope. Confirm this against your own node sizing rather than accepting it as general.
Moving from one option to the other
This sequence moves a PostgreSQL estate from Patroni on virtual machines to CloudNativePG on Kubernetes, or the reverse, while keeping data, backup history and a tested rollback path. Each step ends with a check that tells you whether the next one can start.
Inventory databases, versions and backup chains
Record every cluster, database, extension and PostgreSQL major version in use, along with replication topology, connection pooling and the current backup tool and retention. Your platform or database team owns this list, and DeployOpen can produce it as part of a written scope if you want an outside pass. The step is done when each database has one owner, one target version and a documented backup chain that you have confirmed can restore. Check which extensions exist on both sides, since Patroni supports the Citus extension and CloudNativePG has its own supported extension and image terms that you should confirm with the project before relying on them.
Confirm the target PostgreSQL version and images
Pick a PostgreSQL major version that both tools support and that is still inside its support window. PostgreSQL 14 is supported until November 12, 2026, while 15 through 18 run later, so a move that starts now should avoid 14 unless a longer window is not needed. Patroni runs PostgreSQL 9.3 to 18, and CloudNativePG manages the versions the PostgreSQL Global Development Group supports, so confirm the exact images, Python or Kubernetes prerequisites and operator version against the current documentation. The step is done when the target version, image source and operator or Patroni release are written down and approved.
Build the target cluster beside the source
Stand up the new topology in parallel: Patroni with its configuration store (etcd, Consul, ZooKeeper or Kubernetes) on VMs, or a CloudNativePG Cluster resource on Kubernetes with persistent volume claims and backup configuration. Nothing transfers in this step, so the source keeps serving traffic. Set up synchronous or asynchronous replication policy, watchdog settings and pooling deliberately, because these are rebuilt rather than copied. The step is done when the new cluster elects a primary, passes health checks and shows the expected replication state under a test workload.
Replicate or upgrade with a supported method
Choose one of the PostgreSQL methods for moving data: logical replication, which works between different major versions and can cut over with only several seconds of downtime according to the PostgreSQL upgrading documentation; pg_upgrade for in-place major upgrades on the same platform; or dump and restore for smaller databases. Logical replication does not carry DDL, sequences or large objects, so you must add those by hand before cutover. Physical streaming replication cannot cross to a different tool stack in a way you can rely on for a platform move, so treat it as a same-version step only. The step is done when row counts, sequences and large objects match on both sides and replication lag is stable.
Validate restores and failover behavior
Restore the most recent base backup and WAL archive into a scratch environment on the target platform, then perform point-in-time recovery to a chosen timestamp. Test a planned switchover and an unplanned primary loss in the target cluster, and confirm that applications reconnect through the new endpoint. Both tools rely on different failover designs, so record which component decides the new primary and what happens when the configuration store or Kubernetes API is unavailable. The step is done when a restore completes, the recovered data matches your acceptance queries, and each failover test produces the expected single primary.
Cut over applications and freeze the source
Schedule the cutover with the application owners, stop writes on the source, let the replication stream drain, confirm that the sequences match, and point connection strings, DNS or pooler configuration at the new primary. Keep the old cluster intact and read-only for the rollback window that your change process sets. The step is done when application smoke tests pass against the new endpoint, monitoring shows normal replication and write activity, and the rollback steps have been written down and rehearsed. Confirm with your change approver how long the source must remain available.
Decommission the source and retire old backups
After the agreed rollback window closes, remove the old cluster, its watchers and its scheduled backup jobs, and archive the final backup set under your retention policy. Remove or update runbooks, alerts and access grants that referenced the old platform. Keep an audit record of what was deleted, when, and by whom, since that record is evidence for compliance reviews. The step is done when the old endpoints no longer accept connections, the final backups are catalogued and restorable from the archive, and the operating documentation for the new platform is accepted by the owning team.
Where implementation projects usually run long
Most delays on a Patroni or CloudNativePG project come from the client's environment before any PostgreSQL setting is touched. For Patroni, the longest item is usually the distributed configuration store (etcd, Consul, ZooKeeper or Kubernetes). Someone has to build it, size it, place its members across failure domains and prove that losing one member does not stall leader election. Patroni is a template that needs configuration for each deployment, so the work includes the patroni.yml settings, watchdog device choices, the REST API access controls and the failover tests that show the cluster promotes a standby and that the old primary does not accept writes. Ask who owns the configuration store after handover and whether that team can run its own failure tests.
For CloudNativePG, the delays sit in the Kubernetes platform. Teams need to confirm the Kubernetes networking model (pod-to-pod paths, service exposure, network policies and any ingress or load balancer used for client connections), the storage classes that back the PersistentVolumeClaims, and how volume snapshots behave on those classes. Backup restore testing is the item most often cut short. A WAL archive and an object store target through the Barman Cloud plugin, or volume snapshot backups, prove nothing until a point-in-time restore has been run into a separate environment and the team has timed it against its own recovery goals. Ask for the restore test plan and the acceptance criteria in writing before the schedule is set.
Authentication design adds delay on both sides. PostgreSQL documents password, GSSAPI, SSPI, LDAP, RADIUS, certificate, PAM and OAuth methods, and PostgreSQL 18 deprecated MD5 password authentication in favor of SCRAM. Decide which methods apply to replication, application roles and administrators, and how pg_hba.conf rules and certificate chains will be managed across the cluster. Those decisions depend on the identity provider and directory the client already runs, so the people who own them should join early. The fixed-scope agreement is where this is controlled: a written statement of which configuration stores, storage classes, backup targets, authentication methods and failure tests are in scope, what the client must provide and when, prevents an unmanaged environment gap from becoming an open-ended change request.
Questions buyers ask before choosing an option
What drives the cost of running Patroni compared with CloudNativePG?
Licensing does not separate them: Patroni is MIT licensed and CloudNativePG is Apache-2.0, so the cost is mostly labor, infrastructure and support. For Patroni, the cost sits in the VM fleet, the configuration store (etcd, Consul, ZooKeeper or Kubernetes), load balancing, backup tooling and the people who build and patch that stack. For CloudNativePG, the cost sits in the Kubernetes platform beneath it, its storage classes and the operator upkeep. Ask any implementation partner for a quote that lists each component separately, marks what is one-time (design, build, hardening, migration) and what recurs (upgrades, backup testing, on-call and retainers), and states which environment it assumes. DeployOpen does not publish a price list; a quote follows from the written scope.
How long does a typical PostgreSQL high availability implementation take?
No supplied fact gives a duration for either option, so treat any single number you hear with caution. The timeline is set by the size of the environment, how many clusters are involved, whether a Kubernetes platform already exists, the backup target that must be built, and the number of applications to migrate and test. A Patroni build on VMs adds work for the configuration store and load balancing. A CloudNativePG build depends on how mature the Kubernetes platform and storage are. Ask for a timeline tied to written deliverables and a named list of environments, and ask what the plan assumes about your change windows.
What does the work need from our own team?
Either option needs people who own the database after handover. Your team needs to decide on the backup retention and recovery targets, supply network, DNS and storage access, approve changes, and run the failover tests that prove the design works. With Patroni, the team also owns the VM images, the configuration store, the REST API integration and the load balancer. With CloudNativePG, the team owns the Kubernetes cluster, its storage, its upgrade cadence and its ingress and secret handling. Ask the partner to name which tasks transfer to you and which stay with them under a retainer.
Can a team run Patroni or CloudNativePG without outside help?
Yes, a team can run either one without outside help if it already has the skills for the platform underneath it. A team that runs VMs, a distributed configuration store and a load balancer well can operate Patroni. A team that already runs Kubernetes in production, with dependable storage and backup routines, can operate CloudNativePG. The gap usually shows up in failover drills, restore testing and version upgrades, where PostgreSQL's own documentation says automatic failover needs external tools and minor releases mean replacing executables and restarting. Before deciding, run a restore and a failover test with your own staff and count the hours it takes.
Which option needs fewer specialist skills to operate?
It depends on the skills you already hold, and neither option is simpler in general. Patroni asks for skills in Python-based tooling, the chosen distributed configuration store, PostgreSQL replication and load balancing on VMs. CloudNativePG asks for Kubernetes operations, storage behavior under persistent volume claims and the operator's custom resources. If your team already runs Kubernetes, CloudNativePG keeps database work inside the same tooling, and if it does not, adding Kubernetes just for PostgreSQL is a large skill investment. Ask which of these skills the partner will transfer through documentation and training.
What does switching from one option to the other later involve?
Switching means moving data and changing the failover design, not just swapping software. PostgreSQL's logical replication works between major versions and can keep downtime to several seconds for a major upgrade, which is a useful building block for a cutover. Either direction also needs new backup routines, new connection endpoints for applications and rehearsed failover tests. Ask any partner to describe how they would replicate the data, cut over the applications, keep the old cluster as a fallback and retire it, and what it would cost to keep both running during the move.
How do backups and recovery differ between the two?
Both options can use object storage backups with WAL archiving and point-in-time recovery, but the tooling differs. CloudNativePG supports backups to object storage through the Barman Cloud plugin, volume snapshot backups and WAL archiving with point-in-time recovery. Patroni manages the high availability layer and does not replace a backup tool, so the backup design is a separate build that your team or partner must choose and test. Whichever you pick, ask for a restore test with a recorded recovery time and a defined point-in-time target, since a backup that has not been restored is unproven.
Does the choice affect security and compliance evidence?
Both options can support the controls an assessor will ask about, but the evidence comes from your environment, not from the database tool. PostgreSQL supports several client authentication methods, including certificate, LDAP and OAuth, and PostgreSQL 18 deprecated MD5 password authentication in favor of SCRAM. Each option adds its own access paths: the Patroni REST API and configuration store on one side, and the Kubernetes API and secrets on the other. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors do that. Ask which control evidence the partner will prepare and which your assessor will still need to collect.
How DeployOpen helps you choose and run either option
DeployOpen plans, implements, hardens, documents and supports self-hosted PostgreSQL high availability inside your own infrastructure, whether that is virtual machines with Patroni or Kubernetes with CloudNativePG. We start from your platform, recovery targets and team skills, so the choice between the two is made on written evidence rather than preference.
How we scope
- Confirm where the databases will run: VMs, Kubernetes, or both, inside your cloud, data center or air-gapped network.
- Document the failover design, synchronous replication needs, and read traffic on standbys before any build starts.
- Agree the written scope, deliverables and timeline in writing, since most engagements are fixed-scope.
- Record which PostgreSQL major versions and minor-release cadence your team must keep current.
How we build
- Deploy either a Patroni cluster with its chosen configuration store or a CloudNativePG cluster on your Kubernetes platform.
- Configure the backup path you select, such as object storage through the Barman Cloud plugin or volume snapshots with WAL archiving.
- Set up connection pooling, client authentication and TLS settings to match your access and security policy.
- Test failover, switchover and point-in-time recovery against the recovery targets agreed during scoping.
How we hand over
- Deliver runbooks for switchover, failover, restore and PostgreSQL minor and major upgrades in your environment.
- Walk your operations and platform staff through the Patroni REST API or the CloudNativePG resources they will use daily.
- Document configuration, backup schedules, restore evidence and the ownership of each layer for your audit trail.
- Confirm with your team which skills they hold and which training or handover sessions the written scope includes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Plan minor release rollouts and major version upgrades against the PostgreSQL support windows your team needs.
- Re-test failover and backup restores after changes to Kubernetes, the configuration store, or the storage layer.
- Ask for the retainer scope, response expectations and upgrade responsibilities in writing before you sign.
