CloudNativePG helps teams operate PostgreSQL databases through Kubernetes. You describe the database cluster you want, and the operator manages the associated database instances and Kubernetes resources rather than requiring you to maintain each one by hand. It is useful when PostgreSQL needs an operating model built around the cluster platform. Moving an existing database into that model still requires a real data migration, with application checks and a tested recovery path.
Deployment and operating notes
Its published charts separate operator installation from cluster resources. It is a candidate for a PostgreSQL platform redesign, including migrations away from a chart or image distribution that no longer meets requirements.
A chart swap is not a database migration
Choose a supported PostgreSQL version and verify extensions, roles, connection behavior, storage and backup requirements. The operator's import documentation describes supported import paths; select one based on source compatibility and acceptable downtime.
Acceptance and rollback
Restore a representative backup into an isolated destination and test the application's reads and writes. Record recovery time, permissions, sequences, jobs and replication behavior. Once new writes reach the destination, returning to the source requires an explicit data-reconciliation plan; a DNS change or Helm rollback does not move those writes back.
Use the PostgreSQL migration plan to decide whether logical migration, replication or another supported method fits your installation.
Sources & further reading
Spotted something that needs another look?
Help improve this page →