postgres-operator-cloudnative-pg-migrationlisted

Migrate PostgreSQL clusters from the Zalando postgres-operator (acid.zalan.do `postgresql` CRs, Spilo/Patroni, WAL-G) to CloudNativePG (CNPG) on Kubernetes, incl. fully air-gapped clusters. Core knowledge: the two walls (Spilo↔CNPG glibc/collation divergence that corrupts physically-copied indexes; WAL-G↔Barman archive incompatibility that strands old backups), three migration paths (logical replication default; initdb.import for small DBs/PG≤13; pg_basebackup as the discouraged same-major exception), the acid.zalan.do→Cluster manifest field map with no-equivalent gaps (preparedDatabases, sidecars, logical-backup cron), backup re-plumbing onto the barman-cloud CNPG-I plugin, HA parity (synchronous + failoverQuorum vs Patroni failsafe), consumer cutover (service/secret renames, scram, cnpg_ metrics), air-gap mirroring, stay-vs-migrate evidence.
air-gapped/skills · ★ 5 · API & Backend · score 78

Install: claude install-skill air-gapped/skills

# postgres-operator-cloudnative-pg-migration Migrate PostgreSQL clusters from the Zalando postgres-operator (Spilo + Patroni) to CloudNativePG with data intact, indexes trustworthy, backups restorable at every phase, and no dependency left on maintenance-mode artifacts. Facts below were verified 2026-07-24 against primary sources (both operator repos at HEAD, release manifests, maintainer statements); re-verify anything version-gated before relying on it in a later year. Version anchor (2026-08-25): Zalando v2.0.2 (Spilo-18 4.1-p2, PG 14–18; v2.0.0 and v2.0.1 are both defective), CNPG 1.30.0 / 1.29.2 / 1.28.4 (2026-06-29; PG 14–18; 1.31 unreleased), plugin-barman-cloud v0.14.0. ## Why this migration exists Zalando's operator runs on one sustained maintainer in confirmed low gear (#2921) but is not dead — the v2 line shipped PG18, dropped PG13, and flipped both `kubernetes_use_configmaps` and scram-sha-256 on by default. CNPG runs ~7× the human commit volume across three maintained lines and has a documented migration wave. **This is strategic, not an emergency**: v2 extends the safe-to-stay horizon well past the old ~2027 estimate, and CNPG brings its own churn costs. Migrate deliberately, cluster by cluster. Full evidence, the skeptic's case, and alternatives: `references/decision.md`. For staying and operating Zalando instead — the v1.x→v2.x upgrade, the Patroni DCS/Endpoints switch, rolling-update triggers, day-2 operations — use the sibling skill `postgres-operator-be