CloudNativePG 1.16 imports a snapshot into a new cluster

A consistent backup is not a continuing stream of database changes. That distinction explains why an operator can import a running PostgreSQL database over the network and still describe the migration as offline. The backup can have a consistent view while writes continue, but later writes do not become part of that view.

The July 10 CloudNativePG announcement introduces offline network import in version 1.16.0. CloudNativePG uses PostgreSQL logical backup and restore to populate a new cluster. The same route can move data to a newer PostgreSQL major version, without requiring the source instance to run inside Kubernetes.

I default to PostgreSQL for relational systems, and I like operator features that retain an understandable connection to its native tools. Here the implementation uses pg_dump and pg_restore. The important migration boundary remains visible because the feature does not claim to replicate changes made after the snapshot.

Offline describes the final handover

The import documentation at the 1.16.0 release tag explains that PostgreSQL MVCC and snapshots allow consistent logical backups without stopping writes. CloudNativePG connects to the source over the network and takes that backup. It then restores the selected contents into a destination initialized through the initdb bootstrap method.

That mechanism supplies a view of the source database at a particular point. An application that continues modifying the source after the backup starts produces changes outside the imported snapshot. The documentation therefore recommends stopping writes before the final import. The offline qualification concerns preserving the final set of writes during the move, not an inability to read the source while it serves queries.

This makes the feature useful for a planned migration with an explicit interruption. It does not by itself describe a rolling handover in which both instances remain synchronized until traffic switches. No ongoing replication stage follows from the documented dump-and-restore workflow.

Major-version migration follows the same logical route. The documentation recommends a destination version equal to or newer than the source and leaves application compatibility and extension upgrade feasibility with the operator of the system. Restoring logical objects into another version changes the representation through PostgreSQL tools, but it cannot establish that every application assumption remains valid.

The import mode chooses an ownership model

CloudNativePG exposes two import types. The microservice type selects one database and restores it into the configured application database. Its restore command uses --no-acl --no-owner, and the target application user owns the database. Source roles do not come across in that mode.

This is an explicit change in what is being preserved. Moving one application database into a new owner context differs from copying an entire instance with all its users and databases. The mode is useful when the destination is intended to host one application, but its ownership behavior needs to be part of understanding the import.

The monolith type selects databases and roles from the source. It exports and restores the selected databases individually and imports their required roles. Some roles are excluded, including postgres and the operator-related replication and pooler users. It also removes the superuser option from imported roles. The destination therefore does not inherit every source privilege unchanged.

Both paths need a reachable source and enough privileges to take the logical backup. The selected mode does not arrange network connectivity or make an unavailable directory of credentials usable. Those requirements follow from running PostgreSQL backup tools against the external instance.

Temporary storage is part of the operation

The documentation states that the custom-format dump resides temporarily under a dumps directory in the destination PGDATA volume. Each destination node needs room for that dump in addition to restored data and indexes. The operator removes the dump directory after completing the import.

That is a practical property of the mechanism. The network connects the source and destination, but the operation still materializes an intermediate backup file. Sizing only for the final database would ignore an artifact that exists during restoration. Completion also includes analyzing the imported database so that PostgreSQL can populate its statistics.

I find this explicit workflow preferable to treating migration as one opaque operator action. It identifies the source snapshot, the temporary file, and the restored ownership context. Those details explain what the destination contains when bootstrap finishes.

Replica eligibility also gains topology information

The same release adds label-based anti-affinity for synchronous replicas. The release-tag replication documentation places this under spec.postgresql.syncReplicaElectionConstraint. It can select synchronous participants whose nodes have different label values from the primary node, with availability zone as the example.

This controls eligibility in the synchronous set and is distinct from general pod scheduling rules. It also retains the operator's self-healing behavior. The documentation says it can relax the configured minimum when fewer replicas are available and disable synchronous replication when no ready replicas remain. The topology selection therefore should not be read as an unconditional guarantee that every acknowledged write always has a copy in a different zone.

These two additions expose decisions that otherwise remain outside a simple instance count. Import mode determines what data and ownership the new cluster receives. Synchronous-replica eligibility determines which existing copies can participate in commit acknowledgement, subject to the documented availability behavior. Both need their underlying PostgreSQL mechanism to remain visible in the cluster configuration.