Alauda Data Services Relational Database E3

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 checklistTrademark Notice

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.

Trademark Notice

CloudNativePG™ is a trademark of The Linux Foundation.

PostgreSQL® is a registered trademark of the PostgreSQL Community Association of Canada.

Alauda is an independent vendor. This product is not affiliated with, endorsed by, or sponsored by The Linux Foundation, PostgreSQL Community Association of Canada. All trademarks are the property of their respective owners and are used here for identification purposes only.