Patroni vs CloudNativePG: when each one fits
Choose Patroni when your PostgreSQL clusters run on virtual machines or bare metal and your team already operates that estate. Patroni is an MIT-licensed high availability manager that runs PostgreSQL 9.3 to 18 and keeps leader election in an external distributed configuration store such as etcd, Consul, ZooKeeper or Kubernetes. Choose CloudNativePG when the databases already live on Kubernetes and your platform team is comfortable with operators, custom resources and PersistentVolumeClaims. CloudNativePG is an Apache-2.0 CNCF Sandbox operator that uses the Kubernetes API server for failover, so it needs no separate consensus store. The decision turns on four things: where your platform footprint is, which skills your team already has, who owns failover decisions, and which backup tooling you have standardized on.
Ask who will be paged at 2 a.m. for a failover that did not complete cleanly. With Patroni, the database team owns the configuration store, the Patroni agents, the HAProxy or virtual IP layer that routes clients, and the failover settings. With CloudNativePG, the operator reconciles the cluster, but the platform team also owns the Kubernetes control plane, storage classes and node drains that can trigger switchovers. Confirm the storage path before deciding: CloudNativePG depends on how your Kubernetes storage performs and recovers, and Patroni depends on the disks and network under each VM. Check which backup approach your organization already uses, because both projects work with external backup tooling and you should confirm the exact integration and restore procedure against each project's documentation for your PostgreSQL version.
Which scenario favors Patroni or CloudNativePG
This table maps common operating scenarios to the platform that usually fits best, and names the condition that drives each choice. Read each row against your own estate: where the condition is weak or unknown, both options can be reasonable and the row says so. The main takeaway is that where your databases run and what your team already operates matter more than feature checklists.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| PostgreSQL on VMs in a private data center | Patroni | Patroni runs PostgreSQL 9.3 to 18 on hosts you already manage and uses an external store (etcd, Consul, ZooKeeper or Kubernetes). Choose it when the databases stay on VMs and no Kubernetes cluster is planned. |
| Existing Kubernetes platform team | CloudNativePG | CloudNativePG is a Kubernetes operator that uses the Kubernetes API server for failover without external tools. Choose it when your platform team already runs GitOps, storage classes and cluster operations. |
| Mixed VM and container estate | Either, depending on where most databases run | If most databases sit on VMs, Patroni keeps one HA model. If most sit in clusters, CloudNativePG reduces moving parts. Running two HA models is the main cost to avoid, so confirm which workloads move and when. |
| Air-gapped sites | Either, after confirming offline install paths | Both are open source, but a disconnected site needs offline packages, images and backup targets. Patroni on VMs needs fewer cluster dependencies; CloudNativePG needs a Kubernetes distribution that installs offline. Confirm both with your vendor and environment. |
| Team with no Kubernetes experience | Patroni | Patroni adds a configuration store and a PostgreSQL agent on hosts your team can already administer. CloudNativePG asks for Kubernetes skills in storage, networking and upgrades before database work begins. |
| Team with strong PostgreSQL DBA skills but limited Kubernetes skills | Patroni | Database failover, replication and backup tuning carry over directly to Patroni. Choose CloudNativePG only if someone on the team can own the Kubernetes layer long term. |
| Need for a single declarative cluster definition | CloudNativePG | CloudNativePG manages PostgreSQL clusters as Kubernetes resources, so cluster state lives in the same version-controlled manifests as the rest of the platform. Patroni configuration lives in its own files and store. |
| Compliance evidence across both layers | Either, if the evidence plan is written first | Both need documented failover tests, backup restore tests and access controls. Assessors judge the evidence, not the tool. Ask each option for its recovery test procedures and log outputs before choosing. |
How Patroni and CloudNativePG are built and deployed
Patroni and CloudNativePG both keep a PostgreSQL primary available, but they get there with different parts. Patroni adds an agent to each database node and relies on a separate distributed configuration store, while CloudNativePG runs inside Kubernetes and uses the API server for coordination. The cards below cover the components, how failover is decided, and what each design asks of your operations team.
Patroni agent on each node
Patroni runs as an agent beside every PostgreSQL instance and manages that instance's startup, replication role and promotion. Each agent reads and writes shared cluster state, so the health of the agents and of the database itself must be watched together. Check how your team will deploy and upgrade the agent across VMs, since it is part of the data path for every failover. Patroni supports PostgreSQL 9.3 to 18, so confirm your major version is in that range before you commit.
Distributed configuration store dependency
Patroni uses ZooKeeper, etcd, Consul or Kubernetes as its distributed configuration store. Unless you choose Kubernetes as that store, your team must deploy, secure, back up and monitor a separate consensus cluster alongside the databases. That store is a dependency for leader election, so its availability and quorum shape the availability of the database cluster. Ask whether your platform team already runs one of these stores and who holds its on-call rota.
Operator managing PVCs directly
CloudNativePG is a Kubernetes operator that manages PersistentVolumeClaims directly rather than wrapping the database in StatefulSets. Your platform team reviews the operator's custom resources, storage classes and pod placement like any other Kubernetes workload. This design suits teams that already run Kubernetes operations, and it changes who needs to understand the storage layer. Confirm your storage class supports the volume behavior your recovery plan assumes.
Failover coordination paths
Patroni decides leadership through its configuration store, so a failover depends on that store reaching quorum as well as the database nodes. CloudNativePG uses the Kubernetes API server for failover without external tools, so its coordination follows the control plane you already operate. Ask how each option behaves during a control plane or store outage, and rehearse both a node loss and a coordination loss. Test the failover path with the workloads and network policies you run in production.
Upgrades and component versioning
Each approach has its own release stream that you must track alongside PostgreSQL. Patroni 4.1.5 was released on August 12, 2026, and CloudNativePG 1.30.1 was released on September 23, 2026, so check each project's current release notes before planning upgrades. In Patroni you upgrade the agent and the store separately from the database, while in CloudNativePG the operator and the database images move through Kubernetes rollouts. Document which team owns each component and how a version change is tested.
Day-two skills and ownership
Patroni asks operators to be fluent in PostgreSQL replication, the configuration store and host-level service management. CloudNativePG asks them to be fluent in Kubernetes objects, storage and the operator's lifecycle. Neither removes the need for database administration, backup verification or failover drills. Write a skills matrix for your team before you choose, and identify who answers the pager at 3 a.m. for each stack.
Patroni and CloudNativePG side by side on supported features
This table compares the two PostgreSQL high availability options on license, version support, configuration store, deployment target, failover, storage, maturity and release cadence. Where a supplied fact is missing, the cell tells you what to confirm in the vendor documentation. Read it as a starting checklist, not a verdict, since the right choice depends on where your databases already run.
| Feature | Patroni | CloudNativePG |
|---|---|---|
| License | MIT | Apache-2.0 |
| PostgreSQL version support | PostgreSQL 9.3 to 18 | Confirm the supported PostgreSQL major versions in the CloudNativePG documentation |
| Distributed configuration store | ZooKeeper, etcd, Consul or Kubernetes | Kubernetes API server, with no external store required |
| Deployment target | Virtual machines or containers, outside or inside Kubernetes | Kubernetes clusters only |
| Failover mechanism | Leader election through the chosen configuration store | Managed by the operator through the Kubernetes API server, with no external tools |
| Storage handling | Confirm volume and filesystem layout with your VM or storage team | Manages PersistentVolumeClaims directly instead of StatefulSets |
| Project maturity | Confirm governance and foundation status in the Patroni project pages | CNCF Sandbox project |
| Latest release cadence | 4.1.5, released August 12, 2026 | 1.30.1, released September 23, 2026 |
What each license covers and what support costs
Patroni is released under the MIT license. In practice, your team can run it in production, add it to internal server images, modify it to fit your change control and redistribute modified builds inside your organization without asking the project for permission. The license asks that the copyright notice and permission text stay with substantial copies, and it disclaims warranties. The project therefore carries no contractual duty to fix a defect in your environment, and any response time you need must come from an agreement with a named supplier.
- Internal use and modification: You can change failover logic, logging or configuration handling, provided the license notice travels with your copies.
- Redistribution: If you package Patroni into an image for a subsidiary, a managed service or a customer, carry the MIT notice with that package.
- Warranty: The license disclaims warranty, so guarantees about defect fixes belong in a contract.
- Version coverage: The Patroni documentation states support for PostgreSQL 9.3 to 18, and Patroni 4.1.5 was released on August 12, 2026. Confirm your PostgreSQL major version against the current documentation before you commit.
- Configuration store: Patroni can use ZooKeeper, etcd, Consul or Kubernetes. The license does not change which store you run, so the skills and support for that store are a separate line item.
Confirm with your legal team whether your auditors expect a supplier-backed build, because the MIT license alone does not establish one.
CloudNativePG is an operator licensed under Apache-2.0 and is a CNCF Sandbox project. Like MIT, the license lets your team use, modify and redistribute the code inside your organization. It adds an express patent license from contributors and requires that changed files be marked and that any NOTICE file be carried with redistributions. For a platform team that builds its own operator images, these conditions are routine, but the legal review should happen before the first build goes into a regulated environment.
- Internal use and modification: Teams can alter the operator, its images or its Kubernetes manifests, and must mark the files they changed.
- Patent terms: Apache-2.0 includes an express patent grant from contributors, which MIT does not spell out. Ask counsel to confirm how this fits your procurement policy.
- Sandbox status: CNCF Sandbox is an early stage in the foundation's process. Ask the maintainers about their release commitments and the size of the active maintainer group.
- Version coverage: CloudNativePG 1.30.1 was released on September 23, 2026. Check the CloudNativePG documentation for the PostgreSQL versions and Kubernetes versions your release supports.
- Warranty: Like MIT, Apache-2.0 disclaims warranty, so support obligations must be written into a separate agreement.
Confirm that your Kubernetes platform and storage class meet the operator's requirements before you treat the license as the only open item.
Neither the Patroni nor the CloudNativePG sources supplied for this page describe a paid edition, a subscription or an enterprise support tier. Do not assume one exists. Ask the maintainers and any service provider directly what commercial support they offer, what it covers and how it is priced. The license costs are not the main budget line for either project, so the real cost comes from infrastructure, staff time and any external implementation or support work.
- Infrastructure: Virtual machines or Kubernetes nodes, storage, network and backup targets recur every month.
- Internal staff: Your database, platform and security teams carry operation, upgrades and restore testing.
- External implementation: DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope and timelines agreed in writing before work starts.
- Ongoing support: DeployOpen offers ongoing support as a retainer. It publishes no price list, and a quote follows from the written scope.
- Quote requests: Ask for the scope, deliverables, upgrade responsibility, backup restore testing, support hours and who owns PostgreSQL major version upgrades.
Before you sign, ask the vendor or service provider to state in writing which named people answer incidents and how long they have to respond.
What drives the running cost of PostgreSQL high availability
The running cost of a Patroni deployment and a CloudNativePG deployment comes from the same few places, but they are paid for in different budgets. With Patroni, you pay for the virtual machines that run PostgreSQL and Patroni, the storage attached to each node, the distributed configuration store (etcd, Consul, ZooKeeper or Kubernetes itself) and the load balancer or DNS layer that routes clients to the current primary. Patroni is MIT licensed, so the software line item is zero, but your team or a services partner pays for the configuration store cluster, its monitoring and its upgrades. With CloudNativePG, you pay for Kubernetes worker nodes, persistent volumes managed through PVCs, and the platform itself. CloudNativePG is Apache-2.0 licensed and does not require an external failover tool, so the configuration store cost drops out, but the Kubernetes cluster becomes a shared dependency that has its own cost and skills requirements. Ask each vendor or partner to price these components separately so you can see which ones your estate already owns.
Setup is mostly one-time work: designing the topology, writing the Patroni or operator manifests, wiring backups, and testing failover and restore. Operation is recurring and usually costs more over the life of the system. It includes monitoring replication lag, rotating credentials, testing restores, applying minor PostgreSQL and tool releases, and planning major version upgrades. Check the supported release windows before you commit. Patroni 4.1.5 was released on August 12, 2026 according to its GitHub releases, and CloudNativePG 1.30.1 was released on September 23, 2026 according to its GitHub releases, so both projects change on a steady cadence that your team has to absorb. Backup storage is a recurring cost in either design. Confirm the retention period, the object storage location and whether backups are copied to a second site, because each of those drives the bill.
When you request a quote, ask for a written list of components with the owner of each one, the one-time setup tasks, the recurring operational tasks with their frequency, and the assumptions behind the storage and backup sizing. Ask whether support covers the PostgreSQL version, the failover tool or operator, and the Kubernetes distribution separately, since a support contract for one may not cover the others. DeployOpen does not publish prices, and a quote follows from the written scope, so the scope must name the platforms, the environments and the number of clusters involved. Also ask who will perform the first major upgrade and what it will cost in time, because that is where many PostgreSQL high availability budgets are underestimated. The CloudNativePG documentation and the Patroni documentation describe the operational tasks that the scope should cover.
Moving a PostgreSQL cluster from Patroni to CloudNativePG or back
This sequence moves a PostgreSQL service between a Patroni-managed VM or bare-metal cluster and a CloudNativePG cluster on Kubernetes without a long unplanned outage, and leaves the team with a tested rollback path. The direction works both ways, but the Kubernetes skills and storage work fall on whichever side is the target.
Inventory databases, extensions and connections
Before any build starts, list every database, schema, role, extension, PostgreSQL major version and connection path that touches the cluster, including application connection strings, connection poolers, scheduled jobs and replication consumers. Confirm which extensions the target operator image ships and supports, because a missing extension can block cutover late in the project. The output is a signed inventory that the application owners and the database team both accept. Confirm the exact extension list with the CloudNativePG documentation and your own version pins, since support differs by image.
Design backup and restore on the target
Decide how the target will take base backups and continuous WAL archiving, where the archive lives, how retention is set and who holds the decryption keys. CloudNativePG handles backup through its own resources, while Patroni deployments usually rely on tools such as pgBackRest or Barman set up by the team, so the existing backup chain is not copied across as is. Run a restore test into a scratch namespace or host and record the time it takes and the point-in-time recovery window it achieves. The check that closes this step is a successful restore of a recent backup to a usable state, not only a successful backup job.
Build the new cluster alongside the old
Provision the target cluster in its own environment, with storage classes, network policies, TLS, secrets management and monitoring configured before any data arrives. On the Kubernetes side, the work includes storage provisioning for persistent volume claims and node placement for the instances. On the VM side, it includes the distributed configuration store and the host-level HA networking. The old Patroni cluster keeps serving traffic throughout. The step is complete when the new cluster passes health checks, a failover drill inside the new environment, and a review of its alerts with the on-call team.
Replicate data and verify it
Establish replication from the running Patroni primary to the new cluster, or load a base backup and stream changes, depending on the chosen method and the size of the database. Logical replication is the usual route when the major version or extension set changes, and it needs its own checks on sequences, large objects and DDL. Compare row counts, checksums on critical tables and sampled query results between the two clusters until they agree. Record the replication lag observed during the largest write window. The step closes when the team can show, with query output, that the copies match.
Cut over connections and freeze writes
Schedule a cutover window agreed with the application owners, stop or pause writers, wait for replication to drain, then repoint connection strings, DNS entries or pooler configuration to the new primary. Keep the old cluster read-only and reachable so that a rollback is still possible during the agreed validation period. Run smoke tests from each application tier and confirm that connections, role grants and sequences behave as expected. The output is a written cutover record with timestamps, the connection changes made and the rollback criteria that the owners accepted.
Rebuild monitoring, alerts and runbooks
Recreate dashboards, alert rules and runbooks for the new cluster, since failover tooling, metric names and escalation paths differ between Patroni and CloudNativePG. Patroni exposes its own status through its REST interface and external configuration store, while CloudNativePG reports through Kubernetes resources and its metrics endpoints. Rewrite the failover runbook so it matches the new control plane, and test each alert with a controlled fault. The step closes when on-call staff have run through the runbook in a drill and signed off on it.
Retire the old cluster with evidence
After the agreed validation period passes without rollback, take a final backup of the old cluster, record its retention location, and then stop replication and decommission the Patroni nodes and their configuration store according to your data retention policy. Remove old credentials, DNS entries and monitoring targets so that nothing still points at the retired cluster. Keep the final backup available for the period your records policy requires. The step is complete when the decommissioning record lists each removed component and the location of the retained backup.
Where Patroni and CloudNativePG projects usually run long
Implementing Patroni is mostly a platform build before it is a database build. The team has to stand up the distributed configuration store (etcd, Consul, ZooKeeper or Kubernetes, which the Patroni documentation lists as supported options), build the virtual machines with consistent PostgreSQL packages, and design the network so that the primary can be reached through a stable endpoint after a switchover. Fencing deserves its own design review. Decide how a former primary is kept from accepting writes after failover, how the configuration store behaves when a network partition isolates one node, and which health checks drive patronictl decisions. Each of these choices is hard to change once data is in production, so settle them in writing before build starts.
Implementing CloudNativePG shifts the work to Kubernetes. The team must confirm the storage classes it will use for PersistentVolumeClaims, because volume behavior during node drain, snapshot support and I/O performance differ by storage backend, and the operator's failover depends on the cluster reaching a healthy state on those volumes. Plan the operator lifecycle as a recurring activity: how the operator is installed, how its upgrades are tested against the cluster, and who approves them. The backup target (an object store reached through the barman-cloud tooling, for example) needs credentials, retention settings and network paths defined before the first scheduled backup runs. Confirm the exact operator and PostgreSQL versions your platform team supports against the CloudNativePG documentation.
Across both options, projects run long in the same three places. Backup and restore testing is often scoped as a configuration task when it is really a recurring exercise: a restore into a separate environment, timed and checked against the recovery objective your business owns. Failover testing needs planned and unplanned scenarios, including loss of the configuration store or a storage node, and the results should be recorded. Runbook handover is frequently underfunded, so ask who will operate the cluster at 2 a.m. and whether they have run each procedure. Timelines depend on the written scope and your environment, including existing identity, network and storage approvals, so ask for a fixed-scope plan that names these three activities explicitly.
Questions buyers ask before choosing or hiring help
What does it cost to run Patroni or CloudNativePG, and what drives that cost?
Both projects are open source, so the license fee is zero and the cost is people, infrastructure and support. With Patroni, you pay for the VMs or bare metal, the distributed configuration store (etcd, Consul, ZooKeeper or the Kubernetes API), load balancing, backup storage and the staff who patch and watch the cluster. With CloudNativePG, you pay for the Kubernetes platform it runs on, storage classes, backup storage and the platform engineers who operate the operator. Recurring costs grow with node count, storage volume, backup retention and the hours spent on upgrades. Ask any vendor or partner for a quote that separates one-time setup from monthly or annual run costs, and that names who carries each line item.
How long does a PostgreSQL high availability implementation take?
The duration depends on the scope you agree in writing, not on the tool alone. The main drivers are whether a Kubernetes platform already exists, how many clusters and databases are in scope, how complex the network and identity integration is, how much testing your change board requires, and whether data migration from an existing instance is included. Neither project gives a fixed implementation time, so treat any timeline you receive as an estimate tied to a written scope. Ask for the milestones, the client dependencies behind each one, and the acceptance tests that close each phase.
What skills must our team have before starting?
Patroni requires Linux administration, PostgreSQL replication and failover knowledge, and working experience with the chosen configuration store, along with load balancer and DNS failover design. CloudNativePG requires Kubernetes operations: storage classes, PersistentVolumeClaims, network policies, RBAC and upgrade procedures for the cluster itself, plus PostgreSQL administration. Both need someone who can read a failover event and decide whether to act. Identify the named people for each skill area, check whether they are on call, and decide whether the team will own day-two work before you pick a path.
Can our team run Patroni or CloudNativePG without outside help?
Yes, many teams do, provided they already run the underlying platform and have a documented runbook. The risk sits in the first failover, the first major version upgrade and the first restore under pressure. Ask yourself whether two or more people can perform a failover drill, restore a backup to a new cluster and roll back a failed upgrade without the original builder. If not, plan a fixed-scope engagement for knowledge transfer, or a retainer for upgrades and continuous testing. DeployOpen implements, documents, backs up, upgrades and supports self-hosted platforms in your own infrastructure, so the split of work is set in the written scope.
How do we test backups and restores for each option?
A backup only counts after a restore has been tested against a stated recovery target. Patroni clusters typically rely on separately configured backup tooling, so you must confirm which tool writes base backups and WAL archives, where they go, and how point-in-time recovery is rehearsed. CloudNativePG manages backups through its own Kubernetes resources, so confirm how backup objects are scheduled, where they are stored, and how restore into a new cluster is exercised. In both cases, ask for a restore drill with recorded timings, a checksum or data validation step, and evidence kept for your compliance assessor. Auditors and certification bodies assess the evidence; DeployOpen prepares the controls and records.
What should a written scope include before we hire help?
A written scope should name the platforms and versions in use, the number of clusters and databases, the failover design (including how clients reach the primary), the backup tool and retention, the identity and secrets integration, and the monitoring and logging hooks. It should list each deliverable, such as runbooks, restore tests and a handover session, and state what is excluded, including application changes and data migration if they are out of scope. Add acceptance criteria, the client responsibilities, the change window requirements and how support is handled after go-live. Most DeployOpen engagements are fixed-scope and agreed in writing before work starts, so ask for that document before you compare quotes.
Is it practical to migrate between Patroni and CloudNativePG later?
Migration is practical but never free, because the two options differ in where the database runs and how it is operated. Moving from Patroni on VMs to CloudNativePG means building Kubernetes capacity, moving storage and backups, rehearsing a cutover with replication or logical copy, and retraining operators. Moving the other way means rebuilding VM images, configuration store and failover tooling. Both paths need a tested rollback plan and a restore that proves the data landed intact. Ask any partner for a migration plan that lists the cutover window, the data validation method and the client staff who will sign off each step.
How DeployOpen helps choose, implement or migrate PostgreSQL high availability
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For PostgreSQL high availability, that means helping your team decide between a VM-based Patroni cluster and a Kubernetes-native CloudNativePG deployment, then building whichever fits your environment.
How we scope
- Written scope covers where your PostgreSQL clusters run, whether on VMs or Kubernetes.
- Scope records the distributed configuration store choice for Patroni, such as etcd, Consul or Kubernetes.
- Scope names the backup tooling, restore targets and failover tests agreed before work starts.
How we build
- Build covers cluster layout, failover behavior, connection routing and storage configuration in your environment.
- Testing includes planned switchovers and simulated node failures, with results recorded against the agreed scope.
- Backup and restore procedures are built and exercised, not only configured, before the cluster is accepted.
How we hand over
- Handover includes runbooks for failover, rejoin, upgrades and backup restore written for your operators.
- Documentation records the design decisions, including why Patroni or CloudNativePG was chosen for your estate.
- Your team receives a walkthrough of day-two tasks so operations do not depend on a single person.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Quotes follow from the written scope. Ask for the scope items, assumptions and exclusions to be listed.
