Paul's Programming Notes PostsRSSGithub

Is CloudNativePG ready to replace Aurora or AlloyDB?

CloudNativePG is a Kubernetes operator for running PostgreSQL. It joined the CNCF Sandbox in January 2025, applied for Incubation and added PostgreSQL 18 support later that year, and shipped v1.30 in June 2026. It’s used by some big companies like IBM, Google Cloud, and Microsoft Azure, and it looks solid, though I haven’t run it myself. I’ve been weighing whether it’s worth advocating a swap from a plain Aurora or AlloyDB database onto it, and how much work you’d be taking on.

The pitch for Aurora and AlloyDB is that they take storage off your plate and let you scale compute on its own. Storage grows automatically with no downtime, up to 128 TiB, and is replicated six ways across three availability zones, so a write survives losing an entire zone and you never plan capacity or schedule a resize. AlloyDB takes the same approach on its own disaggregated storage and adds a columnar engine for analytics. CloudNativePG doesn’t work that way. It runs classic shared-nothing streaming replication, where each instance is a full Postgres node with its own PersistentVolumeClaim, and durability comes from replicating between instances rather than from a shared storage layer.

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: pg
spec:
  instances: 3                 # one primary, two streaming replicas
  storage:
    storageClass: local-nvme   # benchmark this before you trust it
    size: 200Gi
  walStorage:                  # WAL on its own volume
    storageClass: local-nvme
    size: 40Gi
  replicationSlots:
    highAvailability:
      enabled: true
  postgresql:
    parameters:
      shared_buffers: "4GB"    # tuning is yours now
    synchronous:               # opt in for RPO=0 (replication is async by default)
      method: any              # any = quorum-based
      number: 1                # standbys that must confirm each commit

That model works, but the volume is now your job. The docs recommend local NVMe for serious workloads and tell you to benchmark with fio and pgbench first, because network-attached storage can wreck Postgres latency. And there’s no auto-scaling, so you size the PVC up front and grow it later only if your CSI driver supports expansion.

Each instance keeps its own copy of the data, so with local volumes a failed node takes its data with it and the operator re-creates that instance by cloning a fresh copy from the primary, a slow rebuild for a large database. That only protects against a zone outage if the replicas are in other zones, which takes pod anti-affinity and topologySpreadConstraints to arrange, with the usual advice to run nodes in multiples of three, one per zone. The operator promotes a replica automatically when the primary fails, but replication is asynchronous by default, so that promotion can drop the last few committed transactions. Synchronous replication (method: any quorum, above) gets you back to RPO=0, and it makes the CAP tradeoff explicit. With the default dataDurability: required, writes pause when the operator can’t reach enough synchronous standbys, so a bad enough zone outage costs availability to preserve consistency. Aurora and AlloyDB make that same call at the storage layer and keep taking writes through an AZ failure. Cross-region means running a separate replica cluster fed by streaming or WAL shipping, with no automatic failover between clusters.

The operational pieces are all yours too. Continuous backup and point-in-time recovery go to object storage through the barman-cloud plugin, but you configure it, set the retention, and test that a restore actually works. Connection pooling is a Pooler resource running PgBouncer that you deploy and size. Monitoring is Prometheus metrics the operator exposes, wired into whatever stack you already run. Minor-version upgrades are rolling pod restarts you trigger.

So is it worth it? If you’re paying for Aurora mainly to avoid thinking about Postgres, self-hosting probably isn’t worth it. If you already have the Kubernetes and Postgres chops, live in GitOps, want off the managed-service markup, or need something the managed services won’t give you (specific extensions, exact versions, multi-cloud portability, no lock-in), it looks worth a serious trial. Either way I’d start on something smaller than a tier-1 database and prove out storage, backups, and failover first.

kubernetespostgresql