CloudNativePG: What the Operator Does and How It Is Structured

▶ Watch (0:04)

CloudNativePG is an open-source Kubernetes operator built to manage PostgreSQL workloads on any supported Kubernetes cluster. It is a CNCF sandbox project and applied for incubation at KubeCon North America. The operator introduces a custom resource named Cluster, representing a PostgreSQL cluster made up of one primary and an arbitrary number of replicas. The typical deployment uses three instances. Kubernetes serves as the source of truth, and the project spans several repositories open for contribution.

Shared-Nothing Architecture Across Availability Zones

▶ Watch (1:51)

The suggested production topology places each PostgreSQL instance on a separate worker node in a different availability zone. Each node gets its own local persistent volume. Services expose the cluster: one read-write service targets the primary, one read-only service targets replicas, and a combined read service covers both. This shared-nothing layout avoids single points of failure at the storage layer and lets Kubernetes scheduling enforce zone distribution without additional configuration.

Declarative Configuration and Backup Options

▶ Watch (2:42)

CloudNativePG handles PostgreSQL configuration declaratively inside the Cluster spec. Operators add parameters directly to the CRD rather than editing config files. Backup and recovery run through two paths: volume snapshot CRDs or object store via Barman Cloud. A kubectl plugin retrieves logs and performance data. The operator also supports hibernation, which lets teams shut down a cluster on weekends to reduce cloud spend, then bring it back without data loss.

Recent Features: Logical Replication, Extensions, and Plugin Interface

▶ Watch (3:55)

Newer releases added declarative databases, logical replication through declarative publications and subscriptions, and the CNPGI plugin interface for custom backup systems. Major PostgreSQL version upgrades are supported. Declarative foreign data management, quorum-based failover, and OCI container-based extension loading arrived in recent versions. The plugin interface means teams can write and attach their own backup provider without forking the operator. The project’s stated goal is to make every operational concern expressible as a Kubernetes manifest.

Notable Quotes

Yes, you can run data on kubernetes. Gabriele Quaresima · ▶ 00:19

We need another one another meaning for cluster. Gabriele Quaresima · ▶ 01:18

we try to pull everything in a declarative way Gabriele Quaresima · ▶ 04:05

Key Takeaways

  • CloudNativePG defines PostgreSQL clusters as a single Kubernetes CRD named Cluster.
  • Three instances across three availability zones is the recommended production layout.
  • Backup runs via volume snapshots or object store; both paths are supported today.
  • Declarative logical replication and OCI-based extension loading landed in recent releases.

About the Speaker(s)

Gabriele Quaresima is a Staff Software Engineer at EDB, where he has worked since March 2021. He focuses on Go and Kubernetes, particularly on Kubernetes Operators, and contributes to the CloudNativePG project. Outside engineering, he plays saxophones and flutes.