CloudNativePG — Production-Grade PostgreSQL Operator for Kubernetes

What it is

CloudNativePG is a Kubernetes operator for managing PostgreSQL database clusters. It handles the full lifecycle: provisioning, streaming replication, automated failover, online backups, point-in-time recovery (PITR), and rolling upgrades. It is a Level V operator, meaning it manages the entire database lifecycle natively in Kubernetes.

CloudNativePG targets platform teams running PostgreSQL on Kubernetes who want automated database operations without external tools like pgBouncer or Patroni.

How it saves time or tokens

CloudNativePG eliminates manual PostgreSQL administration on Kubernetes. Without an operator, you manage StatefulSets, configure replication manually, write backup scripts, and handle failover with custom logic. CloudNativePG encodes PostgreSQL operational expertise into a Kubernetes-native workflow.

Declarative configuration means your database topology is version-controlled YAML, reviewed in pull requests, and applied with kubectl.

How to use

1. Install the CloudNativePG operator:

kubectl apply --server-side -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.24/releases/cnpg-1.24.0.yaml

1. Create a PostgreSQL cluster:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: my-postgres
spec:
  instances: 3
  storage:
    size: 10Gi
  postgresql:
    parameters:
      max_connections: '200'
      shared_buffers: '256MB'

1. Apply and verify:

kubectl apply -f cluster.yaml
kubectl get cluster my-postgres

Example

Configuring automated backups to S3:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: production-db
spec:
  instances: 3
  storage:
    size: 50Gi
  backup:
    barmanObjectStore:
      destinationPath: 's3://my-backups/postgres/'
      s3Credentials:
        accessKeyId:
          name: aws-creds
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: aws-creds
          key: SECRET_ACCESS_KEY
    retentionPolicy: '30d'
  bootstrap:
    recovery:
      source: production-db

Related on TokRepo

• AI tools for database -- Database management tools and operators
• AI tools for DevOps -- Kubernetes and infrastructure tools

Common pitfalls

• Under-sizing storage. PostgreSQL WAL files and backups consume significant disk. Size storage at 3-5x your expected data size to accommodate WAL retention and temporary files.
• Ignoring connection pooling. CloudNativePG includes a built-in PgBouncer pooler. Enable it for applications with many short-lived connections to avoid exhausting PostgreSQL connections.
• Not testing recovery procedures. Backups are useless if you cannot restore from them. Regularly test point-in-time recovery in a staging environment.