PostgreSQL on Kubernetes with CloudNativePG

The decision is not whether PostgreSQL can run on Kubernetes with CloudNativePG. It can. The decision is whether your organization gains more from a shared Kubernetes operating model than it pays in additional moving parts for this one database. For some teams the answer is a virtual machine cluster with streaming replication, an external failover tool and object storage backups, and that setup is often the simpler choice. Make the decision explicitly, with the people who will be paged at night, before the cluster design starts.

A VM-based cluster is simpler in four situations. First, the team has little or no Kubernetes operations experience. A CloudNativePG cluster depends on the operator, the custom resources, pod scheduling, persistent volume claims and the Kubernetes API, and an on-call engineer must understand how these interact during a failover. Second, storage performance is sensitive and the storage layer is not well understood. Database latency depends on how the CSI driver, the storage class and the underlying array or software-defined storage behave under load, and a VM with directly managed disks removes one layer of indirection. Third, the platform already uses a VM-based standby pattern, so the existing runbooks, monitoring, backup jobs and staff skills cover the database without a second model. Fourth, the database must be isolated from a shared cluster control plane, for example because a regulator, a data owner or an internal risk function requires that a database outage cannot be caused by a cluster-level change.

Kubernetes adds real value in some of the same areas. Declarative state means the desired Cluster resource in version control describes the topology, PostgreSQL parameters, storage size and backup configuration, and the operator reconciles the running cluster toward it. Rolling changes let the operator replace standbys first and switch over the primary in a controlled order, which matters for minor updates. One operating model means the same tooling, policies, access reviews and deployment pipelines apply to the database as to the applications around it. These benefits are most visible when many teams run many databases on one platform.

The operational load is also real and must be planned for. The Kubernetes control plane stores its state in etcd, so the team must understand etcd backups, membership and quorum, and the cluster's own upgrade cadence. Storage becomes a platform dependency with its own failure modes, snapshot behavior and capacity planning. Network policy must allow replication, operator traffic, backup access and client connections while blocking everything else, and Pod Security Standards and Secrets encryption at rest must be configured for the namespace. Each of these layers has its own upgrade schedule, so the team upgrades Kubernetes and PostgreSQL on separate calendars. Ask the partner or internal team to write down who owns each layer, how each is tested before an upgrade, and what happens to the database during a control plane incident.

A practical test: if the team cannot yet describe how a failed primary is promoted, how the storage class is expected to behave, and how an etcd restore would affect the database, a VM-based cluster with well-tested runbooks is the lower-risk starting point. Plan a path to Kubernetes later if the platform grows. Note that the CloudNativePG documentation and your Kubernetes distribution's release notes should be checked for the versions you intend to run before any of these conclusions are final.

PostgreSQL provides the building blocks for high availability but not the decision logic. Hot standby servers receive changes from the primary, answer read-only queries and can be promoted, yet PostgreSQL does not detect that a primary has failed and notify its standbys. Something outside the database has to make that call. In CloudNativePG, the operator watches each instance, decides when the primary is unhealthy, chooses a replica to promote and repoints the client-facing services at the new primary. Confirm, for the release you plan to run, how failure is detected, which health checks and timeouts apply, and how the former primary is stopped or fenced so it cannot accept writes after promotion. Verify these by simulating a node loss in a staging cluster and recording what the applications saw.

The replication mode determines what a failover can lose. With synchronous replication, a commit returns only after the configured standbys confirm the write, so a promoted standby holds every transaction the application saw acknowledged. The cost is commit latency that depends on the network between instances, and writes can stall when too few standbys are healthy. With asynchronous replication, the primary commits without waiting, so commit latency is lower and the primary keeps accepting writes when standbys fall behind. The cost is that transactions committed on the primary but not yet sent to a standby can be lost on failover. Decide this per workload and record the acceptable data loss for each system. Confirm in the operator documentation which settings control the number of synchronous standbys and what happens when fewer standbys are available than the setting requires.

Point-in-time recovery combines a base backup with archived WAL. The base backup is a full physical copy of the data directory taken at one moment, and the archived write-ahead log records every change after it. A restore can replay forward to a chosen time, such as just before a faulty migration ran. The two pieces depend on each other: a base backup without continuous WAL archiving only restores to the moment it was taken, and a WAL archive without a usable base backup cannot be replayed. Confirm that the operator writes both to object storage outside the cluster, so a lost node or volume does not take the backups with it. Also confirm how retention is enforced and how a recovery target time is requested. Then run a restore into a separate namespace on a schedule and measure how long it takes.

Incremental backups change the cost of frequent full copies. PostgreSQL's pg_basebackup can take incremental backups that record only changes relative to an earlier backup, and pg_combinebackup rebuilds a complete data directory from that chain at restore time. Smaller backups and shorter backup windows are the attraction. The trade-off is a longer restore path: every backup in the chain must be present and intact, and reconstruction must finish before WAL replay can begin. Decide the chain length, how long to keep incremental backups and how often to take a new full base backup. Confirm whether the CloudNativePG release you plan to run uses pg_basebackup incremental backups and pg_combinebackup, or takes full base backups only, and whether it combines them with the same WAL archive. Do not assume this from a PostgreSQL release note alone.

Minor PostgreSQL releases never change the internal storage format, so applying one means replacing the server executables and restarting the instance. No data conversion takes place, which makes minor updates the routine part of running the cluster. In a CloudNativePG cluster, the operator can roll a minor image change across the replicas first, then switch the primary, so each instance restarts once while a writable primary stays available for most of the window. Confirm in the operator documentation for your installed version how the image change, switchover order and pod restarts are sequenced, and whether your maintenance window must cover the restart of the final instance. PostgreSQL releases minor versions at least once every three months, so set a cadence that matches that rhythm. Test each minor image in a non-production cluster restored from a recent backup before it reaches production.

Major upgrades change the storage format, so they need a conversion step. PostgreSQL documents three routes: a logical dump with pg_dumpall and restore, pg_upgrade, and logical replication. The dump route is the simplest to reason about, but its outage grows with data volume. pg_upgrade converts the data directory directly, and PostgreSQL 18 retains planner statistics across major upgrades and adds parallel jobs and a --swap option, which reduces work at cutover. Logical replication works between different major versions and can keep a new cluster in sync until a short switch, which the PostgreSQL documentation describes as only several seconds of downtime. The cost is setup complexity, the need to carry schema changes and sequence values across deliberately, and a rollback path that depends on reverse replication. Choose the route for each database based on size, write rate and the downtime the business will accept.

Plan the target version against the PostgreSQL support windows. Version 14 is supported until November 12, 2026, and version 18 until November 14, 2030. Versions 15, 16 and 17 are supported until November 11, 2027, November 9, 2028 and November 8, 2029, respectively. Any cluster on version 14 needs a dated upgrade in the plan, because security fixes stop after that date. Confirm which PostgreSQL major versions your CloudNativePG release supports and which image tags are available in your registry, since operator support and PostgreSQL support are separate facts. Each major upgrade also requires application testing for query plans, extensions and driver behavior, and that testing often takes longer than the database step itself.

Kubernetes sets its own constraints on the order of work. The version skew policy requires kube-apiserver to be upgraded one minor version at a time and before kube-controller-manager, kube-scheduler and kubelets, and it allows kubelets to be up to three minor versions older than kube-apiserver. The Kubernetes project maintains the three most recent minor releases, so a platform that has fallen behind must upgrade several times in sequence. Check the current list on the Kubernetes releases page before you schedule work, because the supported set changes with each release cycle of roughly 14 weeks. Operator versions also declare the Kubernetes versions they support, so a Kubernetes upgrade may require a CloudNativePG upgrade first, or the reverse. Map both against your node pools, storage driver and backup tooling.

Plan the Kubernetes and PostgreSQL upgrades as separate tracks with their own owners, test environments and change records. Keep a single matrix that lists, for each environment, the Kubernetes minor version, the operator version, the PostgreSQL major and minor image, and the next dated end of support. Before either track starts, take a fresh backup and confirm that a restore works, because the rollback for a failed major upgrade often depends on the old cluster remaining intact. Run the Kubernetes change in a non-production cluster, then the PostgreSQL change, and avoid combining both in one window so that a failure has one cause to investigate.