Alauda build of CloudNativePG
  • English

    • Migrating from the Zalando postgres-operator

    This section is for users moving PostgreSQL clusters from the Zalando postgres-operator (acid.zalan.do/v1 postgresql, the Spilo/Patroni based stack previously shipped on Alauda Container Platform) to CloudNativePG (postgresql.cnpg.io/v1).

    • Manifest mapping — every Zalando CR field and its CloudNativePG equivalent, plus the automated conversion tool.
    • Data migration — moving the data: dump/restore, logical replication, or physical clone.

    TOC

    Why migrate, and what to expectConcept mappingMigration checklist

    Why migrate, and what to expect

    • No performance regression. Release qualification for CNPG v1.29.1 included a same-hardware A/B comparison against the Zalando stack (identical sysbench OLTP workload, matched shared_buffers and max_connections per scenario): CloudNativePG matched or exceeded the Zalando stack in all eight scenarios (TPS and P95 latency).

    • Extension parity. All bundled extensions ship inside the PostgreSQL operand images:

      PG majorpgvectorpgauditPostGIS 3.6zhparser 2.4TimescaleDB 2.27 (Apache-2 OSS)
      14✓✓✓✓✗ not available
      15–18✓✓✓✓✓

      TimescaleDB packages for Debian trixie start at PG 15 — a Zalando user on PG 14 with TimescaleDB should upgrade to PG 15+ during the migration (PG 14 is near end-of-life). The TimescaleDB build is the Apache-2 OSS edition, equivalent to Spilo's APACHE_ONLY=true — no capability loss versus Zalando.

    • Architecture simplification: no Patroni or external DCS, no Spilo mega-image, Kubernetes-native failover, declarative configuration — see Architecture.

    Concept mapping

    Zalando conceptCloudNativePG equivalent
    One postgresql CR = cluster + users + DBs + pooler + backupsplit: Cluster (+ Pooler, Database, ScheduledBackup)
    Spilo image (PostgreSQL + Patroni bundle)plain PostgreSQL operand image; instance manager injected by the operator
    Patroni / DCS leader electionoperator-driven failover, Kubernetes-native
    master service <cluster> / repl service <cluster>-repl<cluster>-rw / <cluster>-ro (replicas only; -r = any instance)
    secret <user>.<cluster>.credentials.postgresql.acid.zalan.do (Opaque)<cluster>-app for the bootstrap owner; managed roles use kubernetes.io/basic-auth secrets you provide
    postgres superuser secret (always created)superuser access disabled by default (enableSuperuserAccess: true creates <cluster>-superuser)
    logical backup CronJob (pg_dumpall to S3)physical backups (barman-cloud plugin or CSI snapshots, with PITR); logical dumps = bring your own CronJob
    WAL-E / WAL-G archive (Spilo layout)barman-cloud archive — formats are incompatible; backup history does not carry over

    Migration checklist

    1. Convert the manifest (manifest mapping — review every warning the conversion tool prints).
    2. Pick the data path (data migration).
    3. Recreate credential secrets (kubernetes.io/basic-auth) if applications must keep their passwords.
    4. Deploy, wait for Cluster in healthy state, run a first backup, wire monitoring (the Grafana dashboards guide, How To section).
    5. Repoint applications (service names change), then decommission the Zalando cluster after a rollback window.